Homebridge 1.4.0, service browser and avahi advertiser

NorthernMan54 commented 2 years ago

Analysis

With Homebridge 1.4.0 and the avahi advertiser I found that my homebridge-alexa and Homebridge-automation plugins stopped being able to discover all the homebridge instances on the local network. Under the covers in both I'm using the mDNS/Bonjour browser capability of bonjour-hap to discover the _hap services.

After a lot of debugging into the issue, and sniffing of network traffic have found the trigger for issue and want to discuss solutions.

For a trigger I found that when you have alot of homebridge instances on a single host, in my case 15 + instances, the response packet from the mdns query spans multiple packets and the second packets browser response data is not including the ip addresses. The browser callback is called for each service, but the service data returned is missing the ip address details from any services in the second packet.

When I look with Wireshark, I see packets being returned, the first 1453 bytes and the second 920.

Looking at the query response packets in detail, I can see a single type 'A' record in the first packet and none in the second. Am thinking that possible some service address caching is needed.

This function does not take into account query responses that span multiple packets.

https://github.com/homebridge/bonjour/blob/eaca22a520183ceac2faa2ebd1305fbd557d327a/lib/Browser.js#L187

I was able to code a quick hacky workaround, and it did mitigate the issue, but this will take more research into what the RFC says in regards to responses spanning multiple packets.

        if(service.addresses.length) {
          console.log("Adding to cache", service.host, service.addresses);
          _addressCache[service.host] = service.addresses;
        } else if (_addressCache[service.host]) {
          console.log("Using cache", service.host, _addressCache[service.host]);
          service.addresses = _addressCache[service.host];
        }

@oznu If your using my hap-node-client you will have the same issue.

Expected Behavior

See above

Steps To Reproduce

See above

Logs

See above

Configuration

See above

Environment

OS:
Software:
Node:
npm:

Process Supervisor

systemd

Additional Context

No response

github-actions[bot] commented 3 months ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

github-actions[bot] commented 3 months ago

This issue has been closed as no further activity has occurred.

NorthernMan54 commented 2 days ago

@Supereg any comments ? Have a user reporting a similar issue https://github.com/homebridge/bonjour/issues/24

Supereg commented 1 day ago

It's been a while since I last looked into the mDNS spec. If I recall correctly, there is no requirement for a QUERY to return all associated records. E.g., here is the list/combination of additional records that might be sent as a querier would typically be interested in these: DNS Additional Record Generation:

The browser callback is called for each service, but the service data returned is missing the ip address details from any services in the second packet.

If all of these instances are running on the same host, wouldn't the A/AAAA records be the same. After all, they should share the same hostname (when using avahi, our own advertises generates hostnames for each instance as we do not have the knowledge of a host-wide advertiser).

So the problem is not Homebridge or avahi, the problem is this package (as the issue is raised correctly), as it implements a very naive browser that doesn't follow the spec. You can implement an mdns dns-sd browser in two ways:

One shot: Send a single query and listen for responses for a given time period. Take all records into account when assembling the "result".
Continuous browser: Continuously listens on the network on interested records and maintains a database cache of DNS records (to their respective ttl). When receiving a query we can contact the local cache and, if no data is found send a request to the multicast address.

This library doesn't correctly implement any of these mechanisms. It is not trivial to implement these correctly (also considering the Traffic Reduction mechanisms of mDNS). This is one of the reasons why ciao never really shipped with a browser.

Have a user reporting a similar issue https://github.com/homebridge/bonjour/issues/24

I'm not quite sure how the associated issue relates to this issue. How is the /api/accessories endpoint implement. That shouldn't involve and mDNS queries?

homebridge / bonjour