I have just upgraded from 24.10.1 to 25.12.4, retaining configs, which worked fine on an ath79 TP-Link Archer C7 v4 being used as an Access Point, but upgrading an ath79 TP-Link Archer C7 v2 acting as the gateway to the ISP didn't provide a working router.
On 24.10.1 udhcpc successfully obtains an IPv4 address from the ISP. The system log shows
daemon.notice netifd: wan (2716): udhcpc: broadcasting select for <offered IPv4 address>, server <server IPv4 address>
daemon.notice netifd: wan (2716): udhcpc: lease of <offered IPv4 address> obtained from <server IPv4 address>, lease time 3600
On 25.12.4 it does not.
I get multiple instances (usually four) of
daemon.notice netifd: wan (2716): udhcpc: broadcasting select for <offered IPv4 address>, server <server IPv4 address>
before (presumably) the server gives up, and tries again with a different offered IPv4 address. Repeatedly. The OpenWrt device never sends the lease obtained message.
I reverted to the newest 24-series version, 24.10.6, and that successfully gets an IPv4 address from the ISP.
Given that the ISP hasn't been changing the software of configuration at their end, it looks like something has happened with OpenWrt's udhcpc.
Am I being dumb, and have missed something obvious; or has anyone else experienced similar?
This sounds like the dhcp client change that is known and documented and can cause this type of behavior.
Did you perform an override of the router's MAC address (typically cloning the MAC that was used previously)? If so, undoing this (if it won't break your connection) may resolve the issue.
Ahh - my searches didn't find that gem of a thread. Thank-you.
I have every sympathy with wanting to offer standards-observing behaviour, but it would be helpful if the change from previous non-standards-observing behaviour were documented prominently in the user-interface, and preferably some means of easily reverting to the non-standard behaviour (which worked) be offered. The loss of connectivity via my ISP to the Internet was not helpful.
I can't test workarounds right now, but will do so as soon as I have enough uncommitted time.
Edit to add: no, I did not and do not do a MAC address override.
Yeah... I had this problem crop up in my lab at work. In my case, the problem only manifested if I cloned the MAC (which was required for some experiments I was running at the time). I rolled back to 24.10 until I was done with those experiments. Nw I've got 25.12 and I'm using the built-in MAC which works well. That said, like you, I didn't have time to experiment with that device, not sure when I'll get to a point when I can gather more test data.
OK, I grabbed 10 minutes, and yes, setting the Luci - Interfaces - wan - Advanced Settings - Client ID to send when requesting DHCP to a 'randomized' MAC address[1] has meant I get working IPv4[2].
I did not need to set the broadcast flag.
Thank you again for your help.
I used a DECnet MAC address (a blast from my past), which starts with AA0004, and that second 'A' has happens to have the right bit set (locally administered) to taken as an indicator (these days) of a 'randomised' MAC address. ↩︎
The ISP that this particular router is attached to does not offer IPv6. Really. ↩︎