Avahi returns UTF-8 encoding error

[cbrand]

With avahi I see

server.c: Packet too short or invalid while reading response record. (Maybe a UTF-8 problem?)

Interestingly avahi can resolve the (blah.local) hostname, just can't list services

Originally posted by @ZanderBrown in https://github.com/cbrand/micropython-mdns/issues/5#issuecomment-1253917144

[cbrand]

@ZanderBrown I do not have a linux machine locally available right now which makes it a bit hard to debug so would either require to spin up a vm to check this further.

First of all I would like to know a couple of things though: Did you when testing it only install it via upip before too or did you bake it into your own micropython installation and did only upgrade it with upip because I am not quite sure when which code base it prioritizes.

Otherwise it would be great if you could tell me quickly how you test it, I would test it via avahi-browse but would like to know how you produce the avahi error on your end.

[ZanderBrown]

Right both were upip'd, and the underlying ‘firmware’ build is micropython master (with built-in mdns disabled)

It was actually two different devices, so certainly no cross-contamination between versions

The messages I'm getting are from avahi-daemon --kill && avahi-daemon --debug (in a root session), i.e. straight from the daemon itself — avahi-browse tells you nothing of course

[cbrand]

@ZanderBrown thanks for the information. I had a bit of time to look into it today and could reproduce the issue in a VM in my network.

Version 1.2.1 works now with avahi and correctly display the service via avahi-browse for me. Can you check if it fixes the issue on your end?

[ZanderBrown]

+ wlp60s0 IPv4 pico-109362                                   _myawesomeservice._tcp local
Failed to resolve service 'pico-109362' of type '_myawesomeservice._tcp' in domain 'local': Timeout

MDNS: Adding callback with id 0
MDNS: Added consumer on stopped mdns client. Starting it now.
MDNS Responder: Responding to DNS A question for pico-109362.local
MDNS Responder: Answering service record query with services _myawesomeservice._tcp.local
MDNS Responder: Answering service record query with services _myawesomeservice._tcp.local
MDNS Responder: Responding to DNS PTR question for _myawesomeservice._tcp.local
MDNS Responder: Responding to DNS SRV question for pico-109362._myawesomeservice._tcp.local
MDNS Responder: Responding to DNS A question for pico-109362.local
MDNS Responder: Responding to DNS TXT question for pico-109362._myawesomeservice._tcp.local
Task exception wasn't retrieved
future: <Task> coro= <generator object 'send_response' at 2000bc60>
Traceback (most recent call last):
  File "uasyncio/core.py", line 1, in run_until_complete
  File "/lib/mdns_client/client.py", line 163, in send_response
  File "/lib/mdns_client/structs.py", line 104, in to_bytes
  File "/lib/mdns_client/structs.py", line 104, in <listcomp>
AttributeError: 'NoneType' object has no attribute 'to_bytes'
MDNS Responder: Responding to DNS SRV question for pico-109362._myawesomeservice._tcp.local
MDNS Responder: Responding to DNS TXT question for pico-109362._myawesomeservice._tcp.local
MDNS Responder: Responding to DNS A question for pico-109362.local
Task exception wasn't retrieved
future: <Task> coro= <generator object 'send_response' at 2000b060>
Traceback (most recent call last):
  File "uasyncio/core.py", line 1, in run_until_complete
  File "/lib/mdns_client/client.py", line 163, in send_response
  File "/lib/mdns_client/structs.py", line 104, in to_bytes
  File "/lib/mdns_client/structs.py", line 104, in <listcomp>
AttributeError: 'NoneType' object has no attribute 'to_bytes'

Well, avahi-browse certainly seems to see the service now — but something still seems up

[ZanderBrown]

Aha, providing data= (I've been using this snippet for testing) seems to have everything working perfectly — which is fine, I need to provide that in my project anyway

[cbrand]

Thanks for the additional information.

I think I also found what is going on there and provided a fix in 1.2.2. Can you give it one more try? I couldn't reproduce that error state locally but am pretty sure due to the traceback that I fixed it there.

[ZanderBrown]

1.2.2 avoids the exception on device, but avahi still reports a timeout (presumably it still expects a TXT record, even if it is empty)

[cbrand]

Alright hopefully only one more :) Sorry for using you as a guinea pig:

1.2.3 now always returns a TXT record even if it is empty.

[ZanderBrown]

All looks good here

[cbrand]

Thank you very much for the avahi testing and input! I am going to close the issue. Please open a new issue if you encounter anything else.