core: Zeroconf chokes: "zeroconf._exceptions.IncomingDecodeError: Bad domain name (circular)"

Choked at offset 255 while unpacking b'\x00\x00\x84\x00\x00\x00\x00\t\x00\x00\x00\x00\x08Soundbar\n_viziocast\x04_tcp\x05local\x00\x00\x10\x80\x01\x00\x00\x11\x94\x00\xb2\x14bt=00:00:00:00:00:00\x0bid=\n\x0b}\x8f\x0c\x1dL\xbc\nfver=28390\x04dt=2\x05pwr=0\x06oobe=0\x05uli=3\x05tos=0\x0ename=SB3651-E6\x07soc=MTK\x15eth=c4:1c:ff:d1:c7:09\x16wifi=a0:6a:44:25:a2:13\x0brver=V1.0.7\x0bmver=V0.8.7\x0bbver=V0.8.7\nChromecast\xc0%\x00/\x80\x01\x00\x00\x00x\x00\x05\xc1-\x00\x01@\x0230\x012\x03168\x03192\x07in-addr\x04arpa\x00\x00/\x80\x01\x00\x00\x00x\x00\x06\xc1:\x00\x02\x00\x08\xc0\x0c\x00/\x80\x01\x00\x00\x11\x94\x00\t\xc0\x0c\x00\x05\x00\x00\x80\x00@\xc0\xe8\x00\x01\x80\x01\x00\x00\x00x\x00\x04\xc0\xa8\x02\x1e\xc1\x04\x00\x0c\x80\x01\x00\x00\x00x\x00\x02\xc0\xe8\xc0\x0c\x00!\x80\x01\x00\x00\x00x\x00\x08\x00\x00\x00\x00#(\xc0\xe8\xc0\x15\x00\x0c\x00\x01\x00\x00\x11\x94\x00\x02\xc0\x0c\t_services\x07_dns-sd\x04_udp\xc0%\x00\x0c\x00\x01\x00\x00\x11\x94\x00\x02\xc0\x15'

<DNSIncoming:{id=0, flags=33792, truncated=False, n_q=0, n_ans=9, n_auth=0, n_add=0, questions=[], answers=[record[txt,in-unique,Soundbar._viziocast._tcp.local.]=4500/4499,b'\x14bt=00:'..., record[nsec,in-unique,Chromecast.local.]=120/119,,a, record[nsec,in-unique,30.2.168.192.in-addr.arpa.]=120/119,�
                                                                                                                                       �@.Chromecast.local.,ptr, record[nsec,in-unique,Soundbar._viziocast._tcp.local.]=4500/4499,Soundbar._viziocast._tcp.local.,txt|srv, record[a,in-unique,Chromecast.local.]=120/119,192.168.2.30, record[ptr,in-unique,30.2.168.192.in-addr.arpa.]=120/119,Chromecast.local., record[srv,in-unique,Soundbar._viziocast._tcp.local.]=120/119,Chromecast.local.:9000, record[ptr,in,_viziocast._tcp.local.]=4500/4499,Soundbar._viziocast._tcp.local., record[ptr,in,_services._dns-sd._udp.local.]=4500/4499,_viziocast._tcp.local.]}>

Looks like it can handle the garbage in the NSEC next name now

docker exec -it homeassistant /bin/bash
git clone https://github.com/bdraco/python-zeroconf
cd python-zeroconf
git checkout -t origin/forward_name_compression
pip3 install --upgrade .

Works like a charm, no more errors and all seems fine.

I know it’s been merged already, but just confirming it again that it worked for me. I manually updated my instance with the latest code, error is gone. Thank you @bdraco!

I’ve noticed that my Sonos Speakers on a different VLAN are now unavailable. Moving them over to the same subnet as Home Assistant brings them back in. The errors may be more than just informational?

The packets definitely have name compression pointers that are pointing forward instead of backwards.

nslookup does support this

dnspython disallows this Net::DNS disallows this zeroconf disallows this

If we were to allow name compression pointers that point forward we would have to be very careful not to create this vuln: https://www.kb.cert.org/vuls/id/23495/ aka https://nvd.nist.gov/vuln/detail/CVE-2000-0333

Deciphering what is actually supposed to happen is left as an exercise to the reader since there are places that conflict and contradict each other.

I’ve got a Mikrotik router - and never had this issue in my logs before the latest ‘upgrade’. Curious what this improvement should be then…

Probably always happening, just not being logged unlike now.

I’d prefer some error handling upstream to prevent spamming the HA logs: it’s an error in the upstream processing. HA worked fine without this functionality, so I can probably live without it.

I’d prefer not to sweep the issue under the rug as its unlikely to get fixed at the source if we silence it. Its a real problem since the packet will get dropped and something may be relying on the data in the packet.