MDNS and DNS Service Discovery library


#21

Correct, the library only acts as a server at the moment. I implemented the server code according to the MDNS spec:

https://tools.ietf.org/html/rfc6762

Implementing a resolve method would involve creating a query packet in the required format and then sending out to the multicast address used for MDNS. After sending you would wait for a response for a maximum of a few seconds, parsing any packets received. I would suggest following the rules described in https://tools.ietf.org/html/rfc6762#section-6.7 that talk about legacy resolvers - this avoids the need to register for multicast responses and handle lots of messages which are possibly not responses to your query. In legacy mode responders will send packets directly to your host via unicast.

As mentioned, there is probably a lot of re-usable code already in the library to help with creating query packets and parsing responses.

Mark


#22

Hello @mrhornsby,

Is there any recent known issues with the library? I’ve run the example code on my Photon and, although the http server is running fine on the hostname and port I’ve set, the service is not showing up on the Bonjour Discovery app.


#23

Hi @romulosilva,

I’ve not had anyone else report issues, but I’m not actively using this library right now so there could well be a bug.

What version of the firmware are you using? Previously updates to the firmware have broken functionality.

I suggest you have a go at running Wireshark and see whether any data is actually being sent out on the network.

Regards

Mark


#24

Hi @mrhornsby ,

I tested your library with the latest firmware and it’s working great! I do have one question though: is there a way to resolve the dns hostname by another photon in the same network?
My situation is: i have two photons that communicate with each other (one is the server and the other is the client) using the built in TCPclient library. The ip adressing is dynamic so your library is my only solution now.
So the first photon would register its hostname and the second (knowing the hostname of the first) communicates its ip address to the first.
The problem is, the tcpclient library can’t resolve such hostnames and as you probably know Wifi.resolve() fails to get the ip so the second photon couldn’t establish a connection to the first. :frowning:
I already read the comments and know that the resolve function is not implemented yet and wanted to ask if there is work in progress or hope at least that the function is there and was an idiot (the whole time) not to see it.

Cheers,
Achraf


#25

Hi @Orbinom,

I don’t believe there is any work in progress on the resolve side of things (I’m certainly not working on this right now).

As I mentioned above it shouldn’t be too much work to implement this and there is a reasonable amount of existing code in the library that could be re-used to get this working.

If you do decide to work on this I’m happy to incorporate a PR to include it in the library for others.

Regards

Mark


#26

Hi @mrhornsby, first off thank you for all your great work on this! However, I am running the stock “mdns.ino” example from your github on a Photon with latest release firmware v0.7.0, and it doesn’t seem to be working…

Nothing is showing up in a Bonjour Browser (which I have verified can detect other Bonjour devices) on my Windows 7 machine. When I inspect on Wireshark, I see two identical packets sent right after each other, both with destination 224.0.0.251 but listed as “IGMPv2” protocol instead of “MDNS”, and I don’t see the expected data in the packet.

When I visit http://core-1.local I see the “Ok!” message, so the TCPServer seems to be running fine.

Any ideas why it’s not showing up in the Bonjour Browser?

Thanks!


#27

Hi @sddw,

Thanks for your message - that looks rather interesting, I believe IGMP has a different protocol number than IP messages which might suggest that something has changed in the way UDP messages are sent from the photon. I’ve not tested this recently, but I’ll try and have a look later tonight when I’m near some hardware.

In the interim - if you want to send me (via private message) a full packet dump (i.e a copy of the hex window from Wireshark at the bottom of the capture page) of one of the packets sent to 224.0.0.251 then I might be able to help diagnose the issue.

Thanks

Mark


#28

Hi @sddw,

So I finally got to test on my hardware and it’s all working as expected with 0.7.0. The IGMP messages were a red herring as they are sent out by the TCP stack as it is joining a multicast group. I can use Bonjour Browser on Mac and successfully see the _http._tcp service listed against the photons IP.

