I have a Linksys WRT1200AC running open wrt. Whenever the cable modem loses its connection (which happens when we get momentary power interruptions), the router drops the wifi. I'm not positive, but I think the router is actually rebooting. The router, switch and cable modem are all on a UPS so they don't get a power interruption.
So the problem is initiated when the power goes out momentarily, causing the cable company's system to reboot. My modem loses sync and apparently lets openwrt know about it. I tested my UPS and its working flawlessly.
I understand that there can be no internet connection while the modem is resyncing, but the internal network should not be affected and the OpenWrt router should not reboot and drop all the wifi connections.
The router is running OpenWrt 19.07.7 r11306-c4a6851c72 / LuCI openwrt-19.07 branch git-22.025.78315-f3debdc which is a version back, but upgrading on this router is a bit problematic.
So is this a version issue or is it a known bug? Is there a fix?
What client devices have you used to verify this? Mobile phones and other devices with a cellular radio will often drop off wifi in favor of cellular when they detect that the wifi doesn't have an upstream connection. A laptop or desktop computer (or anything not running a mobile OS / cellular connection) will typically stay on wifi if it is still up and running.
You can also look at the logs to see if the wifi SSIDs have been stopped or restarted.
The logs just had a ton of wireguard errors. This particular router had a failed install of wireguard. I removed the offending configuration, but I'm sure the shutdown was not related.
This afternoon when the power glitched, both the cell phone and laptop (both wifi) dropped out. I ran out to the router and it appeared to be doing a boot up sequence based on the LEDs. I keep the cell phone data turned off so I don't think that was related.
This is not the first time. It acts just like you would expect if there was no UPS. I tried flipping the power to UPS on and off and there was no interruption, so its working fine. The modem, router and switch are all on the UPS. My theory is that the lack of a valid modem signal, due to a temporary failure of the cable network, is somehow triggering the OpenWrt router to reboot.
The cable modem has its own router, but if it detects another router downstream, it switches to passthrough mode so that there is no double nat problem. Is it possible OpenWrt knows this and reboots when the modem goes down so it will come back up in the right mode? Is there a way to resync without knocking off the wifi?
This certainly sounds like it had a power glitch... but the logs would be the best way to know.
Even with mobile data disabled, sometimes they will drop off wifi when there is no connectivity. But again, more info from the router itself is necessary.
You might be dealing with a UPS issue or it could even be an issue with your router's own power brick or maybe the router itself is failing. The logs will at least reveal if there has been a reboot.
How did you do this? Does the power outlet that has the UPS connected have a switch? or did you use the UPS's self-test mode? I'd recommend simply yanking the UPS's power connection from the wall and see what happens.
I do not agree with your theory, but I'm willing to be proven wrong. Want to simulate this: pull the ethernet cable out of your OpenWrt router's WAN port. See what happens. Or better yet, pull the power of your cable modem and observe... plug it back in and continue to watch. You could even monitor the logs on OpenWrt along the way to see what is happening on that device.
How would it detect another router? Generally speaking, this is a configuration you'd have to set (pass-through/bridge mode or router mode) -- I'd be a bit surprised if it can reliably detect a downstream router.
If the cable modem's router feature uses the same subnet for the LAN as your OpenWrt router does, routing will not work. In that case, if the cable modem is really detecting the downstream router (which I said earlier would surprise me), the routing would be broken until the modem re-configures itself. It would also need to bounce the Ethernet port to force the downstream device (OpenWrt) to request a new DHCP lease. So while OpenWrt wouldn't be doing anything special here, it could be a function of the cable modem itself.
Definitely not a UPS issue. The UPS is a DC UPS so there is no AC power bricks. Having just said that, since all the the DC power outputs are connected together, its possible that the cable modem shorted the power after being cut off.
I have the UPS plugged into a power strip with a switch. I just flipped it a few times and nothing happened on the router or modem.
I didn't save the logs, and there was a lot of chatter about the wireguard config error, but the first entry was time stamped at this afternoon at just about the same time the power glitch happened. The first line was a wireguard error and not a "Booting Linux" line.
I don't think the cell phone would affect the laptop. Both disconnected at the same time.
When I have time, I will try to simulate a cable failure by pulling the plug on the modem.
I can't elaborate on how the modem detects the downstream router, I only know that it does. If the router is not powered on when the modem is powered on, then the router won't be able to connect to the modem if it is powered on at a later time. Yet, if you plug a laptop directly into the modem, it works fine.
Could it be possible that the modem is trying to make a DHCP or DNS request on the router and if it gets a response, then it knows its a router? Whereas a laptop typically won't respond to DNS or DHCP requests. If true, then it would explain why the modem sets the mode at startup and wont change again until reboot.
But in this case, the mains AC power did glitch for the entire neighborhood, but I don't think it was reflected on the DC output. Nevertheless, it is possible, albeit unlikely, that the modem clamped the power and momentarily dropped the DC voltage to zero.
under what circumstances is the cable modem loosing its connection? I still don't think this is directly relevant, but if it is on a UPS, it shouldn't be dropping the connection on momentary power interruptions. The headend (i.e. the cable company) is almost always battery backed, meaning that unless the connection issue is caused by some non-UPS'd intermediate equipment, a power glitch shouldn't do anything to the cable modem...
you should be able to fix the wireguard error simply by editing your network config file and removing the offending wireguard configuration stanzas (possibly all of them).
The log is a rolling file in RAM, so depending on how many WG config errors and other events were thrown into the syslog, it is entirely possible that it did reboot but those messages were lost to the history.
Most cable modems do a MAC address binding, so this may be normal. The real question is this:
if you plug your laptop directly into the modem, what IP address do you see on the laptop? Is it a public IP or an RFC1918 address (in the 192.168.1.0/24 network for example)? Likewise, when your router is connected, what does it report as its WAN? If you're not sure, just post the first two octets (in bold: aaa.bbb.ccc.ddd) for each of those situations.
Nope... not possible. No router should ever respond to DHCP or DNS requests on its WAN port (at least by default, and usually never).
It could, however, analyze the MAC address of the router and make an assumption (i.e. if the MAC address is from a manufacturer of routers like Netgear, DLink, Linksys, TP-Link and a number of other consumer brands, maybe even including the business and enterprise markets, too).
In general, cable modems "learn" the MAC of the connected equipment and they do not issue an IP to another piece of equipment until after the modem is restarted.
If the modem does this, it is a faulty modem. However, if your power supply is marginal (i.e. near 100% utilization of its current capacity), should the modem require more power at that moment, it could cause a brownout condition due to the additional current draw (which would cause the voltage to droop -- only if the UPS is at or over capacity).
The next time it happens, I will be checking the logs for sure.
The cable company has signal repeaters all around and those repeater boxes have batteries in them. When the batteries are good, and not stolen, the system will not usually go down. Otherwise, a power glitch will initiate a reboot of their repeater which drops my connection momentarily.
The wireguard on that router was not being used. The original reason for using it was so that I could get around a double natting issue caused by T-Mobile's home internet service which I was considering getting. In the end, the cable company came through with a better deal with no double natting problems so the VPN was abandoned on that router. I didn't realize it was a problem until I looked at the logs. I removed the bad WG config as well as OpenVPN which is not used either and the problem went away.
Checking the MAC address would work, but it would likely mean the modem must make assumptions about its use. For example, a raspberry Pi can be a local node or it can be a router. Years ago, I had a PC running Coyote Linux as a firewall/router so the MAC address would mislead the modem into thinking it was connected to just a plain PC.
I'm not 100% certain about the assigned IP address if you hook a computer straight to the modem. I do know that if you do, you can log into the modem itself and change a few settings. That isn't possible once it switches to passthrough mode.
The power supply could be close to marginal. It puts out about 3-4 amps at 12V. It currently powers the modem, router and switch. The switch uses next to no power, the modem and router were measured by others to be less than one amp each. Its still possible that during a loss of signal, the modem kicks up its power output to try to reach a weak node. That could be causing an excess draw. I do know for a fact that this UPS will cut off with an excessive draw.
Anyhow, it sounds I need to wait for the next one and then check the logs. Or maybe put the modem on a separate UPS.