Red Hat Bugzilla – Bug 171412
cups cupsd.conf BrowseAddress directive broken
Last modified: 2008-02-12 19:25:36 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Description of problem:
In cupsd.conf, the directive BrowseAddress appears partially broken, causing automatic advertising of printers to fail.
Raw broadcast address syntax works fine:
then after cups restart, in /var/log/cups/error_log
Sending browsing info to c0a864ff:631
That's all fine and dandy.
But the @LOCAL and @IF(eth4) type syntax doesn't work:
then after cups restart, there is no "Sending browsing info" output, and no error, and no broadcasts are sent and no printers are ever autoconfigured on other machines.
In other words, cups accepts the (as documented) syntax but then completely ignores it.
This was very frustrating when I was setting up cups and no broadcasts were being sent to my other machines as the documentation said they would be.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. put @LOCAL or @IF(eth4) in the BrowseAddress directive in cupsd.conf
2. restart cups
Actual Results: No browse broadcast is sent. No output indicating it was sent in logs.
Expected Results: Broadcast should be sent and output should indicate so.
If no one else is experiencing this, perhaps it has something to do with the fact I have an eth4 up but my eth1, 2 or 3 are all down (they are on a 4-port card, but eth4 is Gb). But cups should not require existence and "upness" of sequential interface numbers.
The other directives that allow @LOCAL and @IF also appear broken. This
includes BrowseAllow and "Allow From". Whatever subroutine does this must be
common to the lot. I'm not 100% sure on this, but my other tests seem to
indicate this is so.
Also, I'm getting very convinced it is unique to my multi-missing-eth's setup as
the directives appear to work fine on my other single interface box.
If I had the code handy I'm sure it would be an easy bug to spot -- couple lines
at most probably.
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.
Fedora Core 3 is not maintained anymore.
Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release, please reopen this bug and assign it to the
corresponding Fedora version.