-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for DNS Service Discovery #1070
base: master
Are you sure you want to change the base?
Conversation
SRV, PTR, TXT record - support. Major refactor.
DNS compression uses a byte that starts with two 1s to denote that compression should start. The existing code only did an AND with 0xc0 to check for this, which also matches 0x7x. This adds explicit verification that the top two bits are 1.
This commit updates resolv to more robustly support DNS Service Discovery. It also is interoperable with avahi on Linux. Changes: - Keep explicit tables of the services the node provides, the services the node is trying to discover, and services that the node knows others provide. This is necessary because more than one device can support the same service. - Update the packet formats to be standards compliant. - Provide the "_services._dns-sd._udp.local" PTR so that avahi knows that the services the node has exist (and will show up in `avahi-browse --all`. - Handle packets when other devices ask if the node supports a given service. - Properly parse PTR, SRV, and TXT packets to discover devices that support a given service.
Thanks for the updated DNS-SD support. Where is the reference to your changes is |
static struct namemap names[RESOLV_ENTRIES]; | ||
|
||
#if RESOLV_CONF_SUPPORTS_MDNS | ||
#if RESOLV_CONF_SUPPORTS_DNS_SD |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Further down below you seem to prefer #if RESOLV_CONF_SUPPORTS_MDNS && RESOLV_CONF_SUPPORTS_DNS_SD
. I suggest to be consistent by using either or the other.
We have been using this PR in 6LBR since a few months now (but only the advertising part) and it seems quite stable. 👍 for me once the few remarks are closed |
nice to meet u lauren! but our platform use IEEE802.15.4 in 434MHZ ranther in 2.4G HZ i wonder how could i change this 2.5GHZ to 434MHZ i really appreciate your help and hope for your reply£¡ |
This PR is an update to #255. Notably, it updates resolv.c to work with avahi on Linux.
Changes:
the node is trying to discover, and services that the node knows
others provide. This is necessary because more than one device can
support the same service.
that the services the node has exist (and will show up in
avahi-browse --all
.service.
support a given service.
Testing
I have tested this by using the minimal-net platform and avahi as the service provider (with udp-client) or listener (with udp-server).
Notes
I cannot get this to work without hacking
uip-udp-packet.c
. See #255 (comment) for the long explanation, but it basically boils down to a problem with resolv.c building packets in uip_appdata, which the UDP library then takes and copies into the same memory, causing problems. Any help would be appreciated.