I had a recent need for mobile computing, preferably with a larger screen size. So I dusted off the GalliumOS powered Toshiba chromebook to discover it refuses to connect to wifi. Delete the connection entry, reboot, create a new one. Nope. Hmm. Network admin brain cells start warming up, a command line or two later, and I have an interesting error message about "no available address". Ok, over to the desktop to check the access point's status screen. Isn't there a special address I need to use, or something? Rooting around the desk unearths the manual and the necessary settings. Boot a live CD for the interim? Nope, too scuffed up.  Fine, ifconfig<enter> "command not found"? Oh, right /sbin/ifconfig<enter> "command not found". SAY WHAT??? My recent upgrade to Debian-Bullseye didn't include those ancient net-tools for which I've memorized the syntax. By this time I've done a full reset on the AP, but the wired ethernet connection should work with minimal intervention, right? Hours later at least the wifi is working and has the correct settings, but the wired connection to the desktop is still dead. Umm, no, couldn't be that. <checks hub under the desk> Only one connection indicator? The desktop _is_ plugged in, that means...

All that time wasted, because of a broken tab on an RJ45. The cable had unplugged itself one or another time that I flipped over the AP to check or re-check its' default values. All I want for Christmas is aRJ45 crimping tool. ;)

Oh, right. Back to the chromebook and why we're really here. With a fully functioning network, updated firmware on the AP, and a nice clean block of 192.168.0.* for DHCP leases the 'book still reports no address. Since it hasn't been used in many months, dhclient -r? Nothing changes. Using nmcli's monitor mode, I notice that it is alway failing at the DHCP lease step. A bit more digging in DHCP land, but nothing changes. I'm not sure why, but I checked the date/time on the 'book to discover that, while the date was off by about a month, the year was somehow set to 2166! Uhh, what? The month being off by a little, due to a dead battery, should resolve as soon as NNTP runs. Without a network to correct the time, a century-expired DHCP offer would be rejected, right? Is it time for a deep-dive in to the relevant RFCs?