« Open MPI Escapes | Main | Katrina »

On CUPS, IPP, OS X, and home area networking with multiple routers

I write this up for two reasons:

  1. Someone may actually find this via google someday and find it useful
  2. So I don’t forget

It took me a while to figure out (all of which, in hindsight, makes perfect sense, of course), so if I can save myself, or someone else, some time in the future, that’s a Good Thing…


Background:

I recently got Vonage, which, for the purposes of this conversation, means that I had to add another router into my home network. This router must go right behind the DSL modem in order to guarnatee quality of service for the telephone TCP/IP traffic. However, this Vonage router (Linksys, in this case) does not have wireless capabilities, so this unfortunately means that my D-Link wireless/wired router must go behind the vonage router. It looks like this:

|-----------|    |---------------|    |---------------|
| DSL modem |----| Vonage router |----| D-Link router |
|-----------|    |---------------|    |---------------|

I’m running OS X 10.3 and 10.4 on clients, and CUPS v1.1.19 (I know, a bit old — it’s from my Mandrake 9.2 machine [it ain’t broke, so I don’t fix it]).

The Goals:

I have two routers, and I need to have clients hanging off both:

  • I have a Linux box that must be ssh-able from the outside. Hence, it really needs to hang off the Vonage router, and have port 22 port forwarded to its local IP address (more on this below — see the Hindsight section).
  • This same Linux box also has an HP printer hanging off it (local parallel connection) that all computers in my home should be able to print to.
  • I have several wireless clients in my home (laptops, handhelds, etc.).

Problems / Confusion:

The D-Link router does not allow me to disable NAT, so it must be a separate subnet from the Vonage router. This is one of the biggest problems — if I had been able to have the two routers create one logical subnet (e.g., with a default gateway from the D-Link->Vonage, and a static route from the Vonage->D-Link), all might have worked out significantly easier.

Part of my confusion was that my OS X clients used to just “find” the printer hanging off my Linux box when they were connected to the network. Once I went to this new configuration, my OS X clients would no longer “just find” the printer.

Analysis:

