patchlwIP - A Lightweight TCP/IP stack - Patches: patch #8755, Multicast DNS responder support

 
 

You are not allowed to post comments on this tracker with your current authentication level.

patch #8755: Multicast DNS responder support

Submitter:  Erik Ekman <yarrick>
Submitted:  Wed 30 Sep 2015 02:54:13 PM UTC
   
 
Category:  DNS Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Planned Release:  None

Jump to the original submission

Thu 18 Aug 2016 05:27:26 PM UTC, comment #14: 

Setting this to done and create a bug entry for the rest of the TODOs

Dirk Ziegelmeier <dziegel>
Group administrator
Mon 15 Aug 2016 08:38:15 PM UTC, comment #13: 

My work project using MDNS was abandoned/delayed, so I will not be working much more on this. I am happy to answer any questions though if someone wants to continue the effort.

Erik Ekman <yarrick>
Group Member
Sun 14 Aug 2016 01:12:04 PM UTC, comment #12: 

Applied initial patch. Work can continue with netif callback.

One TODO came into my mind: It is quite ugly that struct netif contains pointers for several protocols (autoip, dhcp, mdns..). Maybe we can come up with something better here?

Dirk Ziegelmeier <dziegel>
Group administrator
Sat 03 Oct 2015 06:54:24 PM UTC, comment #11: 

Ok, then we could add functionality to add more than one netif change handler. I would just like to keep the "core" folder small enough by holding only the base protocols. Even for traditional DNS you could argue if it's placed correctly in "core", since  it's only a UDP application after all...

Simon Goldschmidt <goldsimon>
Group administrator
Fri 02 Oct 2015 08:36:12 AM UTC, comment #10: 


>> Notifications on IP address changes/additions/removals.
>> They need to be announced to the peers, checked for conflicts etc.


>That sounds like a deep integration into the stack, as even the current status callback does not provide information on what was
>changed that triggered the callback (e.g. old address if IPv4 address was changed).


It will be enough to know that something changed, and then tell the network what the current addresses are.
This data is sent with a cache-flush instruction so it replaces earlier information.

Erik Ekman <yarrick>
Group Member
Thu 01 Oct 2015 06:52:42 PM UTC, comment #9: 


> Notifications on IP address changes/additions/removals.
> They need to be announced to the peers, checked for conflicts etc.


That sounds like a deep integration into the stack, as even the current status callback does not provide information on what was changed that triggered the callback (e.g. old address if IPv4 address was changed).

> Just build the query as usual and send it to 224.0.0.251:5353


Right, I've reopened task #10238 :-)

Simon Goldschmidt <goldsimon>
Group administrator
Thu 01 Oct 2015 02:33:21 PM UTC, comment #8: 


>To make hostname.local. resolvable with the DNS client we need to catch names which
>end in .local. and query them on the v4/v6 multicast groups and then pass the answer
>back to the client in some way. This is related to building an mDNS client that can
>find services/hosts to connect to.


Thinking about this again there is a simpler way to look up data for the .local domain as task #10238 mentions.
Just build the query as usual and send it to 224.0.0.251:5353, and all replies will come back as normal unicast packets
formatted as normal replies.

Erik Ekman <yarrick>
Group Member
Thu 01 Oct 2015 12:35:11 PM UTC, comment #7: 


>>  I will soon add timer functions and netif change callbacks.
>Using timers is OK for an app. What do you mean by netif change callbacks?


Notifications on IP address changes/additions/removals.
They need to be announced to the peers, checked for conflicts etc.

Erik Ekman <yarrick>
Group Member
Thu 01 Oct 2015 12:28:36 PM UTC, comment #6: 


>  I will soon add timer functions and netif change callbacks.


Using timers is OK for an app. What do you mean by netif change callbacks?

About the resolve integration: I saw that some PC browsers automatically try to resolve any hostname via mdns if other ways fail, but such integration might indeed not be necessary for lwip.

> I think it is needed for a switch to forward the multicast data.


That depends on the switch. Cheap switches handle all group addresses like broadcasts.

>  I don't think the membership query is used normally though,
> so maybe just a subset of it is required.


That might be worth an option...

Simon Goldschmidt <goldsimon>
Group administrator
Thu 01 Oct 2015 12:00:20 PM UTC, comment #5: 

Correct, this is the server part, to let other hosts in the local network know that a service exists and where to reach it. There were three different tasks logged before, the two others represent the client and DNS integration.

I thought about the apps thing. I will soon add timer functions and netif change callbacks. If that still is reasonable to have in apps, I am fine with a move.

