Bug 197525 - BrowseAddress @LOCAL doesn't appear to work
BrowseAddress @LOCAL doesn't appear to work
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Depends On:
  Show dependency treegraph
Reported: 2006-07-03 12:40 EDT by Tim
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-21 03:56:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tim 2006-07-03 12:40:14 EDT
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):

How reproducible:

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
     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 06:36:59 EDT
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 06:56:24 EDT
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 08:06:19 EDT
Strange.  Can you attach /var/log/cups/error_log please?  Thanks.
Comment 4 Tim 2007-07-21 03:56:04 EDT
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.