Multicast DNS über SoftAP unter Win10 IoT

Wenn ich mein Win10 IoT-Board mit einem WLAN verbinde, kann ich von macOS aus eine Verbindung zu seinem Web-Interface herstellen http://minwinpc.local:8080. Die Auflösung des Hostnamens erfolgt über Multicast-DNS. Dies kann durch Ausführen beobachtet werden dns-sd -q minwinpc.local..

Das gleiche Verhalten kann beim Onboarding der Win10 IoT-Karte beobachtet werden. In diesem Modus wird ein Zugangspunkt wie der AJ_SoftAPSsidvon der Platine angekündigt. Nach dem dns-sd -q minwinpc.local.Herstellen der Verbindung löst sich die IP-Adresse erneut auf, und der Zugriff auf http://minwinpc.local:8080Mac OS funktioniert einwandfrei.

Interessant wird es jedoch, wenn ich das Win10 IoT-Board manuell in den SoftAP-Modus versetze, z. B. mit einer benutzerdefinierten UWP-App (durch Powershell habe ich keine Möglichkeit gefunden, gehostete Netzwerke direkt zu verwenden, es scheint nur WiFi Direct zu unterstützen).

WiFiDirectAdvertisementPublisher^ p; p = ref new WiFiDirectAdvertisementPublisher(); p->Advertisement->ListenStateDiscoverability =  WiFiDirectAdvertisementListenStateDiscoverability::Intensive; p->Advertisement->IsAutonomousGroupOwnerEnabled = true; p->Advertisement->LegacySettings->IsEnabled = true; p->Advertisement->LegacySettings->Ssid = L"My-SSID"; PasswordCredential^ password = ref new PasswordCredential(); password->Password = L"123456789"; p->Advertisement->LegacySettings->Passphrase = password; p->Start(); 

Dann füge ich die App zum Autostart ( iotstartup add headless) hinzu und starte neu.

Wenn ich mit dem normalen WLAN auf das Gerät zugreife, verhält sich alles wie zuvor. Wenn ich mich jedoch mit dem benutzerdefinierten SoftAP verbinde, kann ich die Adresse nicht mehr auflösen, da Multicast-DNS nicht mehr ankündigt. Interessanterweise kann ich, wenn ich einen dedizierten Windows-Client (keine VM auf einem Mac) verwende, immer noch auf http://minwinpc.local:8080und zugreifen http://minwinpc:8080. Gemäß dem MSDN-Artikel, der in https://stackoverflow.com/a/45619667 verlinkt ist, handelt es sich hierbei um das erwartete Verhalten ( [...]. Außerdem stellt SoftAP keine DNS-Auflösung bereit. [...] )

Eine Problemumgehung, um die DNS-Auflösung wiederherzustellen, ist das Aktivieren von ICS. Wenn ich dies vom IoT-Windows-Geräteportal aus mache, starte ich neu und trete mit macOS dem SoftAP bei, ich bekomme tatsächlich 192.168.137.1 (das IoT-Board) als DNS-Server. Ich bekomme auch die Suchdomäne mshome.net.

Wenn ICS aktiviert ist, ändert sich das Verhalten auf zwei Arten:

• Zunächst scheint Unicast-DNS jetzt zu funktionieren (Unicast-DNS funktionierte zuvor weder im ursprünglichen AJ_SoftAPSsidWLAN noch im normalen WLAN).

dig minwinpc.local. @192.168.137.1

;; QUESTION SECTION: ;minwinpc.local. IN A  ;; ANSWER SECTION: minwinpc. 0 IN A 192.168.137.1 minwinpc. 0 IN A 172.20.10.7 

Darüber hinaus minwinpc.mshome.net.wird auch beworben.

;; QUESTION SECTION: ;minwinpc.mshome.net. IN A  ;; ANSWER SECTION: minwinpc.mshome.net. 0 IN A 192.168.137.1 

Dies bedeutet, dass ich jetzt http://minwinpc.mshome.net:8080von macOS aus zugreifen kann . Es bedeutet auch, dass ich http://minwinpc.local:8080von Windows aus in VMware zugreifen kann . Für beide Plattformen kann ich sogar verwenden, http://minwinpc:8080da die Suchdomäne diese automatisch umleitet http://minwinpc.mshome.net:8080.

Das große Problem hierbei ist jedoch, dass http://minwinpc.local:8080macOS nicht funktioniert. Dies liegt daran, dass die .localDomäne über Multicast-DNS abgewickelt wird.

• Die zweite Änderung bei aktiviertem ICS betrifft Multicast-DNS. In der Tat, dns-sd -q minwinpc.mshome.net.löst mit ICS, aber dns-sd -q minwinpc.local.funktioniert überhaupt nicht.

Wenn ich meinen eigenen Dienst bei registriere DnssdServiceInstance, wird dieser jedoch auf der Domain local.angezeigt, wenn mit dns-sd -B _mycustom._tcpstatt mit durchsucht wird mshome.net..

Als ich den Namen auf den Dienst unter Verwendung zugewiesen lösen dns-sd -L myname _mycustom._tcp, obwohl, erhalte ich die minwinpc.local.Domain, obwohl ^ _ ^: myname._mycustom._tcp.local. can be reached at minwinpc.local.:12345 (interface 5).

Was problematisch ist, weil minwinpc.local.in Multicast-DNS nicht ordnungsgemäß angekündigt wird ( minwinpc.mshome.net.stattdessen) und Unicast-DNS von macOS für die local.Domäne nicht gefolgt wird .

Letztendlich kommt es auf diese Frage an:

• Wie kann ich lokales Multicast-DNS an der SoftAP-Schnittstelle zum Laufen bringen?

Multicast-DNS funktioniert gut über das anfängliche AJ_SoftAPSsidOnboarding-Netzwerk und funktioniert gut, wenn ich die Karte mit demselben WLAN wie mein MacBook verbinde. Es funktioniert überhaupt nicht über SoftAP ohne ICS. Mit ICS wird auf einer anderen Domain als local.

Haftungsausschluss: Bitte beachten Sie, dass alle diese Schritte beim aktuellen Win10-IoT etwas flockig sind. Es ist viel Geduld und ein Neustart erforderlich. Das MacBook sollte zusätzlich zum WLAN nicht über Ethernet angeschlossen werden, um den Auflösungsprozess nicht zu beeinträchtigen.