For weeks I had a strange networking problem on my Linux laptop. It could join my iPhone hotspot instantly, without hesitation, every single time. But my home router – the same one that happily serves every other device – would often refuse to give my laptop an IP address. The network showed as “connected,” yet there was no traffic, no internet, and ping returned nothing but 100% packet loss.
Naturally, I assumed the usual suspects: DHCP server failure, MAC filtering, some mysterious router blacklist. I checked all of it. Everything looked normal. The router’s DHCP table was not full, MAC filtering was off, and other household devices – phones, tablets, even a smart TV – were connecting without the slightest drama.
Meanwhile, Linux would sit there endlessly sending DHCPDISCOVER packets:
DHCPDISCOVER on wlo1 to 255.255.255.255 port 67 interval ...
No DHCPOFFERS received.Yet the same hardware, same Wi-Fi card, same password – instant success on the iPhone hotspot. That contrast felt like a taunt.
Eventually the pattern emerged: whenever I manually executed
sudo ip link set wlo1 down
sudo ip link set wlo1 up– and then reconnected – the router immediately offered an IP and the network sprang to life. No need to touch DHCP client options, no need to spoof MAC addresses. Just bringing the interface properly up fixed everything.
This means the root of the problem was not DHCP, not the router, not authentication – but timing. On boot, the Wi-Fi interface was coming up in some half-asleep “dormant” state. NetworkManager thought it was up and started DHCP too early. The router ignored the requests coming from that half-awake interface. My iPhone, however, is far more permissive: it will hand out an address to anything that even vaguely resembles a client, which is why the hotspot worked effortlessly.
Once the interface was fully awake, DHCP worked immediately, every time.
There are two permanent solutions for this kind of issue:
- make NetworkManager explicitly autoconnect that interface
- or bring the interface up at the system level before NetworkManager touches it
I haven’t yet automated either fix – for now, I’m simply noting the pattern. The interesting lesson is that not all network failures are what they pretend to be. When a laptop connects to some networks but not others, it is tempting to blame the stricter network, or some imaginary filter. In this case the culprit was neither user error nor router policy – it was the difference between a lenient mobile hotspot and a router that expects the interface to behave properly at the exact right moment.
Sometimes the “big” network problems come down to a very small thing: an interface that woke up a few seconds too late.