avahi-browse sometimes never stop despite terminate option

[Cyanat]

Hi!
Here is my command to debug:
avahi-browse -arpt > result.txt && wc -l result.txt

Generally, result file is generated in less than 5s with about 1150 lines, but sometimes, it seems the terminate option isn't respected and command never ends.
In that case if I CTRL+C the command after a minutes, I have about 1400 lines. More I wait, more I have lines, it make sense and the number of additionnal lines seems not to be excessives. However, I can't see why the terminate option hasn't been respected.

I'm using avahi 0.7. Unfortunatelly, I don't have opportunity to upgrade easily to 0.8, but reading the release note, I don't see a bug fix relative to my problem.

Any idea of what could be the problem?
Best regards.

[StephDC]

Take a look at the code of avahi-utils/avahi-browse.c. The flag -t would set c->terminate_on_all_for_now = 1;
This means that avahi-browse would quit upon AvahiBrowserEvent event == AVAHI_BROWSER_ALL_FOR_NOW.

I am not quite familiar with the avahi code, but looking at the following segment of code:
https://github.com/lathiat/avahi/blob/d1e71b320d96d0f213ecb0885c8313039a09f693/avahi-core/multicast-lookup.c#L118-L121

Maybe there is something that stops the avahi client from getting such event, such as having an update of list of services every second? The 1150 lines in 5s means there is a lot of services running on your large L2.

In my small L2 network, I used avahi-browser -atv to check the service, and the output ends with : Cache exhausted, and after 1 second, : All for now. My guess on your system is that during that 1s some new service popped out and causing the script to continue resolving.

[Cyanat]

@StephDC thanks for your feedback.
Using avahi-browse -atv always terminate, even if new services are detected between : Cache exhausted and : All for now.
In fact, I've noticed my problem occurs only with the r option.
My guess is that during the time needed by the system to do the resolve, there are new services detected, asking for new resolve, and so extra time is needed during which new services are detected... and loop again and again.
Also, it seems strange that with the r option, when the command terminate properly, I have first : All for now then : Cache exhausted.
it seems the only solution here is to avoid use of r option.

[evverx]

Looks like it's a duplicate of #264.

[evverx]

@Cyanat could you try the patch from #264 (comment) to see if it works for you?

[evverx]

My guess is that during the time needed by the system to do the resolve, there are new services detected, asking for new resolve, and so extra time is needed during which new services are detected

Could you paste the output of avahi-browse -arpt (and also ideally the output of tcpdump/wireshark showing incoming/outgoing mDNS packets) when it doesn't stop? This scenario is different from what #264 (comment) should fix so it would be great to figure out where it goes wrong.

[Cyanat]

@Cyanat could you try the patch from #264 (comment) to see if it works for you?

Unfortunately, I don't have enough devices in my test network to reproduce this issue, and I can't easily test it on production. Additionally, I've attempted to recompile Avahi with your patch in an Ubuntu container, but the ./bootstrap.sh command never seems to finish (sorry, I'm not very confident with building Avahi from source...).

Please find the result of my avahi-browse below and the corresponding wireshark (filtered on mdns). My avahi server is on 10.12.0.8.
Generated with command avahi-browse -arpt > result.txt && wc -l result.txt. Because command wasn't ending, I had to stop it with Ctrl+C after ~35s

result.txt
mdns.zip

Anyway, thanks a lot for your concern!

[evverx]

avahi-browse -arpt > result.txt

Could you redirect stderr to result.txt too with

avahi-browse -arpt >& result.txt

and attach it just in case? It should make it easier to spot places where resolvers fail/time out (if they fail/time out) and where other things fail.

[Cyanat]

Here it is:
result.txt

[evverx]

I took a quick look and didn't notice anything unusual. The resolvers didn't fail, avahi-client didn't hit any D-Bus limits preventing it from creating new browsers/resolvers and so on. To judge from the pcap avahi got service announcements relatively often but trying to reproduce it I bombarded avahi with much more different services (where it hit the D-Bus limits) much more often (where packets were just dropped) and couldn't reproduce it. I tested it with the master branch though where things like b3ad387 are fixed and the ALL_FOR_NOW event relies on timeouts heavily. Anyway I'll try to take a closer look at the pcap. All I can say at this point is that the patch from #264 (comment) is unlikely to fix this issue.