DNSSD packet parsing failed - HassOS - RPi4

[oscarsiles]

I'm having the same issue mentioned in #307, with the addon-on logs repeating:

2023-06-12 12:03:01 core-matter-server chip.DIS[126] ERROR DNSSD packet parsing failed (for SRV records)
2023-06-12 12:03:01 core-matter-server chip.DIS[126] ERROR DNSSD packet parsing failed (for non-srv records)

I have HassOS 10.2 installed on a baremetal Raspberry Pi 4, with IPv6 enabled (obtaining the correct addresses on ethernet). Checking sysctl, the values of accept_ra and accept_ra_rt_info_max_plen are both 0 and cannot be changed.

[marcelveldt]

@oscarsiles do you have a multicast dns repeater active in your network ?

[oscarsiles]

No, I double checked on my router and it is disabled. Should it be enabled?

[marcelveldt]

No, please don't as it causes tons of issues. So I assume you have a flat network, without any VLANs etc ?

Do you perhaps have Unifi network gear ?

[agners]

The add-on (or rather the Matter stack) parses all mDNS/DNS-SD messages which it captures (it joins the mDNS multicast). Since mDNS/DNS-SD is widely used technology, it is likely that this is caused by some other (non-Matter) device.

Do you have issues with the Matter add-on which you attribute to this errors?

What would be interesting is to have a network/wireshark capture to see the exact packet which causes it (and what it's source is). It might trigger a mDNS implementation bug or it indeed is just a device which sends out broken mDNS/DNS-SD packets. If it is the latter, as long as its not a Matter device, that shouldn't be a problem really.

[oscarsiles]

No VLANs or unifi gear; it's a pretty generic network.

[agners]

Checking sysctl, the values of accept_ra and accept_ra_rt_info_max_plen are both 0 and cannot be changed.

FWIW, that is correct for HAOS as we use NetworkManager's RA implementation.

[planbnet]

Do you perhaps have Unifi network gear ?

I have the same problem and I am indeed using a Unifi Dream Router and several APs. Do you have an idea what might be causing this and how to fix it in this case?

[Poshy163]

Strange, I own a full UniFi network (router, switches and AP’s) and I have no issue with it at all?

Mind dropping what settings you have for the (you think) relative gear, and also if all of your firmware/software is updated.

[marcelveldt]

I have the same problem and I am indeed using a Unifi Dream Router and several APs. Do you have an idea what might be causing this and how to fix it in this case?

For Unifi hardware (and probably others too) you need to make sure that you do not enable it's mDNS forwarding feature as it messes with the discovery packets. Even if you do not use any VLAN's make sure that option is disabled.

Secondly my personal experience was that enabling "multicast enhancements" on the WifI network also caused stability issues, like devices going unavailable at random times or just unable to be discovered at all. As Matter and Thread are both very new, it will take time until router and firewall applications are optimized for their traffic.

If you really want to use VLAN's to get your IoT gear separated from your main network my recommendation would be to have an IoT VLAN with both the devices, the thread border routers and HA in there and not doing any mDNS routing of VLAN's. Opening a TCP port for remote access to HA is way easier and more fail safe.

Another (much easier) option is to just flatten the network and have one single LAN and only add devices you trust in there and/or protect yourself with firewalls and keep all hardware updated offcourse. I have created a separated WiFi SSID for IoT gear on 2,4Ghz only with some failsafe defaults (like disabling the multicast "optimizations") and that works rock stable.

[marcelveldt]

@oscarsiles did you discover which device on your network was broadcasting the (malformed) data ? Can we close this issue ?

[planbnet]

Disabling mDNS forwarding in my Unifi router solved the problem for me. However, shouldn't the logging be relaxed? It makes no sense to log errors that are caused by unrelated other devices with such a high frequency.

[marcelveldt]

Well, lowering the logging hides the issue so I'm not a fan of that. Better solve the issue instead of hiding it.

[oscarsiles]

I finally figured out what was causing it - disabling this addon stopped the messages: https://github.com/hassio-addons/addon-aircast . I toggled it on/off a few times and that would restart the error messages.

[marcelveldt]

Ah, thanks for reporting it back, that will help others

[akzov]

Bonjour protocol is such a nightmare to deal with. If only we could just specify the IP address to connect to.