Thursday, 29 December 2016

Re: Using the dummy0 interface for a local-only service to be broadcasted by Avahi

On 12/29/2016 09:42 AM, Martin Pitt wrote:
> lxc/lxd used to hardcode an IP range like this, and it had to be dropped
> because it caused conflicts on "real" existing networks. The range
> is reserved and very actively being used for local networks, including
> Canonical's own VPN, and thus prone to create conflicts. If you need to do
> something like that, I don't see a way to get away with a static IPv4 address.
> Maybe IPv6 has some clever address schema that makes conflicts improbable.

Is there no way to dynamically (with checking what is currently in use)
select a small free IPv4 address space? For example in the
range there are probably only some 10.X.Y.0/24 subranges used. If not,
which IPv6 range is free for such a dummy0 interface? As it is local
only and current Linux supports IPv6 by default it would be no problem
to be IPv6-only. It would also need a host name as IPv6 IP addresses are

>> Does it cause any problems using "dummy0" for a production purpose? Is there
>> any better way? Perhaps even one which would allow me to work with
>> localhost?
> Making avahi work on 'lo' certainly sounds even nicer.

Would this be very complicated (would need upstream work on Avahi
probably)? It is said that multicast is needed and "lo" does not support
multicast. Is that true?

>> How should I implement this? Simply run above commands from maintainer
>> scripts of ippusbxd? Get them run when the first IPP-over-USB printer is
>> detected via UDEV? Or implementation in network-manager or so?
> Creating the interface in postinst is a no-go. It won't survive a reboot and it
> can't/must not be done when installing into chroots. It could ship or generate
> an ifupdown/netplan/systemd-networkd configuration file, though.


Are there packages which I could take as an example?

Another thought is an architecture extension to cups-browsed (which I
already plan for the phone):

cups-browsed will open a socket (only root can access) to receive commands.

The client which sends the commands will also be cups-browsed.

When cups-browsed is started (as root) and there is already a
cups-browsed running, it will send its command line options through the
socket to the already running cups-browsed and exit (so that only one
daemon instance is running at any time).

When cups-browsed is started (as root) and there is no cups-browsed
already running it keeps running as the current daemon instance, also
applying all its command line options.

On the Ubuntu phone this way the print dialog could tell to cups-browsed
to create a print queue to a given Bonjour service (printer) which the
user has selected, instead of cups-browsed creating automatically queues
for all printers and waking up all these printers.

For an IPP-over-USB printer UDEV would not directly call the systemd
service of ippusbxd and then cups-browsed be informed by a Bonjour
broadcast from ippusbxd, but instead, UDEV calls the systemd service o
cups-browsed with the info about the USB printer and cups-browsed calls
ippusbxd, this way knowing the printer's data and the fact that the
printer is there and so it also creates the queue. With the socket
architecture UDEV does not need to take care whether cups-browsed is
already running.


My favorite is clearly that UDEV creates ippusbxd and ippusbxd does a
local-only Bonjour broadcast so that we get a complete emulation of a
network printer. This does not require changes in cups-browsed and it
allows the use of the printer also without cups-browsed.

So I would very much like to get the local-only Bonjour broadcast
somehow working.

Best would be to be able to broadcast localhost. If not a dummy0 with a
reliable way to obtain an IP address (IPv4 or IPv6) would be great.

Thanks in advance for any suggestion.


ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: