Resolving minwinpc.local on SoftAP

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:

• MSDN forums (same question)
• https://unix.stackexchange.com/questions/385235
• https://superuser.com/questions/1239910/multicast-dns-over-softap-on-win10-iot

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.