Wired Ethernet and Wireless network connections not available after update

At first it seemed that the update had succeeded without a hitch; however, on restarting my computer, it would no-longer recognize my router. Both the wired ethernet connection (which is what I normally use) and the both of my wireless networks (2.4GHz & 5.0GHz, both from the same router as my wired network) were all invisible. Even attempting to connect Firefox to “” in order to check the configuration of my router also failed; I got “there is no router at that address”. But yes there is!

I tried restarting the cable modem, router, and computer multiple times, but the OS still couldn’t see the router.

So I had to use Timeshift to reset my system back to how it was on September 13, then everything worked again.

UPDATE, 3 hours later: I managed to fix the issue. Somehow, my router got reset to “factory”! I’m not sure if this happened before, during, or after the latest Manjaro upgrade process on my main computer.

I noted that the 2 other computers I have running Manjaro (not yet upgraded) were able to connect, as was my main computer after timeshifting back to September 13. However, on looking at their IP addresses, instead of being on the 192.168.63.## subnet as I expected, they were on the 192.168.1.## subnet! No wonder I couldn’t connect to; Firefox was right: there really was no router at because it got moved to

After redoing all my router settings, I was able to do this latest Manjaro update on my main computer, restart, and access my router & network and the Internet with no problem.

I think the issue may be that the way Manjaro reacts to a “router not on expected address” may have changed; my not-yet-upgraded Manjaro installations were able to connect via something called “auto-ethernet”, but my upgraded machine couldn’t connect at all. Maybe that’s even a “feature” rather than a bug; could have a security benefit, I suppose: if an unauthorized person were to screw-with the router, apparently Manjaro now balks; whereas before, it would connect to whatever IP the router’s DHCP server was offering, without complaint.

if you have not manually set up your ip (pretty rare) then it is configured automatically and the router IP means nothing for your internet access, only for connecting to it for configuration etc.

Well, since in my network, my computers get their internet feeds from my router, and my router gets its internet feed from a cable modem, if the computers can’t see the router (which was the case after this update), then they can’t see each other, or the router, or the modem, or the Internet.

Oddly, the not-yet-updated computers could see the router, network, modem, and Internet, and so could the timeshifted-back computer; only the updated one had the issue.

It thus appears to be due to a difference in how the non-updated vs updated computers handle a mis-configured router. The old way was to auto-connect via “auto-ethernet” (whatever that is) to whatever the router’s DHCP is offering. The new way is apparently to not connect at all (which is actually probably safer). How/why the updated machine was able to determine there was a problem, I have no idea; but apparently it did and balked.

Once I discovered the problem and set the router parameters (router name, subnet, allowable IP range, reserved addresses, WiFi names, WiFi passwords, etc) back to what they should be, then everything worked and both updated and non-updated computers could access the router as-normal, to either Ethernet or WiFi.

As for what screwed-up my router, or when, I have no idea. But it’s now fixed and everything works, so it’s moot.

Just a comment.

If the router is part of the ISP cable setup then the reset may have been caused by a ISP initiated modem/router firmware update.

If the router for one reason or another has been reset and advertising a subnet of then it is safe to assume this is the default for the device in question.

Assuming you were not satisfied with the defaults and you therefore had the router reconfigured to and subsequently configured static IP addressing matching the new subnet - then upon the mysterious reset those systems using the static addressing will never be able to communicate with other devices unless the whole #! is connected via a switch then to the router - in which case they would be able to talk to eachother.

All devices connected using DHCP would be able to communicate using the new subnet broadcasted by the router but only if the device’s network was restarted.

Even though a system has been addressed using DHCP the router configured lease time will have to expire before the device - in case of always on - will try to renew the lease - in that case it would get the new subnet - leading to confusion for experienced sysadmins.

There is no old or new way. You had those PCs set to use DHCP, and for this one you used static addressing. Simple as that.

Doesn’t matter, you still need PCs to be in the same subnet, since you need layer 3 to communicate. And home routers aren’t routers but all-in-one devices, so PCs are actually already connected via switch - those 4 LAN ports + wireless are bridged.

The evidence appears to indicate otherwise. (Though, admittedly, appearances can be deceptive.) The fact remains that my main computer was able to connect before the update, was not able to connect after the update, and was able to connect again after time-shifting back to Sept. 13. That appears to indicate that something in how Manjaro connects to routers (especially mis-configured routers) has changed.

I wish I had some idea of when the router got reset, and why, but I really don’t. The last time I connected to one of my router’s two WiFi channels (2.4GHz and 5.0GHz) was several days ago. So, the router reset could have occurred any time from about 9/13 to 9/18. As long as my computers logged onto the router via fully-automatic DHCP, I wouldn’t have noticed, as I don’t bother looking at my local IP addresses on a daily basis.

But I’m actually glad that this incident occurred, because it called my attention to the router glitch. As I understand it, the router is supposed to keep its settings in non-volatile memory, and the only way to “reset to factory” is to push the tiny, recessed red “Reset” button on the back while the router is up-and-running. (It’s not part of my ISP’s equipment, so I doubt the reset was their doing.) If it’s starting to reset itself for no good reason, it could indicate impending failure.

It would be preferred (especially if you want to get out of your local network, like to internet etc.), but not necessarily for communication in local network. Although now mostly obsolete, ever heard about IPX or AppleTalk or Bonjour? Even IPv6 doesn’t require you to be in the same “subnet” and link-local addresses are enough for communication between computers in the same switched area… (although some might argue that all link-local addresses are “same subnet”)… but still without being in the same IPv4 subnet. Even for protocols like DHCP to actually work, you don’t need to be in the same subnet prior for the communication to happen.
Even avahi (which should be present in linux by default?) … try typing in shell without being in the same subnet avahi-browse -avr.

First of all, we are talking about TCP/IP network stack here. Of course there is no physical limitation to make whatever custom stack where MACs are enough. And sure, as (L2) switches are concerned, there are no IP addresses. But when we get to endpoint devices and apps, you do need an IP address - it’s in the TCP/IP name for a reason.

What else are they if not in the same subnet? That’s the point of link-local addresses - doesn’t matter if IPv4 or v6. v4 has them too - APIPA:

Also you are throwing in some multicast - that is its own subnet too.

In almost all cases in home use you use DHCP to connect, and for that there is no old/new. The default still is to automatically connect. Whatever made one of your machines not able to, is a question but rest assured even after the update on a fresh install your computer will automatically connect as soon as you plug in the ethernet cable.

No, it did not. Sorry to contradict your statemet, but the fact is, computer equipment does it’s own things for its own reasons, which may-or-may-not correspond to how a human computer expert thinks it should behave. With enough troubleshooting, it may be possible to trace such quandaries to their sources. But since I was able to fix the issue by correcting the misconfiguration of my router, I didn’t (and don’t) find it worth my time to try and figure-out exactly why the events unfolded as they did. It was a glitch, now fixed. If it the problem repeats, I’ll investigate further; otherwise, I’ve better things to do with my time.

i meant that if things work like they should, in manjaro and pretty much any distro, then it will automatically connect once cable is plugged in. As long as you have at the other end a router that offers internet.

1 Like