mDNS Repeater not working since 22.1 upgrade

[surly]

Hi all:

Late last week I updated from 21.7 to 22.1.  I did an upgrade in place.  After some brief testing I did a reinstall with config import to move from UFS -> ZFS for the rootfs.   Again, other than having to separate restore zenarmor configs from separate backups everything seemed OK.

In more detailed use over the next couple of days I discovered a small handful of issues.  One is that mdns-repeater doesn't seem to be doing anything any longer.  I have - verified the config, checked that it's running, stop/start, enable/disable, uninstalled and reinstalled, rebooted firewall.  I don't see mdns-repeater logging anywhere on the system.

I have also exhaustively gone through all of the firewall rules which took me a fair bit of time to develop 18 months ago or so to allow a VLAN where my kids' devices are to cast to my entertainment devices on another VLAN.   All of the rules to allow traffic to flow between devices (printers, chromecasts, TV, AVR) seem to be working but anything requiring mDNS doesn't find anything to connect to.  On a test laptop Bonjour Browser is empty and google Chrome shows nothing available in the Cast-> function from the kid VLAN.  I see multicast traffic to UDP/5353 hitting "pass" rules on both interfaces.

One potentially different config I have that might be uncommon which arose due to the way my home LAN evolved - my main LAN is untagged and many other VLANs (including the kids) are tagged on the same physical interface.  i.e. the LAN with the devices I want to case to is on igb1 and those attempting to cast are on igb1_vlanX.  This worked prior to 22.1, zenarmor and other software is still working fine from what I can see.

Anyone else?

[meyergru]

I use mdns-repeater, too. The process was running:

Code: [Select]

#ps auxwww | fgrep mdns
root   47056   0.0  0.0  12652  2288  -  Ss   22:44       0:00.00 /usr/local/bin/mdns-repeater -p /var/run/mdns-repeater.pid ax0_vlan7 ax0_vlan108 ax0

Started without "-f", the process never outputs anything, so nothing is logged.

After I killed the process and restarted with debug on, I could see it working:

Code: [Select]

# /usr/local/bin/mdns-repeater -p /var/run/mdns-repeater.pid -f ax0_vlan7 ax0_vlan108 ax0
mdns-repeater: dev ax0_vlan7 addr 192.168.7.1 mask 255.255.255.0 net 192.168.7.0
mdns-repeater: dev ax0_vlan108 addr 192.168.108.1 mask 255.255.255.0 net 192.168.108.0
mdns-repeater: dev ax0 addr 192.168.1.2 mask 255.255.255.0 net 192.168.1.0
data from=192.168.108.80 size=120
repeating data to ax0_vlan7
repeating data to ax0
data from=192.168.7.210 size=114
repeating data to ax0_vlan108
repeating data to ax0
data from=192.168.7.210 size=114
repeating data to ax0_vlan108
repeating data to ax0
data from=192.168.108.22 size=519
repeating data to ax0_vlan7
repeating data to ax0
data from=192.168.108.81 size=41
repeating data to ax0_vlan7
repeating data to ax0
data from=192.168.108.80 size=585
repeating data to ax0_vlan7
repeating data to ax0
data from=192.168.108.23 size=481
repeating data to ax0_vlan7
repeating data to ax0

Also, my printer, as well as my AppleTV, which are both on VLAN 108, showed up on a smartphone on my guest VLAN 7, so MDNS seems to work fine here in a situation similar to yours.

Did you use hardware VLAN filtering and is your hardware capable of that? igbX usually stands for Intel hardware which should be fine?

[tracerrx]

It's also working for me across vLANS (tested connected iphone to guest vLAN and seeing management vLAN printers).  Make sure you have the vLANS you want spanned BOTH/ALL selected in the mDNS service setup!

[surly]

OK - it's not everyone so that's "good'.  NIC is i340-T4 in an Optiplex i5-3xxx box..   Will keep looking at mdns debug modes.

Thanks

[surly]

Started manually with -f and everything looks fine, but it doesn't work.  Quite the flurry of activity when I restarted the shield and TV on the other LAN.  Constant chatter from the devices on the kids LAN.  mdns-repeater says it's doing all the right things in debug mode.

No changes were made to rules or anything else when the upgrade was done.  Initially I thought everything was OK, this and one other thing only revealed themselves later.   Since then I've reviewed and, if anything, made things more permissive with additional logging.

Many thousands of permits on the "permit multicast" rules on both networks.  Without any denied traffic and with good looking debug output I'm unsure where to go from here.   

Was thinking - I do use zenarmor on the kids interface too.  I shut down the packet engine, restarted mdns-repeater to test, no change.  I did not see dmesg indicating that it took the adapter out of promiscuous mode when stopped zenarmor though so it's not quite like it was never there.

The only other thing I noticed that was off was something with wireguard site-to-site. 

[Mks]

Hi.

I had a similar issues. After restart of my managed switch it works again. I assume it was an issues with multicssts.

Br

[surly]

I had a similar issues. After restart of my managed switch it works again. I assume it was an issues with multicssts.

I was thinking something similar.  Switch reboots here have had no effect.

[meyergru]

I would try to check if the multicast traffic really reaches the clients with "tcpdump -i eth0 -s0 -vv net 224.0.0.0/4" - but that relies on a proper client.

If not, there are only so many possibilities: Firewall out rules, weird VLAN filtering, routing problems diverting the packets or a switch not forwarding multicast.

[surly]

Yes, I'll probably have to start sniffing.  Again, everything was settled and fine, the 22.1 upgrade with no other changes started it all.  Every switch in the house has been rebooted.  I'll have to keep chugging at it whenever time permits.

No 'out' rules are implemented anywhere except one on WAN to block a specific malware.  That's been in place for a few months.

I'm all ears for any ideas as to cause.

[surly]

Fixed, I think.  I have Unifi switching and AP.  Cycling the configuration in the "Block LAN to WLAN Multicast and Broadcast Data" section (contains a list of exception MAC addrs) has possibly fixed it.  All of the affected equipment had been rebooted without fixing it.

Using wireshark I had observed that that kids LAN was basically devoid of almost all MCAST traffic while on wifi.  Not even chatter amongst the various teen devices.  The LAN where castable devices reside was extremely active wired and wireless.  That made me go "hmmm", followed by "eureka".  I checked both settings related to client isolation and broadcast/multicast.

So long as this sticks and there isn't some weird interaction which confuses the Unifis, hopefully this is in the rearview mirror.