Skip to content
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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

bradjc
Copy link
Contributor

@bradjc bradjc commented May 15, 2015

This PR is an update to #255. Notably, it updates resolv.c to work with avahi on Linux.

Changes:

  • Fix DNS compression.
  • 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.

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.

rklauck and others added 3 commits May 9, 2015 19:09
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.

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
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.
@vsaw
Copy link
Contributor

vsaw commented Sep 3, 2015

Thanks for the updated DNS-SD support. Where is the reference to your changes is uip-udp-packet.c?

static struct namemap names[RESOLV_ENTRIES];

#if RESOLV_CONF_SUPPORTS_MDNS
#if RESOLV_CONF_SUPPORTS_DNS_SD
Copy link
Contributor

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.

@laurentderu
Copy link
Member

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

@SSnoda
Copy link

SSnoda commented Aug 23, 2016

nice to meet u lauren!
i'm a student from chinese HIT,and i wanna use foren6 this useful tool for packet sniff

but our platform use IEEE802.15.4 in 434MHZ ranther in 2.4G HZ
however foren6 work in 2.5 GHZ in default (when we click "manage source" we could noly choose 1-24 channel)

i wonder how could i change this 2.5GHZ to 434MHZ

i really appreciate your help and hope for your reply£¡
thanks a lot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants