Hide Forgot
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: BrowseAddress 192.168.100.255 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: BrowseAddress @IF(eth4) 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): cups-1.1.22-0.rc1.8.7 How reproducible: Always Steps to Reproduce: 1. put @LOCAL or @IF(eth4) in the BrowseAddress directive in cupsd.conf 2. restart cups 3. 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. Additional info: 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. Thank you!
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.