Don't let sleeping wifi printers lie

Certain multifunction printers are notorious for not waking up from wifi sleep. For my HP OfficeJet 6978, one indication is this message in the Windows 7 status bar:

Scan to computer is no longer activated. The network connection to the printer has been lost. ScanToPCActivationApp.

Another indication is that the printer periodically stops responding to PINGs for extended intervals. When this happens, Windows reports destination host unreachable.

Often, we're told to power cycle the printer and/or router to recover. But that only works until the next print job. That rather defeats the purpose of a wifi printer. And the very same printer may have worked just fine for months previously. What changed?

This issue is not uncommon. A search on wifi OfficeJet won't wake up returns 47,700,000 hits, and a search on wifi Epson won't wake up returns 1,420,000 hits (Google 2022). It started affecting my HP OfficeJet Pro 6978 after I replaced an obsolete router for security reasons.

In my case, using my new router's configuration page to deselect 'legacy' 802.11b rates (1-11 megabytes/second) was a complete cure! But what if some new Internet thing only supports 802.11b? With 802.11b: on and beacon interval: 100ms, increasing the 'DTIM' interval from 2 (the default) to between 16 and 20 helped. But it wasn't as good. From Windows 7 it could still take up to 2.834 seconds to get a response, and in any 40 tests, at least one would time out. I elected to go back to DTIM: 2 and 802.11b: off instead.

Steps to reproduce this bug

Using a GL-iNet GL-SF1200 OpenWRT router, advanced configuration (the LuCI interface):

1. Make sure the router option to allow legacy 802.11b rates is enabled. This is on the wireless tab, applicable radio edit button, advanced settings tab.
2. Make sure the router beacon interval is 100 (the default here).
3. Make sure the router DTIM interval is 2 (the default here).
4. Make sure the printer's IP/MAC address association is no longer in your computer's ARP table. From your computer's command line, arp -a will show current entries. For one of my computers, this is automatically purged 20 minutes after the last use. But you can purge it manually. Type arp to find out the correct command line for your computer.
5. Have an Android such as a Nokia 2.2 or Samsung Galaxy A32 join the Wifi. This is important. I could not reproduce the bug unless an Android was on the network.
6. Try to ping the printer's IP address. Sometimes it responds to the first ping, but I find it may take up to 49 pings to get a response. By that time any attempt to use the printer from the PC would time out.

Either turning off all Androids on the network or turning off support for legacy 802.11b rates solves the problem. Otherwise, when you ping at 1-second intervals, the result may not be answered for nearly 50 seconds, by which time the PC will have given up.

Once the IP: MAC association is in the PC's ARP table, everything works fine until the PC removes that association from its MAC table. That commonly takes less than 20 minutes from the last use.

The whole is more than the sum of the parts. Your printer was working fine. One day your printer won't wake up. An Android and router are snickering in the background. The OEM printer people will give you every appearance of support short of help. They don't know about the Android connection. They certainly don't know about turning off support for legacy 802.11b rates in the router. But when the Androids leave, everything works fine. When they return, printing breaks. Until you finally notice that, the unpredictability will drive you batty. But actually, it's completely reproducible.

Somebody else should check into this and find an explanation for why things behave this way. But until then, just turn off support for legacy 802.11b rates and you'll be fine. There's nothing like a good coverup.