The only thing I can imagine is that the way I have implemented MDNS is not compatible with the Windows zeroconf browser. One thing that could be preventing this is that I only support multicast responses for MDNS / DNS-SD messages and not the unicast response (which should be sent in response to a unicast question).

I will raise an issue to fix this and bring it inline with the spec - this will also help to speed up resolutions because the first query is normally asking for a unicast response which my code ignores and then my Mac waits for a second before asking the same question with a multicast response. Not sure when I’ll get around to fixing this, but I hope to get it done in the next week or two - look out for a new release of the library then to see if it helps to fix your issue.

Mark


#29

Hi @mrhornsby,

Sorry for my slow response, I made my previous post right before going on vacation and won’t have access to a Photon until next week. That is great to hear you will be making an update to the MDNS package and I will certainly be excited to try it once ready!

I have separately run a Node.js implementation of MDNS from a Raspberry Pi (which is discovered successfully in my Bonjour Browser on Windows), and while inspecting Wireshark I would see multiple “MDNS” protocol packages being sent out, which I did not see from the Photon using your MDNS library. Perhaps this is what you are referring to in bringing it inline with spec? If you believe it may be helpful I could send you the packet dumps for these messages once I am back in town?

Thanks!


#30

Hi @sddw,

I checked over the code this week and it does in fact respond to the initial unicast MDNS query, so nothing I can change there. If you want to send me details of your packet capture when your back with your photon I can certainly try and see if there is a bug or underlying issue that doesn’t effect Mac.

Mark


#31

Hi all,

Just in case anyone else is watching this discussion - I think we’ve found the issue. The library is working as expected when responding to expected MDNS, service type or instance name queries, but it doesn’t support Service Type Enumeration as defined in Section 9 of the DNS-SD spec.

I’m going to raise an issue to add this to the library, but it might be a few weeks before I get around to it.

Thanks

Mark


#32

Hi,

The library is now updated (v1.4.0) with support for service type enumeration and the ability to announce services on startup by passing true to mdns.begin(...).

Mark


#33

Hi, I tried to use your mDNS library in Particle Photon. It is working well! I have a question. How can you restart or repeat advertising?

I searched new photons with a NodeJS server. If the photon is fresh restarted, then the server gets the advertisement, everything is ok. But If I start the server later then the photon, the server does not receive any message from the photon.

Can you help me?
Roland.


#34

Hi Roland,

You shouldn’t need to restart or repeat advertising. Announcing is only done on startup as per RFC 6762 section 8.3.

It sounds more likely that your queries are not being responded to. What library are you using in node.js for mdns? Have you tried installing wireshark to see the packets being sent and received by your photon and your node.js process?

Mark


#35

Hi,

I used Bonjour at nodeJS side: https://www.npmjs.com/package/bonjour
Thats a good idea to check the packages with wireshark. Do the queries need some kind of respond from the NodeJS server?

I checked with wireshark the photon sends only one package, when its starts. If the NodeJs server is alive, it gets that package, else no

Thanks for your answer,
Roland.


#36

Hi,

I had a quick look at the GitHub source for that library - it only appears to do passive service discovery (i.e. it will only pick up announcements as devices start up).

I only had a quick check, so might be wrong.

Ideally when you ask it to browse it should send a service enumeration query (see section 9 of RFC 6763). I suggest you try an alternative library.

What platform are you on and I can at least point you to a tool that will show your photon working (i.e. responding to service type enumeration queries).

Mark


#37

Also, this library uses the underlying os implementation of dns service discovery (avahi daemon or Apple’s mDNSResponder) - I have tested both of these and the photon will respond to both name and service queries directly.


#38

Yeah, mdns library works perfectly. Thanks for your answer!

Have a good day,
Roland.


#39

Hey is there a way to resolve the HOST IP if we know their broadcast name on mDNS using this library?
I couldn’t find a solution to this anywhere.


#40

Hi @moz,

Resolve functionality isn’t currently supported (see above).

Thanks

Mark