I'm on my university's network and would like to avoid bothering the support staff if I can resolve this myself. Printing usually works for me, but since yesterday I get the "Printing - The printer is not responding" message in the print queue. Some details about my situation:
The printer is online and working for everyone else.
I can ping the printer's IP address, and I can access its web page and see its supply levels, so I can definitely connect to it.
The printer is a Canon iR-ADV C7565. This might be a Japan-only model.
I have tried:
- turning WiFi off and on again
removing and re-adding the printer
resetting the print system and re-adding the printer
removing /Library/Printers and re-adding the printer
adding a new location in the Network preferences pane, then removing and re-adding the printer
I even tried rebooting
When adding the printer I do it by IP address, as per my institute's instructions. However, I get the following message:
It also doesn't correctly recognise the printer's driver, which I have installed, when trying to add it. (But I think that happened to me before - "Generic PostScript Printer" should work.)
I'm on OS X 10.11 El Capitan and have no intention of upgrading.
Is there anything else I can try to fix or at least diagnose the problem?
3 Answers
Self-answer: This might not be super helpful to anyone else with a similar question, but I was able to resolve this by reinstalling the drivers.
I did this by googling the printer's name - this gave a different page on Canon's site than the one my university's instructions link to, and installing that version of the driver made it work perfectly.
I have this issue too.
Something will get added to the print queue, and the MAC won't print it. 'The printer is not responding.'
ping works.
Connecting to the printer with the web browser works.
Displaying the ink levels from the printer device menu works.
If left alone, the MAC will eventually print it. Sometimes many minutes or hours later.
In the past I have 'reset the printing system', it deletes all the printers. It is a waste of time. But it gives you something to do. I did something to fix it!
Here's what I did this last time it did not print. I have not repeated this process. I did this because I did not feel like 'reseting the printing system.'
- open a terminal window
- ping printer (where printer is the hostname or ip-address)
- open the printer device queue
- pause the printer queue
- wait 30 - 60 seconds
- resume the printer queue
- You should see 'Connecting to printer' for the print job waiting. If it reports 'cannot connect to printer', repeat starting at step (4).
- It starts printing, type Control-C in the terminal window and close it.
After three cycles, the MAC started printing.
I have the same problem with CUPS on my macbook running El Capitan. But ONLY when the macbook is connected to the router using the wireless interface. It never happens when my macbook is connected using a cable.
I have seen this problem with a HP laserjet printer and with a Brother laser printer.
When the problem happens, netstat shows the state as SYN_SENT and lpstat -l reports "the printer is not responding". But tcpdump on the interface shows that the kernel is sending a different type of packet to the printer (I forget what type now, but it was not a SYN packet).
Also (since the HP is a postscript printer) I found that it is possible to use netcat to send a postscript file to the printer at the same time that lpstat says that the printer is not responding.
The fix is to: kill cupsd, switch off the wireless interface, kill cupsd again (launchd probably restarted it), wait a bit, switch the wireless interface back on, wait for the interface to come back up, kill cupsd AGAIN. Then when launchd restarts cupsd, the printer works again (until next time ...)
In fact I wrote a script called unjam-cupsd to do all this. It takes around 5 seconds to run, and almost always works first time.
Since my experience with the HP laserjet and netcat shows that a (non-CUPS) program can print a file when cupsd says it can't connect, I assume that cupsd uses some rarely-used socket option that sometimes triggers a bug in the wireless ethernet driver that causes non-SYN packets to be sent when the calling process is trying to set up a TCP connection.
1