Avahi/mDNS Not Working in Container

Utilizing a cups/avahi stack in the default balenalib/raspberrypi3-debian image – unable to see the AirPrint service even though it’s configured correctly.

Set up vanilla Raspberry Pi 3 with Raspbian and installed the same packages used for the stack above, and am able to see the AirPrint service from other iOS devices on the WLAN.

I think the breakdown is something to do with mDNS protocols within the container. Verified that building with a custom docker-compose.yml with the network-mode: host does not help.

Hey Will,

Do you have a minimal repro that I could run locally? If you want to just link to a GitHub repository, that would probably be easiest!

Cheers,
Trevor Sullivan

@wwalker just checking, the thing to try would be network_mode: host (with an underscore), but maybe you did this and it was just a typo on the post? If not then yes if we can get a repro to try as @pcgeek86 asked that would be great!

@chrisys – yes, I meant network_mode: host but thanks for checking!!

@pcgeek86 – here’s the repo! https://github.com/willswire/balena-cups

@wwalker Thanks! Provided I deploy that application, what would I need to do on the “client” side to reproduce the issue? Are you saying that the CUPS daemon isn’t discoverable via avahi-browse? FYI I don’t have an iOS device to test from, only Android or Windows 10 clients.

1 Like

On the client side you might be able to use something like this (disclaimer - never installed it before, but looks legit). Also looks like there is a java implementation of a mDNS zeroconf listener. Let me know if either/neither for these work.

Once deployed, a USB/network printer should be added to the container through the cups interface, and the shared option enabled.

Some progress has been made!!

After referring to a few different threads such as this one, I recognized the issue might lie between a disconnect of the services offered from within the container, and the host OS.

Since the host OS has an Avahi instance already running, cups should be able to provide the services and mark them as available by pushing them up to the host OS layer.

It seems like this is done via DBUS, so adding the required
export DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket
command to my initial startup script enabled iOS devices to recognize cups printers that had been added.

Can confirm that the issue is resolved.

Removed Avahi from the container, and established connection with host OS thru DBUS.

See GitHub here for working project: balena-cups

@wwalker thanks for following up and sharing your work (as always) - much appreciated!

Edit: I actually have a perfect use case for this so I’ll give it a try next week some time.

@wwalker does this require that you actually have a USB printer physically connected? Unfortunately I don’t have one, so it might not have worked to reproduce. Glad to see you got things working though!