1

We have a fairly extensive campus network consisting of multiple subnets connected by a core router.

Everything has been working fine for years, but recently I have a number of macosx clients that refuse to print to a network printer (LPR) on a different subnet than the client machine. This is causing some consternation.

Checks:

  • Correct addressing, subnet mask, and routing has been confirmed on both the client machines and affected printers
  • YES - I can ping the LPR printer via IP address from the client machine
  • YES - I can ping the LPR printer via its DNS name from the client machine
  • YES - I can telnet to port 515 on the printer from the client machine
  • macOS "Network Utility" port scan shows TCP port 515 "open" on the printer from the client machine
  • YES - I can pull up the printer's admin web page from a browser on the client machine
  • I have tried removing and re-installing the printer on the client machine via both DNS name and IP addresss
  • I AM able to print from the same subnet as the printer with no configuration changes
  • I have tried both "dscacheutil -flushdns" and "sudo dscacheutil -flushdns" to no avail

The odd thing is, I have multiple macosx clients that will no longer print. More than one printer is affected, too.

Symptoms:

If I connect a client machine directly to the same subnet as the printer (via Ethernet cable or WiFi), I can print just fine.

If I attempt to print to the printer from a different subnet, the PrinterProxy (macosx print monitor) app opens up and shows the document with the status below: "Printing - Connecting to printer." After some time it says "Printing - The printer is not responding."

Sample Info:

  • Client machine running macOS Sierra 10.12.6
  • Konica-Minolta C652DS multifunction copy machine
  • HP LaserJet 2100

This is baffling me. Clearly there is connectivity from the client machine to the printer. I have tried removing the printer and re-adding it via its DNS name and via its IP address. The same failure occurs in all cases.

My experience suggests to me that nothing is wrong with the printer or the network itself. It must be some bug in macosx or CUPS that refuses to talk to the printer if it's not on the same subnet.

Has anyone observed this phenomenon, and are there any solutions or suggestions?

Kevin H. Patterson
  • 133
  • 6
  • First, mDNS lookups (i.e. ".local" names) will not work across subnets (without special setup), but DNS and numeric IP should. Second, `dscacheutil -flushdns` doesn't work anymore, use `sudo killall mDNSResponder`. You can use `dscacheutil -q host -a name printername.whatever.com` to verify that names are being resolved correctly. You can also enable debug logging in the print system with `cupsctl --debug-logging; sudo launchctl stop org.cups.cupsd`, try printing, and then look in /var/log/cups/error_log for output. To disable, repeat with `--no-debug-logging`. – Gordon Davisson Nov 18 '17 at 20:41
  • If that doesn't provide any useful information, try watching the actual connection with `sudo tcpdump -Ans0 -ien0 port 515` (replacing "en0" with the appropriate network interface). This should tell you if it is actually connecting (/trying to connect) to the printer. Also, look for printer error messages in the LPR session content. (I've run into a couple of LPR errors I couldn't diagnose any way other than capturing error messages off the wire. This is one of the reasons I hate LPR.) – Gordon Davisson Nov 18 '17 at 20:51
  • FYI Updated one of the client machines to macOS 10.13 High Sierra. The problem remains. – Kevin H. Patterson Nov 21 '17 at 15:52
  • Also, we did replace our core router recently. I'm not sure how closely the onset of the problem might correlate with that time wise, but it seems odd that LPR would be the only thing affected; the rest of the network and routing works perfectly. – Kevin H. Patterson Nov 21 '17 at 16:00
  • Printing to the same printers via TCP/IP from Windows clients seems to work fine. – Kevin H. Patterson Nov 21 '17 at 18:07

1 Answers1

1

We never did isolate the change that gave rise to this problem, but it persists to this day. I haven’t had the time to debug it with wireshark.

My best guess as to the cause is some change to macOS stemming from an OS update. I don’t think it’s related to changing our core router, as Windows workstations using LPR still work across routed subnets.

My ultimate solution is a simple workaround. Delete the printer from the Mac, and reinstall using JetDirect or other TCP/IP socket connection instead of LPR.

Kevin H. Patterson
  • 133
  • 6