I should preface my post by saying that I'm far from a networking expert, but I'm hoping to learn.
I just recently purchased a OpenWRT One device. It came installed with 24.10 firmware version and I've mostly left the device configured with the default settings (I turned on the wifi radios and set a password for root).
I have had a LOT of connectivity issues. Everything seems like it's working fine and then I'll lose internet access for hours. Generally my ISP is rock-solid so I don't think they are to blame.
I'm able to connect to the router and the wan interface seems fine (doesn't say No Link), it shows that it has an IP address from the Gateway. However, I'm unable to ping the gateway or any other address outside my home network.
I've tried:
changing the static address for the LAN from 192.168.1.1 to 192.168.2.1
cloning the MAC address of my old router (TP-Link) and configure my new router to use it
Both of these configuration changes have help restore connectivity, but only for a few hours and then I get back to the same state.
Has anybody else had a similar experience with this device? What has helped you?
Does this sound like an obvious configuration issue?
Again, I'm a noob and I'd love to keep the device, but the intermittent failures are really frustrating.
Maybe this might help:
if you have not installed it already, install ethtool-full (opkg update ; opkg install ethtool-full)
then run the following commands and post the output here (see at the end of this post for how to format the pasted text):
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fdb0:2358:5e4e::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth1'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config interface 'wan'
option device 'eth0'
option proto 'dhcp'
config interface 'wan6'
option device 'eth0'
option proto 'dhcpv6'
I used to have a line in the config interface 'wan' section that set a specific MAC address, but I removed that. As I mentioned above that seemed to help only temporarily.
Nothing obvious to me, but I also rebooted the router as soon as I had connectivity issues. My understanding is that rebooting flushes the logs in memory and they aren't persisted. If it happens again, I'll look in the logs first.
I'd love to understand this better. What makes you think it's a DHCP issue? (I don't doubt you just trying to get a better understanding of this system)
Leave logread ; logread -f running on an ssh shell and wait for your problem to manifest, ideally you should get a log messages around the time it happens. This is just a first step in debugging the issue, but usually provides a first insight.
Things working and then after some while, while the DHCP leases expire, things going ballistic + the routing issues (gateway has internet but the rest of the network does not).
Please try changing your lan IP address on the OpenWRT One to something else, like 192.168.0.1 and reboot the device. Also, and this is annoying, power cycle all devices connected to the One sp they get a new DHCP lease.
Okay, it's happened two more times since I posted. In both cases I see:
Sun Mar 23 09:23:09 2025 daemon.notice netifd: wan (2683): udhcpc: sending renew to server <redacted>
Sun Mar 23 09:23:09 2025 daemon.notice netifd: wan (2683): udhcpc: received DHCP NAK
Sun Mar 23 09:23:09 2025 daemon.notice netifd: Interface 'wan' has lost the connection
I search the logs to see if this happens in other places, but it only shows up when the network goes down (and stays down).
The router seems to think it has recovered
Sun Mar 23 09:23:12 2025 daemon.notice netifd: wan (2683): udhcpc: broadcasting discover
Sun Mar 23 09:23:12 2025 daemon.notice netifd: wan (2683): udhcpc: broadcasting select for <redacted>, server <redacted>
Sun Mar 23 09:23:12 2025 daemon.notice netifd: wan (2683): udhcpc: lease of <redacted> obtained from <redacted>, lease time 10800
Sun Mar 23 09:23:12 2025 daemon.notice netifd: Interface 'wan' is now up
No.
It appears to me this is an issue with your ISP that has sent a NAK response to a renewal request for a lease renewal for your WAN client. A normal response should return something like this:
Sun Mar 23 12:16:45 2025 daemon.notice netifd: wan (28915): udhcpc: sending renew to server 100.64.0.1
Sun Mar 23 12:16:45 2025 daemon.notice netifd: wan (28915): udhcpc: lease of 100.110.88.170 obtained from 100.64.0.1, lease time 300
The second stanza posted would be a normal discover request from your router to your ISP dhcp server saying are you there?.
Changing the MAC address seems to fix the issue. Initially I thought I needed to clone the old router's MAC address, but it turns out that any address fixes the issue. This leads me to think it's an issue with the ISP along with what @RuralRoots said. However, my old TP-Link doesn't seem to have this issue so that makes me think it's an issue with my new OpenWRT router.
Anyway, at this point I think I have a workaround (auto update the MAC on internet loss), but I wish I understood what the underlying issue was.
I would suggest taking a backup of your current config for reference and restore the router to firstboot and see if it runs past the 3Hr. WAN lease without cloning the MAC.
I’m not exactly sure what was causing the issue. However, I’ve been able to avoid losing connectivity by using the hot plug system to detect if I receive a NAK From my ISP And restart the network.
@momomalone your post here Connectivity Issues w/ OpenWRT One - #13 by momomalone is exactly what should happen. Its perfectly valid for an ISP to return NAK to a DHCP renew request, although it shouldnt happen very often. On receiving the NAK, the router should immediately go back to DHCP Discovery and obtain a new IP. That seems to be what is happening and should restore internet access within seconds. If access isnt resored by the reassignment of the new IP then there's another fault somewhere.
