No way to turn off mDNS and ssdp discovery for Chromecast support built in Chrome |
||||
Issue description<b>Version: <Kenneth, what is the frequency?></b> <b>OS: <please tell me it's not XP></b> What steps will reproduce the problem? (1) Launch Chrome (2) Monitor network traffic on ports 1900 and 5353 (3) What is the expected result? No traffic if the user do not want to use Chromecast at all. In a big corporation network where Chromecast is not used it generates unwanted network traffic. There should be an option to turn off Chromecast support so that the traffic is minimized. What happens instead? Chrome sends network request every 2 minutes to find out Chromecast devices on the network. If you multiply by the number of users in a big corporation network it's a lot of traffic for nothing. That traffic is multicast which causes WiFi to drop down to 1 Mb/s to transmit to all nodes, which means it slows down the network for everyone. Additional users have been reporting the same issue, see https://productforums.google.com/forum/#!topic/chromecast/WsbZQaDt9Q0
,
Nov 16 2016
,
Nov 16 2016
We can use chrome://flags/#media-router and turn that to off seems to solve the issue however this is not convenient when it comes to scale it to a big corporation population.
,
Nov 16 2016
There is a policy setting that you can use to control the behavior of Media Router in an enterprise, EnableMediaRouter. See https://www.chromium.org/administrators/policy-list-3#EnableMediaRouter.
,
Nov 16 2016
It would be useful to integrate Chrome/Chromium with the caching mDNS servers that may be running on the system. On Linux, we have Avahi; on Mac, there's mDNSResponder (I think Chrome does the latter already as I haven't seen traffic from Mac machines). This way, there's no need to send a discovery if an announcement from the Chromecast was seen recently. I also think that the default policy should be not to do discoveries until the user opens the Cast menu. Finally, please check whether the standalone implementation is following mDNS rules properly: can't one machine depend on the results by others? I'm seeing lots of machines in our network send the discovery query. Shouldn't it be enough that one of them do that and the others observe if there's been any reply? Given the fact I haven't seen discovery from Mac machines, this seems to be the correct behaviour.
,
Nov 17 2016
Chrome does use the platform Bonjour service in Mac. Not sure if it is feasible to use an installed daemon on Linux. Please file a feature request under Internals > Network > DNS and OS = Linux, feel free to CC me on it. For the second and third points, we do hope to further optimize the number of queries we send, assuming reliability doesn't suffer. There are some limitations of the chrome.mdns API we're working around at the moment.
,
Dec 22
What the hell ? The chrome://flags setting does not stop the mutlicasts ?!
,
Dec 27
,
Dec 27
I'm not aware of a flag that disables all multicast traffic in Chrome, as it's used by multiple features and APIs. This bug is specifically about disabling Chromecast support in enterprise networks, which we have a policy flag for per Comment #4. If you think there's a need to disable all multicast, please file a separate issue.
,
Jan 18
(5 days ago)
Disabling EnableMediaRouter has stopped the ssdp traffic from Chrome to dial-multiscreen-org for us. http://www.chromium.org/administrators/policy-list-3#EnableMediaRouter |
||||
►
Sign in to add a comment |
||||
Comment 1 by drott@chromium.org
, Nov 16 2016Components: Internals>Cast