Repository navigation
iOS mDNS lookup fails at Starbucks #46698
Description
Splitting off from #41085
With Catalina and iOS 13, iOS mDNS lookup is reported to fail reliably at Starbucks (and presumably other public WiFi setups as well).
Marking with both 'tool' and 'engine' because it is not yet clear where the problem is.
Activity
dnfield commentedon Dec 10, 2019
A likely relevant point here is whether Starbucks wifi allows for nodes to find eachother via multicast. Some wifi networks disable this intentionally, and I would not be surprised if this is the case there.
Any volunteers to see if we can get a Starbucks to let us set up a devicelab machine there though?
zanderso commentedon Dec 10, 2019
A one-off experiment with a regular dev setup while grabbing a capture with wireshark might tell us what we need to know.
stx commentedon Dec 10, 2019
Adding on here since this is what I reported over in #41085. It has indeed failed on every public WiFi I've tried it on - dozens.
zanderso commentedon Dec 10, 2019
@stx Many thanks for the info, and for the investigation on #41085. It is very much appreciated.
stx commentedon Dec 13, 2019
New host computer, macOS version and network, on latest master, same problem.
Open hotel WiFi. LAN IP 172.20.0.20, subnet 255.255.248.0, router 172.20.0.1.
Two Wireshark captures attached. Cap 1 is much longer in case the extra network context helps. I stopped both a few seconds after
mDNS lookup failed, waiting for observatory port.mDNS_failure_1.pcapng.zip
mDNS_failure_2.pcapng.zip
dnfield commentedon Dec 13, 2019
@stx thanks for the traces, they're really helpful.
I would have expected to see traffic going over a link-local address. Here's what a successful trace looks like for me:
Note that the broadcast is going out over al ink local address and being answered from another link local address (169.254.152.106 and 168.254.74.55). I specifically set up wireshark to capture on the iPhone network interface:
Could you try a trace with those settings and post it? This should be enough to connect to a plugged in iPhone, regardless of whether it's on the same WiFi network as you or not.
dnfield commentedon Dec 13, 2019
@stx - I'm still seeing only LAN addresses (172.20.0.20) in there instead of the link-local address.
stx commentedon Dec 13, 2019
@dnfield No packets are captured with the settings you posted.
stx commentedon Dec 13, 2019
@dnfield Seems pretty obvious to me we've found the problem here - the requests are being sent over the wrong interface. Am I missing something?
12 remaining items
dnfield commentedon Dec 14, 2019
I strongly suspect that when hotspot is enabled, you don't get a link local bridge anymore. I wonder if there's some way to force that to happen, but I suspect not.
I think
flutter doctorcould be taught to look for a link local address or the iPhone USB address, and if it's not visible we could print instructions on what to do to fix it.dnfield commentedon Dec 14, 2019
I'm a little murky on how we'll determine which interface is the one for the iPhone from the tool though.
zanderso commentedon Dec 16, 2019
How about, if we have
we
throwToolExit()with instructions to disable hotspot and a link to this issue. That might be a little overfit to the situation in this issue, but I think we're pretty sure if all of those are true, the tool won't be able to make progress without help from the user.Regarding a doctor message, I'd prefer not to add a message to the doctor that causes someone with a working setup to fiddle with the network settings, and get themselves into a bad state.
dnfield commentedon Dec 16, 2019
@zanderso - I think that's close but maybe not quite it. It sounds like even with hotspot disabled, you won't get a link local bridge to the iPhone (if hot spot is available).
dnfield commentedon Dec 16, 2019
I see, we'd be guarded from this because mDNS failed.
I did a quick test with someone's phone overhere that has hotspot available.
When hotspot is enabled, we don't get al ink local adaptor. And by default, when I'm otherwise connected, that adaptor is disabled. We should look to see if there's some way we can enable that adapator (I'm thinking something like either
ifconfig upordefaultsshould be able to control that somehow).The basic problem is we can end up in a case where there's no route from the phone to the host machine - even if they're on the same wifi network, on a lot of public networks they won't be able to discover each other based on a variety of router or firewall settings.
zanderso commentedon Dec 17, 2019
After adding the error message, I've tried to capture the actionable part of this discussion in: #47224. I'll close this one in favor of that one.
stx commentedon Dec 17, 2019
@zanderso What about when Personal Hotspot is disabled and there is still no link local adapter?
Due to Catalina's default
Disable unless neededsetting.perepechin commentedon Dec 27, 2019
Hooray! It works for me with iOS 13.3 and Xcode 11.3 and VS Code. Thank you!!!
nerder commentedon Feb 18, 2020
This error also appears if you have a wrongly configured
GoogleService-Info.plistwhich is quite odd 😕darrinps commentedon Apr 5, 2020
I'm seeing what I think it this issue. Here is what I have setup.
First off when I do a "run flutter -v" I see the following:
[ +3 ms] Attempting to forward device port 51594 to host port 1024
[ ] executing:
/Users/dpsmith/Flutter/flutter/bin/cache/artifacts/usbmuxd/iproxy 1024 51594
00008020-001319C121D9002E
[ +3 ms] Failed to establish a debug connection with 00008020-001319C121D9002E
using
mdns: Invalid argument(s): Cannot find executable for
/Users/dpsmith/Flutter/flutter/bin/cache/artifacts/usbmuxd/iproxy.
[ +2 ms] mDNS lookup failed, attempting fallback to reading device log.
[ ] Waiting for observatory port.
There it just sits.
My setup is as follows:
iOS version: 13.4
Mac version: Catalina 10.15.3
Xcode version: 11.4 Build version 11E146
My Mac's Network iPhone USB has the "Disable unless needed" UNCHECKED
Note that now it is showing that iPhone USB is Not Connected even though it is connected (and Flutter sees it just fine)
Running Flutter devices I see this:
CHM-C02YT92KLVCG:flutter_test_ios_device dpsmith$ flutter devices
1 connected device:
Darrin Smith iPhone - 000... • 000...002E •
ios • iOS 13.4
HM-C02YT92KLVCG:flutter_test_ios_device dpsmith$
Running "flutter --version" I get:
HM-C02YT92KLVCG:flutter_test_ios_device dpsmith$ flutter --version
Flutter 1.12.13+hotfix.9 • channel stable •
https://github.com/flutter/flutter.git
Framework • revision f139b11 (6 days ago) • 2020-03-30 13:57:30 -0700
Engine • revision af51afceb8
Tools • Dart 2.7.2
So, I think I'm as up to date as I can get, and I think this is the same issue others have reported, but doing the steps that seem to work for some of the others so far have not worked for me.
Is there anything else I should do or something wrong I did do that I should change?
Things seem to be working perfectly for Android for what it's worth.
zanderso commentedon Apr 6, 2020
@darrinps it looks like there is a problem with downloaded artifacts:
Try deleting
flutter/bin/cacheto trigger a re-download.darrinps commentedon Apr 6, 2020
@zanderso That did it! Thanks!
lock commentedon Apr 25, 2020
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.