Has anybody heard of any known issues with using a HP printer networked to a RT-AC68P router? I've tried wired (ethernet, not usb) and wireless. It has been an ongoing issue for months so I have tried multiple firmware versions including both stock and Merlin. The printer goes into sleep mode and then refuses to print. Only a power cycle will get it to print again. I've been going back and forth with HP support because I assume it is a printer problem but I just wanted to see if anybody else has experienced anything similar with their router. I tried with IGMP snooping on/off as well as IGMP proxying on/off. The only reason that I am starting to question the router is because as a test last night, I hooked up an old WNDR3700 running Gargoyle to the printer with a wired connection and then connected wirelessly from my computer to the WNDR3700 and I was able to print after it went to sleep. It may have been a fluke because I only tried once. I also ran a packet capture with it hooked up to the RT-AC68P when it was in sleep mode and I can see it responding, although it ran into an issue where the printer keeps responding with smaller and smaller window sizes until it hits 0 and then after repeated ZeroWindowProbe/ZeroWindowProbeAcks the computer gives up waiting on the printer.
RT-AC68P + HP Printer
- Thread starter westmc
- Start date
sfx2000
Part of the Furniture
What OS (OS'es) are you trying to talk to the printer from?
IGMP has nothing to do with printer sharing... so those options shouldn't have any direct affect.
If you're doing Wireless or Ethernet, I've found that the HP Printer Drivers on Windows 7/8/10 do bind to the IP address of the printer, so if the Printer's IP address changes, the printer is lost...
The workaround, not just for Asus, but for all Router vendors, is to do a DHCP reservation for the printer, and not do a static IP address in the Printer WebUI - and then things should be fine..
IGMP has nothing to do with printer sharing... so those options shouldn't have any direct affect.
If you're doing Wireless or Ethernet, I've found that the HP Printer Drivers on Windows 7/8/10 do bind to the IP address of the printer, so if the Printer's IP address changes, the printer is lost...
The workaround, not just for Asus, but for all Router vendors, is to do a DHCP reservation for the printer, and not do a static IP address in the Printer WebUI - and then things should be fine..
Just to clarify, this is not using the router's printer sharing. It is just a network printer attached to my home network.
It affects Windows 10 (with the Microsoft drivers as well as the HP drivers), Windows 7, and OSX.
I've tried a static ip but it doesn't matter. I can literally print, wait 30 minutes, and try again and it won't print.
I've read other people reporting the same issue and a few believe it has to do with the latest version of the printer's firmware (and of course HP doesn't support firmware downgrades) so I still think it is the printer but when it worked with that other router, it really surprised me.
It affects Windows 10 (with the Microsoft drivers as well as the HP drivers), Windows 7, and OSX.
I've tried a static ip but it doesn't matter. I can literally print, wait 30 minutes, and try again and it won't print.
I've read other people reporting the same issue and a few believe it has to do with the latest version of the printer's firmware (and of course HP doesn't support firmware downgrades) so I still think it is the printer but when it worked with that other router, it really surprised me.
sfx2000
Part of the Furniture
I tried all of those steps but it didn't make a difference
I tried one more time with the WNDR3700 and it worked again, so I am really starting to wonder if it is the router. According to the packet capture, both the good and bad attempts successfully connect to receive the printer queue status, then successfully connect again to create a print job. The next message with the actual print job is where the difference shows up. It sends 3 packets of size 1514 and gets back an ACK. On the successful print, the ACK has a window size of 4380. On the failure, it is 502. The success attempt sends another 3 packets of size 1514 and continues on. The failure sends a packet of size 552 and then goes into a loop of ZeroWindowProbe/ZeroWindowProbeAck until it gives up.Similar threads
