Bug 197525 - BrowseAddress @LOCAL doesn't appear to work
Summary: BrowseAddress @LOCAL doesn't appear to work
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: cups
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-07-03 16:40 UTC by Tim
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2007-07-21 07:56:04 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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.


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