To make hostname.local. resolvable with the DNS client we need to catch names which end in .local. and query them on the v4/v6 multicast groups and then pass the answer back to the client in some way. This is related to building an mDNS client that can find services/hosts to connect to.

IGMP is used to join/leave the 224.0.0.251 multicast group. I think it is needed for a switch to forward the multicast data. I don't think the membership query is used normally though, so maybe just a subset of it is required.

Erik Ekman <yarrick>
Group Member
Thu 01 Oct 2015 11:30:56 AM UTC, comment #4: 

Oh, and why is IGMP required? Just to send the join messages or does LWIP_IGMP enable anything else that is required to operate? If it's just for the join message, I'd be tempted to leave it up to the user to decide whether IGMP is enabled or not...

Simon Goldschmidt <goldsimon>
Group administrator
Thu 01 Oct 2015 11:28:19 AM UTC, comment #3: 

OK, so this is only the server part of mDNS, right? As such, it is more of an application than a core part of the stack. I'm asking this because I'm about to create an 'apps' folder. Maybe this would better fit there, too.

Keeping that aside, how would the client part be implemented if we wanted dns_gethostbyname() or getaddrinfo() to use mDNS to resolve hots names?

Simon Goldschmidt <goldsimon>
Group administrator
Thu 01 Oct 2015 07:53:07 AM UTC, comment #2: 

Yes, the main file is 2000 lines, along with 900 lines tests.

I don't know why it did not arrive in lwip-devel, that address in included in the To-header I received at least. Some emails from savannah have been marked as spam by my gmail as well lately.

Erik Ekman <yarrick>
Group Member
Wed 30 Sep 2015 07:25:56 PM UTC, comment #1: 

Yikes, a patch of 115kB! It'll take some time to check that ;-)

But it would sure be a nice feature to have!

BTW: why wasn't this patch announced to lwip-devel?

Simon Goldschmidt <goldsimon>
Group administrator
Wed 30 Sep 2015 02:54:13 PM UTC, original submission:  

Here comes my summer project..

Creating as a patch since task #10240 was closed.

I have built an implementation of multicast DNS and DNS Service Discovery to enable an lwIP node to publish its name, IP addresses and services to the local network over IPv4 and/or IPv6.

---------

Basic API usage:

Activate MDNS responder on a netif:
mdns_resp_add_netif(struct netif *netif, char *hostname, u32_t dns_ttl)

If this returns successfully, the netif will join
the multicast groups and any MDNS requests sent unicast or multicast to port 5353 will be handled:
- <hostname>.local type A, AAAA or ANY returns relevant IP addresses
- Reverse lookups (PTR in-addr.arpa, ip6.arpa) of netif addresses
  returns <hostname>.local

Then add a service:
mdns_resp_add_service(struct netif *netif, char *name, char *service,
    u16_t proto, u16_t port, u32_t dns_ttl,
    service_get_txt_fn_t txt_fn, void *txt_userdata);

If this call returns successfully, the following MDNS will be handled:
- _services._dns-sd._udp.local type PTR returns <service>.<proto>.local
- <service>.<proto>.local type PTR returns <name>.<service>.<proto>.local
- <name>.<service>.<proto>.local type SRV returns hostname and port of service
- <name>.<service>.<proto>.local type TXT builds text strings by calling txt_fn with the supplied userdata.


---------
The code attempts to minimize dynamic memory allocation and instead uses objects on the stack. It should use less than 1kB stack.

I have tried to keep the code standards, but might have missed something so give me comments on what needs to be fixed. It is quite a lot of code, I can break it up in a few commits if needed.

I moved the interesting defines out from dns.c into a dns_common.h includefile so the info does not have to be duplicated. The DNS parsing/generation in dns.c was not enough, so I have built new code for that. Maybe this new code can become a shared base for an update of dns.c.

I have written tests on DNS parsing and name compression so far, but not yet on the packet handling.

I will keep working on this code, to add conflict resolution and such things to follow most of the RFC requirements.

Erik Ekman <yarrick>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dziegel (Posted a comment)
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by yarrick (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-08-18 dziegel StatusIn Progress Done
        Open/ClosedOpen Closed
    2016-08-14 dziegel StatusNone In Progress
    2015-09-30 yarrick Attached File- Added 0001-Add-Multicast-DNS-responder.patch, #35016
        Attached File- Added 0001-contrib-Multicast-DNS-update-unittest-makefile.patch, #35017

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code