CUPS Printing Woes with MacOSX Client and Linux Server
My spouse, Charlottte, recently ran into a problem with our printing system. She was getting the message:
Unable to connect to IPP host: Can't assign requested address.
This was weird, sine I used that printer all the time from my Linux notebook. So I undertook to troubleshoot the problem.
My home network configuration consist of a LAN with two wired machines. One of these called ccm-desktop is a Mac running OSX. The other machine is a Linux box running Ubuntu server called casa-pc. This box has a CUPS printer attached to it via a USB port. This printer is called Epson. Charlotte's notebook is a Powerbook and is on the same network.
At first I thought the problem was a DNS problem. I knew it was not a network issue, since the Powerbook's network connectivity was fine. So I checked the DNS by running:
dig casa-pc.sanpedro.tic.com
This showed the name was resolving to the correct IP address. I was puzzled, so I checked how the printer was configured on casa-pc. It tured out I had taken the DNS names out of the CUPS configuration and used IP addresses. This is not the best practice, but is fine for our small network. So the issue was not DNS.
I was frankly stumped, so I decided to see what was happening on the wire. I ran a tcpdump to see if the printer request was even sending any packets. It turns out it was not which confirmed that the connection was not even getting off the ground. I also checked the error message again. The format of the message looked suspiciously like it was an errno.h message and was generated by a call to perror which translated return codes from a system call to a human readable format. A little checking revealed the error code was typically from the connect system call and indicated an invalid socket address.
This was at least a clue. A socket address passed to connect consisted in part of an IP address plus a TCP port number. I did some more rooting around in the error messages and discovered the message was coming from the IPP backend process which is spawned by the CUPS scheduler. So it seemed obvious that the wrong socket address was being passed to the printing backend.
Since the printer was networked and was discovered dynamically by the Powerbook, I decided to run tcpdump on the IPP port in verbose mode and see what the server was passing to the client as its printers. The tcpdump command I ran was:
sudo tcpdump -i ath0 -X -s 200 broadcast and port 631 and host casa-pc
Fortunately, the IPP protocol specs are mostly ASCII, so it was easy to read the packet output. It revealed the port number in hte URI was set to "0" instead of "631". The Powerbook was receiving a URI of:
ipp://192.168.128.2:0/printers/Epson
Since I could successfully print to this printer from my Linux notebook, the problem must be in the version of CUPS running on the Powerbook. Instead of changing the port to 631, it tried to connect to port 0 which resulted in the error message and aborting the print job.
Since I could not change CUPS on the Powerbook (there were no updates to the version of MacOSX), I looked for a workaround in the server configuration. Since the Powerbook could print to a printer on another Mac running CUPS, I looked in the configuration file for clues. One difference I noted on the Mac server was the Port the CUPS server listened on was set explicitly in the configurations: e.g.
Port = 631
This was not the case on casa-pc. I let the configuration use its default port number (which is 631). After setting the Port directive to 631, I restarted the CUPS daemon and took another look at the tcpdump output. It revealed the port was now being set to 631 in the printer URI. This solved the mysterious printing problem.
I did look through the CUPS bug reports and could not find anything on this issue. Nor did a find anything on this issue in my initial Google search. I am a little surprised by this, but maybe no one else has seen this particular problem.
