[snip the garbled Google ifconfig -a. I pasted it elsewhere for
> What netstat -nr says:
> Kernel IP routing table
> Destination Gateway Genmask Flags MSS Window
> 18.104.22.168 0.0.0.0 255.255.255.0 U 0 0
> 22.214.171.124 0.0.0.0 255.255.255.0 U 0 0
> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0
> 0.0.0.0 126.96.36.199 0.0.0.0 UG 0 0
Quote:> As you see the Net 49 is local.
> Now what I want to do in cups to broadcast into that net too.
> What I originally do not wanted to do is to set another
> ifalias of the host in the 49er network, as it seems to me to
> take another ip-number for nothing. And what I also
> not intended to do is to set up some relay-host for the browsing
> in the 49er network.
I'm not sure about your setup here. An alias on eth0:x 129.69.49.x?
You do have a route entered on that interface (eth0) but that doesn't
make it "local" in any sense I'm familiar with.
> What works on the cups server is:
> - Broadcast to the local network with
> BrowseAddress 188.8.131.52
Because this _is_ local, ie., on the subnet of eth0.
Quote:> - Broadcast to some other host in 49er network like
> BrowseAddress 184.108.40.206
This is actually a unicast to the host 220.127.116.11, I believe.
> - global Broadcast. If I rely on the routers we could use that.
> BrowseAdress 255.255.255.255
Linux doesn't like you using this address -- it will normally change
this to the local subnet broadcast address. Similar problem occurs
with DHCP clients (like Win) that boot up with this broadcast. The
"solution" in that case is to add a "host" address (on the dhcpd box)
# route add -host 255.255.255.255 dev eth0
But I don't think it will help you :( Worth a try?
> What not works is:
> - Broadcast to the other 49er local network
> BrowseAddress 18.104.22.168
Because it's not the local subnet. CUPS only broadcasts to the local
subnet and I doubt you can trick it into seeing multiple networks as
> - Broadcast to the whole class B network with
> BrowseAddress 22.214.171.124
As above -- your networks' prefix length (/24) doesn't match (/16).
Quote:> I checked these cases with tcpdump on another host so I assume that
> it not so much a problem of the receiving host, but currently
> of the sending.
As near as I can tell, it's built into the cupsd _not_ to broadcast
unsolicited packets beyond the local subnet.
The closest candidate I could locate in cupsd.conf was:
to force the packects out a particular interface (?), but an
intervening router won't forward the broadcast dst 255.255.255.255.
The built-in restriction makes sense as a wayword router could "flood"
a server broadcast onto other networks. It's also why routers don't
I'm unclear on your network layout and the position of the cups print
server in that network. You could, I think, get a server to broadcast
out each _physically_ attached interface onto the interfaces' subnets.
Otherwise, I don't think you will "trick" it into broadcasting farther
That's really the purpose of BrowsePoll and BrowseRelay: provide a
means of crossing router broadcast constraints. In fact, that's the
only way I've used cups in a multiple, routed, subneted network. It's
also the mechanism that cups uses to "find" internet printers (which
obviously could not "broadcast" their presence).
Your situation may not "fit" the cupsd default behavior and I don't
know if slp is a reasonalbe/effective solution for your needs. Cups
(according to cupsd.conf) supports it, but I'm sot sure of the details.
You can check out openslp here:
email above disabled