OpenWRT and mdns

I wanted to ask what is required for my router to broadcast mdns packets on my home subnet?

I have read that I needed to install umdns, although its not clear to me whether this is a service that provides the factility to propagate broadcasts of whether it just broadcasts the route hostname.local? Interestingly I can see more devices since I installed umdns on all three OpenWrt boxes so maybe it does halp propagate the broadcasts.

The firewall ruleset on my main broadband router (Watchguard T70 running OpenWrt) is pretty much default, so anything allowed out of the LAN and nothing allowed into the WAN except for services required to establish a fibre connection with the provider. I have added only one rule to allow SIP traffic into my VOIP adapter.

I also have two WiFi APs running on OpenWrt WSM20 routers that have a wired connection into the LAN side of the main router and these have their firewalls disabled.

The problem I currently have is that although mdns-scan shows me this:

$ mdns-scan
ANABELLA._smb._tcp.local
ANABELLA._device-info._tcp.local
WiFiM2._ssh._tcp.local
WiFiM1._ssh._tcp.local
OpenWrt._ssh._tcp.local
UnoQ2Gb2._arduino._tcp.local
SpotifyConnect._spotify-connect._tcp.local
SpotifyConnect (2)._spotify-connect._tcp.local
AGABUS._smb._tcp.local
AGABUS._device-info._tcp.local
_service._amzn-alexa._tcp.local

and clearly the UNO Q is on the list, I can't connect to it using Arduino AppLab or adb. Both of these rely on the device appearing in mdns, which is apparently does.

I am also curious as to what the two SpotifyConnect devices are? Its not something I am aware of as being on my network, although I suspect could perhaps be related to Alexa devices?

I disabled ufw on my Linux laptop to make sure that it is not getting in the way.

Not sure what else I might be missing?

BTW, why does the pre-formatted text option add a blank line in after each line of text?

Just an update to this: it seems the problem is not the router but that Uncomplicated Firewall (UFW) on Linux is blocking mdns traffic despite rules being set to allow traffic for UDP port 5353 into the computer. Other non-Arduino tools (avahi-browse and mdsn-scan) seem to work fine with the existing rules. The Arduino tool requires UFW to be disabled. I am investigating further but the issue appears not to be related to OpenWrt.

That sounds plausible. mDNS discovery and the next connection are two separate things: avahi/mdns-scan can see UDP 5353 multicast, but Arduino/adb may then try a normal TCP connection to the device and UFW can still block that. I’d check the UFW log while starting the Arduino tool, and also make sure multicast to 224.0.0.251:5353 is allowed on the laptop’s actual LAN interface.

After further investigation of the matter, that is exactly what was happening.

The mdns-discovery tool that Arduino seems to request Unicast connections to ephemeral ports rather than just using UDP port 5353 and it does that on both IPv4 and IPv6. Avahi and mdns-scan are able to work with UDP port 5353 only. I did notice an iPhone trying to access port 224.0.0.251:5353 and getting blocked by UFW. I do currently have UDP port 5353 open from 'anywhere'. I added a UFW rule to allow traffic from IPv4/IPv6 UDP 5353 to ports in the range 32768-63535 and that allows mdns-scan to work, but having half the of port range open is far from ideal.