Bug 171412 - cups cupsd.conf BrowseAddress directive broken
Summary: cups cupsd.conf BrowseAddress directive broken
Alias: None
Product: Fedora
Classification: Fedora
Component: cups   
(Show other bugs)
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-10-21 16:07 UTC by Trevor Cordes
Modified: 2008-02-13 00:25 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-13 00:25:36 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Trevor Cordes 2005-10-21 16:07:10 UTC
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:
   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):

How reproducible:

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.

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.

Comment 1 Trevor Cordes 2005-10-22 00:53:50 UTC
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.

Comment 2 Matthew Miller 2006-07-10 23:26:46 UTC
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!

Comment 3 petrosyan 2008-02-13 00:25:36 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.