2

When I connect to the Windows IoT board normally, accessing "minwinpc.local:8080" to get to the IoT device portal works fine in the same network. However, when the same is done through the built-in SoftAP (using WiFiDirectAdvertisementPublisher), the hostname cannot be resolved. The device portal is still reachable if accessed directly through the IP (by default 192.168.137.1 on SoftAP).

This behaviour can also be observed using custom services – i.e. hostname resolution only works through external networks, but not if the IoT board itself is hosting a SoftAP.

Is there any configuration that I need to apply or any settings I need to configure using PowerShell in order to enable name resolution on the SoftAP interface?

Update

Further testing:

Initial AJ_SoftAPSsid

  • Windows client: minwinpc:8080 works fine, minwinpc.local:8080 does not work
  • macOS client and Windows in VMware: minwinpc:8080 does not work, minwinpc.local:8080 works fine

iPhone hotspot with DragonBoard as client

  • Windows client: minwinpc:8080 works fine, minwinpc.local:8080 works fine
  • macOS client and Windows in VMware: minwinpc:8080 does not work, minwinpc.local:8080 works fine

Custom SoftAP hosted by DragonBoard

  • Windows client: minwinpc:8080 works fine, minwinpc.local:8080 works fine
  • macOS client and Windows in VMware: minwinpc:8080 does not work, minwinpc.local:8080 does not work, only direct access through IP works (192.168.137.1:8080).

Related questions:

Etan
  • 17,014
  • 17
  • 89
  • 148

1 Answers1

3

The windows client is automatically attempt to enrich the minwinpc:8080 to become minwinpc.local:8080. When it is a virtual client, it is dependant upon the host OSX name resolution, which doesn't do that automatic hostname enrichment upon lookup.

I see the following from: https://msdn.microsoft.com/en-us/library/windows/desktop/dd815243(v=vs.85).aspx

... In addition, SoftAP does not provide the DNS resolution. In the case where an external DNS server is not made available using Internet Connection Sharing (see the discussion of ICS below), fully qualified domain name (FQDN) resolution between any two computers or devices connected with the SoftAP, including the computer hosting the SoftAP, would only work if both entities mark the network type of the SoftAP network as PRIVATE (HOME or WORK in the network category pop-up). Since the machine hosting the SoftAP always marks the SoftAP network type as PRIVATE, only the computers or devices connected to SoftAP need to mark the SoftAP network type as PRIVATE in order for FQDN resolution to work...

Which sounds like what you are experiencing is the intended behavior of SoftAP. If you would like to see this in action, flush the dns cache on the client and then wireshark the request, on windows, you should see at least two DNS requests when attempting connections to minwinpc:8080.

Raymond Bannan
  • 86
  • 4
  • 1
    That would suggest that Windows lookups should no longer work when the wifi is set to public – however, it still works. I don't think that DNS is used underlying as nslookup on Windows fails to resolve the hostname. Could it be that Windows is using some alternate mechanism for hostname resolution, while macOS depends on the DNS resolution to be available, which is not available in SoftAP mode? –– Also strange, why does hostname resolution work on the initial AllJoyn SoftAP, and just fails when I create my own one? – Etan Aug 10 '17 at 17:28
  • Try disabling NETBIOS name resolution and see if this changes anything. – Raymond Bannan Aug 10 '17 at 18:31
  • OK. So, unicast-DNS resolves fine with ICS enabled (`dig minwinpc.local`) so in Windows, minwinpc.local:8080 now also works on Windows in VMware. However, macOS uses mDNS when the domain is local for normal lookups, and there, ICS seems to advertise using `mshome.net.` domain instead of `local.`. Therefore, on the Mac, minwinpc.local does not work yet. Any way to change Windows to use the `local` domain also for mDNS? – Etan Aug 10 '17 at 19:56
  • 1
    Hmm, maybe could add a DNS search suffix on the windows client for .local, I have no idea if that changes the mDNS search order though. – Raymond Bannan Aug 11 '17 at 18:29
  • It seems that more steps are necessary: See “To enable unicast .local resolution on a client computer” on technet.microsoft.com/en-us/library/cc708087(v=ws.10).aspx (“Connecting Macintosh OS X 10.3 and Higher Clients to a Windows Small Business Server 2003 Network”). I cannot adjust client settings here as I don’t control all the clients, and the same problem exists for iOS clients. I wonder: Why does everything work fine in the initial “AJ” onboarding SoftAP, but starts breaking in my own SoftAP? Windows clearly has the functionality of mDNS via SoftAP... – Etan Aug 14 '17 at 09:24
  • Did you ever found a solution for this problem? I'm looking for the same thing. – andy May 28 '19 at 20:55