| 2008-01-09 16:49:37 |
Hugues Fournier |
description |
Binary package hint: cupsys
From CUPS 1.3.x, except at startup, network interfaces are not anymore polled for changes (appearance and disappearance of a network interface, and any IP address or mask change).
This means that in a CUPS configuration allowing local connection (sharing of local printer on local network), any connection from a local ip coming on an interface that appeared after CUPS startup (in my case a vpn one), is refused (403 error). And as a result, obviously, printer is not shared on the local network related to this interface.
The user has to restart cupsd in order to make cups accept connection on these new network interfaces.
Until recently this was difficult to see, because there was another problem affecting sharing in gutsy and hardy, that was necessitating a restart of cupsd (the late start of avahi, recently fixed in bug 173470 ).
I have tracked it down and in fact, the problem appeared with revision 6123 (pre 1.3.0) in cups svn trunk, that was landing a multiplatform management of poll (use of poll(), epoll(), or kqueue() depending of the platform). Part of this checkout moved the Mac OS X specific call to cupsdUpdateSystemMonitor in main.c to a select callback in sysman.c (we don't care), but in the same time it removed (inadvertantly) in main.c the set of NetIFUpdate to 1 every minute or so for all other OS (here, we care ;-) )
See:
svn diff -c 6123 http://svn.easysw.com/public/cups/trunk/scheduler/main.c (look for NetIFUpdate)
and more generally
svn diff -c 6123 http://svn.easysw.com/public/cups/trunk/scheduler/ (to check that this checkout did not reintroduced the code removed anywhere in the scheduler else (except for Mac OS X) )
svn log -r 6123 http://svn.easysw.com/public/cups/trunk/
I have reported the problem upstream on Sunday :
http://www.cups.org/str.php?L2631
with a patch :
http://www.cups.org/strfiles/2631/interface-update_v2.patch |
Binary package hint: cupsys
Problem:
From CUPS 1.3.x, except at startup, network interfaces are not anymore polled for changes (appearance and disappearance of a network interface, and any IP address or mask change).
This means that in a CUPS configuration allowing local connection (sharing of local printer on local network), any connection from a local ip coming on an interface that appeared after CUPS startup (in my case a vpn one), is refused (403 error). And as a result, obviously, printer is not shared on the local network related to this interface.
The user has to restart cupsd in order to make cups accept connection on these new network interfaces.
Until recently this was difficult to see, because there was another problem affecting sharing in gutsy and hardy, that was necessitating a restart of cupsd (the late start of avahi, recently fixed in bug 173470 ).
Fix:
I have tracked it down and in fact, the problem appeared with revision 6123 (pre 1.3.0) in cups svn trunk, that was landing a multiplatform management of poll (use of poll(), epoll(), or kqueue() depending of the platform). Part of this checkout moved the Mac OS X specific call to cupsdUpdateSystemMonitor in main.c to a select callback in sysman.c (we don't care), but in the same time it removed (inadvertantly) in main.c the set of NetIFUpdate to 1 every minute or so for all other OS (here, we care ;-) )
See:
svn diff -c 6123 http://svn.easysw.com/public/cups/trunk/scheduler/main.c (look for NetIFUpdate)
and more generally
svn diff -c 6123 http://svn.easysw.com/public/cups/trunk/scheduler/ (to check that this checkout did not reintroduced the code removed anywhere in the scheduler else (except for Mac OS X) )
svn log -r 6123 http://svn.easysw.com/public/cups/trunk/
I have reported the problem upstream on Sunday :
http://www.cups.org/str.php?L2631
with a patch :
http://www.cups.org/strfiles/2631/interface-update_v2.patch
TEST CASE:
Edit /etc/cups/cupsd.conf in order to get a basic local sharing configuration : change "Listen localhost:631" to "Port 631" and "Browsing Off" to "Browsing On"
Get your networking off to start it only after CUPS :
1) sudo /etc/init.d/networking stop
2) sudo /etc/init.d/cupsys restart
3) sudo /etc/init.d/networking start
After these restarts, any CUPS connection coming from the local network is refused if the bug is present
This can be checked from a remote box on the LAN by trying to access *more than 1 minute* after restart to http://<cupsserveripaddressonthelan>:631 , that leads to a 403 error if the bug is present.
The 1 minute wait is needed because the check for new network interfaces takes place once a minute.
Note that CUPS correctly broadcast on the local network (test: avahi-browse -k -t -v -r -a) whether or not this bug is present, but this is useless if it is refusing connections.. |
|
