Issues with Multicast DNS browser app in Chrome OS

[Jordan Austin]

I've noticed that there have been reports of the mDNS browser sample app not working in Chrome OS, but I've never seen an answer as to if this would be fixed or if there is a valid work around. Has anyone been able to successfully get device discovery to work on Chrome OS?

Thanks!

-Jordan

[Steven Bennetts]

I'm not familiar with mDNS, but if it requires MyIpAddress{Ex}, see crbug.com/175652

[Ben Wells]

+rockot

Ken - you know about the socket API, don't you? Any idea if there are problems with this sample?

[Jordan Austin]

When you launch the mDNS-browser app in Chrome OS you'll get a console log saying "IPv6 unsupported" which is coming out of the ServiceFinder. Seems odd to me. 

[Jordan Austin]

Just thought I'd check in to see if anyone has seen this issue on Chrome OS? I'm curious if this is a bug in Chrome OS or if this is just a bug in the mDNS-browser app itself. 

It sure would be nice if there should be a chrome.mdns or chrome.nsd API that would be a nice layer on top of the raw sockets API for device and service discovery specifically.

[Steven Bennetts]

I just tried the app on Chrome OS and it shows "no mDNS services found" when I run it on my device and click 'Refresh', even with the fix for  crbug.com/175652 applied.

If someone wants to investigate further and determine which API call specifically is failing I might be able to help design a fix for Chrome OS. We may have to do something similar to what was done for myIpAddress().

[Jordan Austin]

This isn't the only issue I'm finding, but one issue that I'm running into is that ".local" doesn't resolve on ChromeOS - It seems there isn't any zero-conf implementation on ChromeOS - so line 170 in main.js of mdns-browser won't add the DNS records so this throws the "no mDNS services found" warning. 

[Jordan Austin]

Okay my last message may have been incorrect. Here is what one of the other devs I work with found out: 

He actually was able to get the bonjour browser working as is by booting into dev mote on the Chromebook and running  the (big hammer) command:

$ iptables -I INPUT -p udp -j ACCEPT

He then ran the mDNS-browser app and it worked perfectly. It's interesting because if you look here: 

https://chromium-review.googlesource.com/#/c/169200/2/client/site_tests/security_Firewall/baseline

It looks like a patch was already applied to make this work. However it clearly doesn't work. The iptables.config shows:  # Accept inbound mDNS traffic
 iptables -A INPUT -p udp --destination 224.0.0.251 --dport 5353 -j ACCEPT

So it's strange how that's still not allowing that ip traffic. We need to figure out how we can accept the mDNS udp traffic without having to open the entire floodgate obviously.

[Mike Tsao]

Renaud and Jorge, any idea why the 224.0.0.251/32 patch isn't doing the trick?

[Jorge Lucangeli Obes]

Nope. The original CL was tested with the Cloud Print fake printer, so things should work. If we get an easy repro we can try to take a look.

[Jordan Austin]

The easiest way to reproduce the issue is try to run the mDNS-browser (chrome-sample-app) on ChromeOS. Going in and editing the iptables to allow the floodgates to open for udp with: $ iptables -I INPUT -p udp -j ACCEPT

The app will now work. 

This is not an issue on Mac OSX.

-Jordan

-Jordan
------------------
missing

design & development

[David Stanfill]

We are actively researching/interested in resolving this bug to enable our software to work properly in ChromeOS as well. We have extended the mDNS sample browser to implement complete service resolution, and it would appear that because the UDP binding is to port 0 (assigned port) return traffic from the network devices is returning to the original source port instead of port 5353 as the network devices are issuing unicast responses to the multicast query. It is possible a firewall rule with src or dst port 5353 would solve the problem though may introduce a security issue.

Binding to 5353 fails EADDRINUSE  due to mDNS service discovery implemented in Chrome already using that port, so the src/dst port same patch doesn't seem to be working.

[Jordan Austin]

Thanks for the update David, good to hear that there is attention on this. Thanks again!