It turns out that CUPS (http://www.cups.org/) uses the Internet Printing Protocol (IPP) as the backbone for all of its printing. CUPS can also be setup to advertise its printers via IPP using UDP broadcasts (which my Mandrake 9.2 box did by default). This is how my OS X clients used to “just find” the printer before when they were all on a single subnet. But now that they’re on different subnets, this UDP broadcast doesn’t cross the boundaries — if I connect any client on the Vonage network (i.e., the same subnet as the Linux box with the printer and CUPS server), they “just find” the printer, as usual, and everything is fine.

However, this doesn’t help printing from the D-Link subnet (e.g., my wireless clients).

On my D-Link OS X clients, I tried manually adding an IPP printer, but that never worked. Specifically, I would enter the IP address of the Linux server (on the Linksys router) and the printer name, and then try to print something to it. OS X would try to print and then report that printing had “stopped” with no other expalantion.

Looking at the CUPS logs on the Linux server, I saw that it was replying “Hey, there’s no such printer here.” Looking even closer, it looks like the clients were posting to the URI path /ipp/<printername>, which is what CUPS was insisting did not exist. Looking further back in the logs at jobs that did succeed, I saw that they had posted to the URI path /printers/<printername>. So somehow OSX is inserting the prefix /ipp instead of /printers. How to fix this?

It seems you can’t fix it from the OSX “add printer” GUI (either 10.3 or 10.4). You have to manually edit /etc/cups/printers.conf to reflect the correct URI and then kick the local cupsd (i.e., kill -1 it). On 10.3, this seems to just cause a cupsd reload; on 10.4, you may need to wait a few seconds for the launchd to re-start the cupsd.

Once this was working, I could see that print requests were correctly spanning the entire distance from an OS X client, across the wireless, across the D-Link, into the linksys, to the Linux router, and to the CUPS server. However, jobs were still not printing. Looking at the server CUPS logs again, they were resulting in a “403” HTTP error code every time (“Access Forbidden”).

This was really werd — in my cupsd.conf file on the server, I have a block similar to:

<Location />
Order Allow,Deny
Allow from All
Deny from All
</Location>

Watching the logs server’s CUPS logs (using LogLevel “debug2”), I could see that it wasn’t barfing on the config file, and it was using the “/” Location for the permissions on this printer. But it stubbornly gave 403’s for all accesses until I deleted the Deny clause! Specifically, I had to do the following:

<Location />
Order Allow,Deny
Allow from All
#Deny from All
</Location>

And then it worked just fine (i.e., got “200” HTTP responses instead of “403”, and jobs would end up printing). According to the Apache conventions and the CUPS documentations, my first version should have worked fine — the Allow clause should be examined first and then the Deny clause should be examined. But only by not having a deny clause (effectively making an empty deny conditional) did it work. Just for completeness, I tried “Order Deny,Allow” and got exactly the same results (although that it what should have happened in that case). I tried many carefully-constructed cases (kicking the cupsd every time, of course), but could never get this to work properly until I commented out the Deny clause.

I downloaded the 1.1.19 source and had a quick gander through it. It appears to have the Right code in it for checking the Order, but it somehow appears that the parser is always reading in the file as “Deny,Allow” instead of “Allow,Deny” (I double checked that it was reading the config file that I thought it was reading by introducing syntax errors and saw that they were reported in the log). I’m not sure how this was happening, and I ran out of time before tracking down the problem in the parser. Perhaps someone else will have the time to figure this one out (I have a wholly unremarkable cupsd.conf file). And perhaps it’s fixed in later versions of CUPS (http://www.cups.org/ says that the current version is 1.1.23).

So these were the three Big Things that I had to do:

  • Manually add the IPP printer on the OS X clients by IP address and queue name
  • Manually edit the OS X client printers.conf (in /etc/cups on OS X) and kick the cupsd
  • Manually edit the server cupsd.conf file and remove the “Deny” clause

In Hindsight:

There are several other configurations that might have worked:

  • Move everything down to the D-Link and simply setup port forwarding from the Linksys to the D-Link to the host that I need to ssh to. This should [hypothetically] work, in terms of port forwarding (i.e., it will work for any real router; I’m not sure of the exact capabilities/bugs of these two broadband routers, and whether it would really work or not), and then put all hosts back on one subnet and the whole IPP UDP-broadcast-not-spanning-multiple-subnets problem goes away. I may actually try this in the near future as it would simplify a lot of things.
  • I should have been able to use LPR-style printing (CUPS supports the server-side of LPR as well) — i.e., don’t rely on IPP self-advertising printers, but rather configure the clients manually to talk to the LPR server (via IP address and queue name). However, when I tried this from OS X clients, although the print job did end up issuing on the printer (LPR doesn’t support authentication / authorization, so there were no permissions issues), somehow it ended up printing a stream of postscript text instead of the actual formatted output. I’m not sure where the translation was lost (i.e., that the printer / driver didn’t realize that the job was postscript and do whatever translation was necessary), but I abondoned this attempt because I wanted to use IPP for so that clients would automatically download the relevant PPD files from the CUPS server.

TrackBack

TrackBack URL for this entry:
https://www.we-be-smart.org/mt/mt-tb.cgi/261

Listed below are links to weblogs that reference On CUPS, IPP, OS X, and home area networking with multiple routers:

» Home LAN: followup from JeffJournal
Following up on this entry -- it seems that my "hindsight" section was correct. The simplest solution was just to put everything on the Dlink and setup double port forwarding. That is, I setup the Linksys to forward incoming port... [Read More]

Comments (2)

anoncoward:

“It seems you can’t fix it from the OSX “add printer” GUI (either 10.3 or 10.4)”

In 10.3 and 10.4 you can hold down the option key while hitting the ‘Add’ button. This gets you to the advanced panel where you can enter the URL youwant to use to connect to the printer.

In 10.4 when you add the IPP printer the /ipp suffix is not longer appended and instead it comes from the ‘queue name’ field. you can enter /printers/ there.

Arrgh!

Wish I had known that. Actually, I just tried it, and it’s slightly different for me (10.3 — didn’t try 10.4 yet). If you hold down “Option” when you click the “Add” button, you get another entry in the drop-down menu for what kind of printer you want to add named “Advanced”. If you select “Advanced”, then you can further select “Internet Printing Protocol using IPP” from the Device Type drop down, and then enter in the URI manually.

Even for being totally un-obvious and non-intuitive (grumble), it is far better than editing CUPS configuration files manually.

Thanks for the tip!

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

About

This page contains a single entry from the blog posted on August 28, 2005 12:01 PM.

The previous post in this blog was Open MPI Escapes.

The next post in this blog is Katrina.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.34