Bug 197525

Summary: BrowseAddress @LOCAL doesn't appear to work
Product: [Fedora] Fedora Reporter: Tim <debugging>
Component: cupsAssignee: Tim Waugh <twaugh>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-07-21 07:56:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tim 2006-07-03 16:40:14 UTC
Description of problem:
BrowseAddress @LOCAL doesn't appear to work, the server doesn't appear to the
clients in their list of printers, nor to a "lpoptions -l" query (you get a
"lpoptions: No printers!?!" error message).

Version-Release number of selected component (if applicable):
cups-1.1.23-15.4

How reproducible:
always

Steps to Reproduce:
1. Configure BrowseAddress @LOCAL
2. Restart CUPS on servers and clients
3. Try to print on a client without a specifically configured CUPS printer
  
Actual results:
No printer is found, and the default postscript printer (as offered by Firefox,
for instance) does nothing (the printer dialogue goes away, without errors, as
if the page was going to print).

Expected results:
Should be able to see the server's printer on all the clients, without any
problems, and print to it.

Additional info:
Specifying alternative BrowseAddress parameters, as per the examples in the
configuration file works fine.

e.g. BrowseAddress 192.168.1.255
     BrowseAddress 192.168.1.0/255.255.255.0
     BrowseAddress @IF(eth0)

I didn't try the other variations that are supposed to work.  I don't know if
the error's in the documentation (suggesting that you can use @LOCAL), or if the
fault's in the software (that @LOCAL should work, there).

Comment 1 Tim Waugh 2006-07-04 10:36:59 UTC
It certainly works in FC5 with cups-1.2.1-1.7.  1.2 has some improvements over
1.1 in this area -- in particular, it regularly re-scans for local network
interfaces now.

Could it be that your eth0 interface is not active until after CUPS has started?

Comment 2 Tim 2006-07-04 10:56:24 UTC
No.  The eth0 interface has been up for a very long time.  CUPS has been
restarted many time while tracing this fault.  CUPS has been left running a very
long time, without anything being fiddled with, and it still didn't work.

It'll be quite some time before I shift from FC4 to FC5.  Too many problems.

Comment 3 Tim Waugh 2006-07-04 12:06:19 UTC
Strange.  Can you attach /var/log/cups/error_log please?  Thanks.

Comment 4 Tim 2007-07-21 07:56:04 UTC
Problem ceased to occur, after some experimentation, without being able to see 
any reason why it failed in the first place.