To unsubscribe from this group and stop receiving emails from it, send an email to apps-dev+u...@chromium.org.

[David Stanfill]

Related to this - does anyone here know if there some reason chrome.mdns is not being exposed to packaged apps? That would seem to be the simplest way to resolve this problem and provide simple mDNS discovery to any chrome application.

[Jordan Austin]

David, I agree exposing the chrome.mdns API would be very nice, that way we're not having to roll our own using the raw socket. But would that actually solve the underlying issue? 

[David Stanfill]

In this case yes. The regression causing (at least one instance) of the bug is the addition of the chrome.mdns for internal use. Since it is binding to port 5353, we can no longer make that binding in the javascript land mDNS client and we can no longer take advantages of the multicast firewall exception that allowed responses.

I am not sure where/who to raise this issue with to try and get chrome.mdns exposed or an additional firewall rule added. While I am familiar with the underlying tech and happy to contribute to the project I am not sure what the best channel to do so would be.

[Mark Scott]

Hey Everyone,

Our team did some of the work on the chrome.mdns API.  We'd be glad to see this proceed along the path of being more openly available.  A little additional context:

• The regression was likely not caused by the introduction of chrome.mdns, but rather by the inclusion of an mDNS listener in Chrome (to support Cloud Print).  The chrome.mdns API exposed access to this, but the mDNS listener itself landed before the API did.

• For security reasons, the services that can be discovered are intentionally narrow at present.  While apps can use socket APIs anyways, extensions cannot, and since chrome.mdns was enabled for extensions we wanted to be more cautious.
  

• The API is not where it needs to be to support e.g. event pages, so we didn't feel it was stable enough that it was ready to be built on yet.
  

• The underlying mDNS listener is still a little buggy, especially on some platforms.  We've had to build a fairly significant number of workarounds at the app/extension layer to get around these.

Wez or Mark Foltz could likely provide some guidance on how to contribute to help resolve some of these - we appreciate the interest!

Mark.

[Jordan Austin]

David, thanks for the information. It looks like you're correct then in saying the way to fix this would be to have the chrome.mdns API exposed to chrome apps. 

Mark, thanks for the info on the current status of the chrome.mdns API. Hopefully we can get this hammered out so that developers can use it. I think it's a pretty essential API.

Thanks! 

[David Stanfill]

Hi Mark,

Thank you for the details, I think that brings some clarity to what will need done.

Event page support and the platform bugs are something I would be willing to tackle/put some patches together for. Do you have a list of the known bug reports or is this tribal knowledge at this point?

Can you clarify the security concerns of allowing discovery of arbitrary services? I would also like to add service resolution (zeroconf/TXT record support) to the mDNS listener and chrome.mdns API. 

Best,

David

[Jordan Austin]

Hey guys,

any update on what can be done to support multicast dns?

-Jordan

[David Stanfill]

We also remain interested in helping this move forward.

[Chris Davis]

Any chance we will see mdns exposed to chrome apps soon?  or is this a long way off?  

[Mark Scott]

I'm very sorry for having not responded to this thread.

David, the security concern on arbitrary use of service discovery is that it could be used to local known vulnerable devices (e.g. a router) that exposes a service in a particular way, and to initiate an attack against that device.  I believe there was a proof-of-concept of such an attack - I forget the router make/model, but it was a relatively popular one.  However, this was more a concern for the web (in the context of the NSD API) than it would be for apps which can already request socket permission and could already make educated guesses.  So I'm guessing this would not be blocking for opening up the mDNS API.

Our team hasn't (and still doesn't) have much bandwidth to generalize the API to support discovery of arbitrary services, but miket@, can you provide pointers/guidance to what David or others should do if they'd like to take on this task?

I'll also circle back with a few folks in our team for further thoughts on this.  Sorry again for the delays.

Mark.

To unsubscribe from this group and stop receiving emails from it, send an email to apps-dev+u...@chromium.org.

[Py Chee]

I was wondering if any progress has been made on this issue.

Thanks,Chee