(Apparently I had this uncommitted file in _posts collecting dust for more than two years, so what the hell, publish it. – 2019-10-02)
After watching a few LGR tech tales too many, I was inspired to dig through the “old junk” boxes at work. (Which for some reason included buying more old junk on eBay.)
So far, the loot: (and miscellaneous junk that I left behind)
Several PCMCIA cards for 802.11b Wi-Fi, all of them various Lucent/Avaya/Agere “ORiNOCO” models – these have an origin story of their own;
Several boxes of software – Office for Windows 3.x; Visual FoxPro; VisualAge for OS/2; large pile of IBM Lotus Domino CDs and various AIX add-ons (when did we even have AIX?!
&c.
quality D-Link products
Found a D-Link DP-301P+, which is a small “print server”, basically a LPT-to-Ethernet adapter. Spent 30 minutes trying to figure out its admin password with no luck – supposedly it has a hardcoded SYSxxyy password based on the MAC address, but that didn't work at all.
…However, the web UI only requires a password for GET requests – not for POST. So you can send a dummy POST to /Config.htm and see the regular configuration webpage, even with the old password fields filled in. And of course you can POST an update that clears the password or even factory-resets the device.
(Apparently there's a firmware update available, which might have fixed this, but… honestly the device is just too old and useless so I didn't bother testing.)
Spent an hour debugging Wi-Fi connection problems with our printer at home. It's a nice device overall, with good Linux support, and the network printing capabilities are very convenient these days as everyone is working on their laptop somewhere.
However, during the past few months we kept having intermittent connection problems – despite being on the same table as the AP, the printer just wouldn't connect to the network; whenever the "Wi-Fi" button was pressed, it would keep blinking for several minutes before giving up. If it ever managed to connect, however, it would work perfectly well for the next week.
At first I thought the printer had roamed to the other AP for this network (a powerline adapter on the opposite end of the house) which might be having connection problems – and sure enough, as soon as I disconnected it, the LaserJet would successfully connect to the main AP. But today I decided to take a shot at debugging it with my laptop's radio monitoring mode, and it turns out the distant AP was not a problem – the problem was the fact that there were multiple APs in the first place.
What the capture log in Wireshark showed was that that the printer would start associating to the main (closest) AP, but give up somewhere midway during the WPA2 handshake and go back to scanning. It seems that whatever embedded Wi-Fi chip is in the printer cannot keep track of multiple MACs per network – so while it was talking to access point A, it would receive a beacon from access point B for the same network name and this would make it abort the connection in progress.
For lack of a better solution (no firmware upgrades, no Ethernet…), I ended up just renaming the other AP to “Home (alt)”. I'm not entirely sure why the problem kept occurring even though the channels were not overlapping, but merely changing the network name does make the printer work perfectly – though I lose automatic roaming for all my other devices, which is a bummer.
The only bright side is that my printer still has fewer problems than some older models described in that 2015 post.