[English]Ich stelle mal ein Problem hier im Blog vor, auf das ich beim Stöbern in Microsofts Answers-Foren gestoßen bin. Auf manchen Systemen kommt es vor, dass Clients nach dem Upgrade auf Windows 11 24H2 kein Netzwerk, weder per LAN noch per WLAN erhalten. Ursache ist ein fehlender Gateway-Eintrag, der auf Grund eines Bugs vom DHCP-Server nicht angefragt werden kann. Es hilft auch nicht, das Gateway manuell einzutragen, da es nach dem Neustart wieder verloren geht. Abhilfe scheint ein Update vom November 2024 zu bringen.
Anzeige
DHCP bei Windows
Das Dynamic Host Configuration Protocol (DHCP) ist ein Kommunikationsprotokoll, welches auch in Windows zum Einsatz kommt. Über das Protokoll kann ein Windows-Client die IP-Adresse und die Netzwerkkonfiguration von einem DHCP-Server beziehen.
Windows 11 24H2: Kein Netzwerk
Mitte Oktober 2024 hat sich ein Administrator im Microsoft Answers Forum für Windows 11 für IT Pros gemeldet und berichtete im Thread Win11 24H2 – DHCP issue – no Gateway über Probleme in seiner Umgebung. Er versuchte in Testgruppen einige Clients auf Windows 11 Version 24H2 zu aktualisieren.
Dabei ist er in einen merkwürdiges Problem gelaufen: Manche dieser Windows 11 24H2-Clients bekamen im Anschluss kein Netzwerk – weder per LAN noch per WLAN. Die Installation von Windows 11 24H2 wurde sowohl per WSUS als auch direkt mit einem USB-Stick getestet.
Das merkwürdige: Es betrifft nicht alle umgestellten Clients, aber der Administrator rauschte mit fünf Maschinen seiner Testgruppe in dieses Problem. Die gleichen Maschinen mit Windows 11 23H2 zeigten dagegen keine Probleme. Es deutete sich an, dass dieses Problem mit Windows 11 24H2 zusammen hängt, welches ja am 1. Oktober 2024 erst freigegeben wurde.
Anzeige
Fehlerursache: Kein DHCP-Gateway-Eintrag
Eine Analyse der betroffenen Clients ergab sehr schnell, dass das Gateway in der Netzwerkkonfiguration der betreffenden Windows 11-Maschinen fehlte. Man kann das Gateway zwar manuell eintragen, dann funktioniert alles. Aber nach einem Neustart war der Eintrag für das Gateway wieder weg.
Der Administrator schrieb, dass man DHCP-Server verwende und alle Einstellungen geprüft und für in Ordnung befunden habe. Die Konfiguration war vollständig, d.h. IP, Maske, DNS-Server sind korrekt eingetragen – nur das Gateway fehlte in der Netzwerkkonfiguration. Der Versuch, den Netzwerkstack mittels der Konsolenbefehle ipconfig /release oder /renew zurück zu setzen, halfen nicht. Wireshark zeigt nichts Auffälliges.
Ein weiterer Administrator bestätigte dieses Problem, und schrieb, dass sie es in ihrer Umgebung beobachteten. Das Einzige, was funktionierte, bestand darin, statische IP-Adressen an den Clients zuzuweisen. Dann funktionierte das Netzwerk einwandfrei, aber wenn er die Clients entfernte, kann dieser Rechner keine Domänen-IP-Adresse mehr empfangen.
Der Betroffene vermutete ein Problem bei der Authentifizierung in einem Domänennetzwerk, was auch für der Domänen-WiFi-Verbindung zutraf. Denn er konnte eine Verbindung zum Gast-WiFi-Netzwerk herstellen und erhielt Internetzugang. Auch sein Mobiltelefon als Hotspot verwendet, ermöglichte einen Internetzugang.
Ein weiterer Betroffener hat das Ganze dann analysiert und Wireshark verwendet, um den DHCP-Verkehr zwischen einem 23H2-Computer und einem 24H2-Computer zu untersuchen. In seiner Umgebung werden Benutzerklassen-IDs verwendet, damit die Rechner ein Gateway erhalten, um Benutzer davon abzuhalten, persönliche Geräte anzuschließen. Das Upgrade auf Windows 11 24H2 bewirkte, dass diese Client die DHCP-Erkennungsanforderung ohne die Benutzerklasseninformationen sendete, was zu den Problemen mit der DHCP-Verarbeitung führte.
Eine Lösung wurde gefunden
Die Diskussion mäanderte im MS Answers-Forum seit Mitte Oktober 2024, ohne weitere Rückmeldung Microsofts. Zum 5. Dezember 2024 hat sich ein Nutzer gemeldet und schrieb, dass er eine Lösung gefunden habe. Das Update KB5046617 für Windows 11 24H2, welches zum 12. November 2024 freigegeben wurde, habe in seiner Umgebung dieses Problem behoben. In der Tat heißt es im Support-Beitrag:
- [Internet connection] Fixed: A small number of devices cannot connect to the internet. This occurs when a DHCP server response has duplicate DHCP options. This stops IPv4 connections on certain networks.
Vielleicht hilft es weiter, falls jemand aus der Leserschaft in einer Unternehmensumgebung von diesem Problem betroffen ist.
Anzeige
Was für ein Gateway? Wenn man DHCP mit einem DHCP-Server macht, der in einem anderen Subnetz steht, muss man für das Client-Netz im Routing ein entsprechenden DHCP-(IP-)Helper- bzw. DHCP-Relay-Eintrag (der eine Hersteller bezeichnet es so, der andere so, gemeint ist aber das selbe) anlegen, damit DHCP-Anfragen zum DHCP-Server weitergeleitet werden. Das macht man normalerweise auf dem Switch oder Router, welcher im Client-Netz als Gateway fungiert.
Ich glaube du denkst gerade in die falsche Richtung. Wenn ich das richtig verstanden habe ist das Problem, dass der Client per DHCP eine IP bekommt, aber die Option für das Gateway nicht übernommen wird bzw. seine Benutzerklassen-ID nicht sauber sendet und somit der DHCP kein Gateway liefert, da dort wohl nur bekannte Geräte eine Gateway bekommen sollen.
Das hat nichts mit DHCP-Helper zu tun, das ist eine andere Baustelle.
Habe ich auch erst nicht ganz verstanden. Gemeint ist aber sicherlich, dass die Clients kein Standard-Gateway bekommen. Daher "kein Netzwerk"…
So ist es imho.
Das wäre aber die Trivial-Situation, die jeder in seinem Heimnetz hat. Kann mir irgendwie nicht vorstellen, dass Microsoft so einen Trivial-Fehler übersehen könnte? Sind ja sicher schon ein paar Millionen 24H2 Installationen "da draußen"… Also entweder passiert es unter nur ganz speziellen/nicht so häufig anzutreffenden Umständen (bestimmte Netzwerkkarte, Treiberversion oder mit einem bestimmten DHCP-Server) oder es ist was anderes.
steht doch im Artikel
[Internet connection] Fixed: A small number of devices cannot connect to the internet. This occurs when a DHCP server response has duplicate DHCP options. This stops IPv4 connections on certain networks.
Auch ohne Gateway ist selbstverständlich "Netzwerk" möglich. Allerdings nur im eigenen Netz.
"Ursache ist ein fehlender Gateway-Eintrag, so dass der DHCP-Server zur Zuteilung der IP-Adressen und Netzwerkparameter nicht angefragt werden kann. "
Wenn ein DHCP-Discover abgesetzt wird, kennt der Client noch kein Gateway und braucht es dafür auch gar nicht. Das bekommt er erst genannt, wenn die Abfrage erfolgreich war.
Alles sehr verworren…
ein NetzWerk funktioniert ganz prima auch ohne Gateway.
man kommt halt nicht aus seinem Segment raus. Die billigste Firewall.
Um den DHCP Server zu erreichen braucht man natürlich kein Default Gateway, denn dieses kommt ja erst in der DHCP Antwort..
gell?
eigentlich müsste das ja schon beim Schreiben der Überschrift aufgefallen sein, wenn man die geringsten Grundlagen der Netzwerk Technik kennt, wo von ich eigentlich beim Autor ausgegangen war.
es wird doch kein Klick bait sein ala "Mann beißt Hund" weil "Hund beißt Mann" niemanden interessiert?
oder wird sich hier auf llm verlassen, das gerne mal Ursache und Wirkung verwechselt?
die Überschrift ist irreführend
[Internet connection] Fixed: A small number of devices cannot connect to the internet. This occurs when a DHCP server response has duplicate DHCP options. This stops IPv4 connections on certain networks.
Ok wieso schickt ein DHCP Server überhaupt Duplikate? Und vor allem, warum hat Windows in der Vergangenheit Duplikate zugelassen und jetzt wieder?
Wäre es nicht sinnvoller den DHCP Server soweit zu bringen, dass er keine Duplikate schickt?
Der Windows DHCP Client scheint sich an doppelten DHCP Optionen zu verschlucken.
möglicherweise widersprechen die sich. Aber eigentlich sollte der Client damit zurecht kommen…
im Eventlog scheinen keine Probleme hemeldet zu werden?
Es ist aber ziemliches stochern im Nebel.
Die DHCP Antworten scheinen OK
zu sein wie eine Analyse mittels wireshark ergeben haben soll.
das Problem tritt auch bei frisch installierten Clients auf.
Bisher hat das DHCP funktioniert.
Erst mit dem Update wird der Effekt sichtbar.
das liegt dann wohl am Update…
es ist eigentlich der Job von MS das Problem zu lösen, oder ist das ne Beta Version?
wozu braucht MS denn die Telemetrie Daten?
Kann es vielleicht sein, dass in dem Netz zwei DHCP-Servers sind? So, dass sie die gleiche Konfiguration verwenden? Aber auch das müsste gehen, wenn man es richtig macht, habe ich zuhause so am Laufen, damit im Fall dass der Router mal ausfällt, dass ich aus einem anderen (kleineren) Bereich des gleichen Subnetzes wenigstens eine IP bekomme (DNS- und Gateway-Angaben sind gleich), um eine Chance zu haben, mal zu gucken, was der Router so treibt. Die beiden DHCP-Dienste beschweren sich natürlich in ihrem Log, dass jeweils der andere die DHCP-Anfrage schon beantwortet hat. Meistens gewinnt bei mir aber der Hauptrouter, weil er am kürzeren Ende des Netzes ist.
Server und Bereichsoptionen?
an sowas dachte ich auch, das bereichsoptionen server optionen overrulen sollten, was ja legitim wäre. nur Windows verhaut es dann
Üblicherweise probed ein DHCP mit ICMP Ping, ob auf einem DHCPDISCOVER eine per DHCPOFFER angebotene IP bereits vergeben ist. Ein Client sammelt daher erstmal alle Antworten auch doppelte, bis zum finalen DHCPREQUEST der dann am Server mit DHCP ACK oder NAK beantwortet wird.
Im RFC steht ferner, dass ein Client ein Check ausführen sollte (SHOULD) z.B. mit Abgleich der ARP Tabelle. Scheint hier nicht erfolgt zu sein, sonst dürfte das Interface diese Config ohne Gateway gar nicht erst übernehmen dürfen.
Der Fehler dürfte symptomatisch für das Spielzeug-Produkt Windows und die Bude Microsoft sein, wenn im Jahre 2024 solche jahrzehntelangen Internet-Grundlagen nicht sauber implementiert werden und es auch noch in ein finales Produkt schaffen.
Seit wann ist dem DHCP-Client angeraten, den Gateway zu prüfen? Dieser Teil der RFC wäre mir jedenfalls neu.
Ausserdem denke ich, dass die doppelten Einträge in der einzelnen DHCPOFFER waren, denn der Client merged die verschiedenen Antworten nicht – er entscheidet sich für Eine (mEn die Früheste).
Letztens: Eine DHCP-Config ohne Gateway ist zwar eher unüblich, aber zulässig und in der Praxis auch funktional.
Schau doch bitte ins RFC:
"The client receives the DHCPACK message with configuration parameters. The client SHOULD perform a final check on the parameters"
> Letztens: Eine DHCP-Config ohne Gateway ist zwar eher unüblich, aber zulässig und in der Praxis auch funktional.
Hat aber offensichtlich kaum was mit diesem Problem zu tun, denn ich denke eher nicht, dass eine Fritzbox plätzlich Ihr Gateway nicht propagiert. Dann schon eher, dass Windows 11 einfach nur scheiße baut.
Der DHCP Client von Windows befolgt also genau die RFC, er checked die Optionen, die passen nicht, er wendet sie nicht an.
Das wissen wir nicht ohne die Datenpakete gesehen zu haben. Eine DHCPOFFER darf durchaus mehrere Gateways beinhalten.
Das betrifft Validität der einzelnen Parameter und bezüglich Gateway sagt die RFC nichts (wäre für Sie also ein aktuell nicht erreichbarer Gateway nicht zu übernehmen (und wenn nein: Warum?!)?).
Man kann die F!B und andere DAU-Router nicht so konfigurieren (einfach weil es die GUI nicht hergibt und kein CL-Zugang besteht), bessere DHCP-Server (inkl. OpenWRT) hingegen schon.
Von der F!B war im Artikel übrigens keine Rede.
Das wirkt mir alles irgendwie komisch…
Zum einen – was hat das Gateway mit DHCP bzw. das beziehen der IP mit dem Gateway zu tun? -> nix. Auch die Beschreibungen im MS Forum sind technisch quatsch.
Ja, man kann sicher Policys nutzen um via User Class bestimmten Geräten mit diesem Eintrag eben andere Optionen zu geben, aber welchen Sinn hat es, die Verteilung des Gateways da dran zu knüpfen? DHCP ist nix was wirklich manipulationssicher ist. Also die Pakete zumindest. Heißt also, wenn man aus Sicherheitsgründen?? Clients nur ein Gateway gibt, wenn dieser String gesetzt ist, bringt das genau was, wenn ein unbekanntes Gerät einfach statisch IPs vergeben kann? Nix… Sicherheit gibts nur mit Authentifizierung. Und das hat nix mit dem Gateway zu tun.
Was mich auch wundert – es wird von Update auf 24H2 geschrieben. Möglicherweise ist einfach der Grund gar nicht DHCP oder das Gateway, sondern die Art und Weise, wie diese User Class auf den Client kommt. Sprich ist die User Class nach dem Update überhaupt noch gesetzt?
Meiner Ansicht nach ist das alles ultra wischi waschi beschrieben und es fehlen so ziemlich alle troubleshooting Steps um das Problem in der Quelle einzugrenzen. Ja, es mag der Gateway Eintrag schuld sein, dass keine geroutete Verbindung zustande kommt – aber der fehlende Gateway Eintrag ist nicht die Ursache des Problems. -> leider kommt das irgendwie stark zu kurz.
Um es nochmal in Klartext zu sagen. Vor allem weil Leute auch hier schon wieder Verschwörungen zu der Unfähigkeit von Microsoft spinnen… Es gibt aktuell kein globales Problem. Der Fehler trifft bestenfalls in Sonderkonstellationen zu und auch in der beschriebenen Form – User Class ist leer beim DHCP discover ist mMn klar fraglich, warum man im DHCP Server kein Gateway senden soll(te), wenn der Eintrag fehlt. Es kann natürlich sein, dass der Client aufgrund eines Fehlers in der Implementierung für DHCP Responses generell ein Problem hat, wenn da irgendwas mit User Classes passiert, kein Gateway setzen zu wollen/können -> aber das ist schon wieder eine Interpretation, denn das steht in der Quelle im MS Forum so nirgendwo. Das steht, die User Class wird nicht gesendet. Nichts davon, dass im DHCP Response das Gateway gesetzt ist, aber der Client es nicht verarbeitet. Wahrscheinlich viel Wind um nix…
Viel Text! Ich kann es als nicht Betroffener nicht genauer präzisieren, sondern arbeite mit dem, was an Infos da ist.
Was ist denn Fakt? Es gibt Leute, die Probleme wegen fehlender Gateway Einträge in AD-Umgebungen feststellen. Im November 2024 Update ist laut MS was in diesem Bereich korrigiert worden. Ein Betroffener schreibt, das November Update habe geholfen.
Was folgt? Nicht betroffen? Gehen Sie weiter, es gibt nix zu sehen…
Betroffen – das Update installieren und testen. Fehler weg, dann freuen und habe fertig.
Fehler noch da? Zurück auf los.
Lebbe kann so einfach sein … oder was verstehe ich nicht
Wäre toll, wenn ein Betroffener die Datenpakete so einer fehlerbehafteten DHCP-Aushandlung aufzeichnen und uns verfügbar machen würde.
Ich habe den MS Answers-Forenbeitrag ja verlinkt – magst Du da mal nachfragen – vielleicht hat der eine Betroffene, der mit Wireshark unterwegs war, die Aufzeichnungen noch. Meine Sichtweise hatte ich ja in einem anderen Kommentar auf den Punkt gebracht: Es gibt einen Patch von November 2024, der laut Microsoft und Betroffenen das Problem löst. Aus diesem Blickwinkel ist die Diskussion was genau Phase ist, lediglich Nabelschau – auch wenn ich euch verstehe. Aber ich persönlich mag mich da nicht rein hängen – ich habe hier genug offene Baustellen, wo ich mich kümmern, nachfassen und für den Blog dann aufbereiten muss/will/darf.
Was ich damit meine ist eher, dass nicht überall, wo ein Problem gerochen wird, auch wirklich ein Problem drin ist. Natürlich hat Microsoft da irgendwas mit DHCP im Namen gefixt, nicht näher beschrieben ist das leider auch bei denen nicht ganz nachvollziehbar was nun genau. Die Frage ist ob das überhaupt einen Zusammenhang hat…
Die Thematik, dass die Erklärungen der betroffenen irgendwie allesamt technisch Quatsch sind und sonstwas für Gründe zu dem Verhalten geführt haben können, gepaart mit dem Umstand das einige? der Leute dort dann meinen, ein/das Update fixt ihr Problem, was letztlich aber ebenso nix mit dem ursprünglich beschriebenen Thema zu tun haben muss, macht das ganze doch stark undurchsichtig.
Wie gesagt, was mich wundert, dass eben bei mindestens einer der Aussagen User Class Einträge nicht richtig oder gar nicht gesetzt sind und auch nicht übermittelt wurden -> was erstmal natürlich ein Thema sein kann – aber warum zur Hölle wird dem nicht nachgegangen? Also nachgegangen im Sinne von, ja die Einträge sind gesetzt, die Einträge sind auch angekommen, wenn man es neu setzt, kommt es an usw.
Was ich hier einfach herauslese ist, dass der Betreiber des DHCP Systems eine warum auch immer existierende Policy geschrieben hat, die bei keinem oder falschem User Class Attribute eben kein Gateway zurück liefert. Das ist das, was da steht. Das heißt aber eben dann auch, das Verhalten ist offenbar so gewollt? Ergo also kein Problem?
Fragezeichen habe ich auch bei der Art und Weise des Updates.
– Fresh 24H2 von der grünen Wiese?
– Update einer 23H2 oder älteren 11er Version?
– Update einer 10er Version?
-> wie wurde geprüft ob die User Class Einträge gesetzt sind bzw. wurde das überhaupt geprüft?
-> natürlich, wenn nach einem Update das 24H2 via Rollback runter geputzt wird zum alten Zustand, geht es ziemlich sicher auch, wenn damit irgendwie ein Problem existiert.
Wenn ich die Tage mal bisschen Luft und lange Weile habe, teste ich das mal im Lab bei mir… Vielleicht lässt sich dem ja irgendwie auf die Schliche kommen.
danke für den Beitrag. Hat uns die Woche gerettet. Seit letzter Woche hatten plötzlich immer mehr Windows 11 24H2 Clients Probleme, insbesondere Notebooks von HP mit v.g. installierter Version.
Ist schon einfach nur noch krass mit welchen Problemen Windows 11 24H2 zu kämpfen hat.
Ich hatte das Problem der fehlenden Gateway auf einem PC nach dem Update von Windows 10 auf Windows 11. Eintragen der Gateway hat geholfen, seither ist dieser PC wieder am Netz.
ich würde mal auf den betroffenen Systemen den Treiber nebst Registry Einträgen komplett löschen.
Windows speichert da oft uraltes Zeug.
Allerdings soll es ja auch mit ganz frisch installierten Clients auftreten…
und natürlich sind doppelte DHCP Antworten kein Problem, sondern sogar ein notwendiges Feature.
Außer bei Windows…
mir kommen echt die Tränen, wenn ich sehe was aus Microsoft geworden ist. das grenzt an Sabotage.
ändere doch bitte
"DHCP-Problem wegen fehlendem Gateway-Eintrag"
in
"DHCP-Problem? Fehlender Gateway-Eintrag"
jetzt ist es irre führend formuliert, weshalb Du zwar Klicks hast, aber von den falschen Leuten.
Danke für den Beitrag @Günter
Hatte letzte Woche das Problem mit einem Windows 11 Pro 24H2 als HyperV Plattform zum Testen.
Weitere Maschinen mit 2019/2022/2025 HyperVs stehen auch parat
Der" HyperV "von Windows 11 Pro 24H2, ließ keine DHCP Pakete mehr durch, also weder der Host noch die Clients, bekamen DHCP Pakete ab**.
Netzwerkkarten Tausch, Treiber oder Virtueller Switch wechsel halfen nicht.
Hatte zum Testen den Server 2025 mit DHCP/DNS usw. laufen *sauber ohne Fehler*,
als 2 Testkandidat einen Server 2022 und auch der machte die gleichen Probleme auf dem Win11 HyperV 24H2
Andere Testmaschinen für meine VMs, mit einem Unterbau: Windows 11 Pro 23H2, Server 2019 V1809, 2022 und 2025 hatten da keine Probleme bei diesen VMS
Erst das zurücksetzten der betroffenen Maschine auf W11 23H2 brachten Erfolg!
**
Das Seltsame daran ist, dieser Test Client mit HyperV 24H2 lief schon paar Wochen und mitten aus dem Nichts, ging nichts mehr in Sache DHCP, also auch keine Gatewayinfo. Und keine Fehler im LOG, einfach keine DHCP Pakete o.O
Und an der Netzwerkstruktur lag es nicht, sobald im Testnetzwerk ein Fremder DHCP aktiviert wurde z. B. ein Router, NAS oder Linux mit einem DHCP Server, haben alle eingebunden Geräte sofort eine DHCP gesehen. Nur der Microsoft DHCP Server war nicht sichtbar für die Clients.
Einfach verrückt und traurig, was da bei Microsoft abläuft, echt, keine Woche mehr ohne Mist.
Bei sowas drehst du doch ab, als normaler User.
Vielleicht sollte Microsoft, neben dem Ausschaltenbutton, eine Windows Recoverybutton platzieren :o)
Da fällt mir noch ein "altes" Vista Problem ein:
Ohne Gateway Eintrag kann die Network Location Awareness das Netzwerk nicht identifizieren und auch nicht speichern. Die NLA merkt sich das Firewall Profil anhand der MAC Adresse des Gateways. Vista Clients ohne Gateway konnten auch keinen AD Join durchführen, da das Netzwerk nicht vollständig ist.
Es fühlt sich gerade danach an. Die DHCP Optionen werden nicht ordentlich implementiert, der Gateway fehlt, die NLA flippt aus und findet kein Netzwerk mehr.
Haben das Problem trotz Installation des erwähnten Updates immer noch.
Man kann es zwar durch Eintragen einer festen IP, Gateway etc. umgehen, das ist aber keine Dauerlösung.
Hat jemand dasselbe Problem auch weiterhin, trotz neuem Update?
Hi, wir haben das Problem auf einem Testclient (Terra) auch noch nach dem Update. Leider keine bisher Lösung gefunden… Bin wieder zurück auf 23H2!
Da muss MS wohl langsam nachziehen mit einem Fix, was. Ist ja schlimm, 24H2 ausrollen und die QS von denen hat scheinbar gepennt.
Am besten 24H2 erst einmal aussetzen und abwarten.
Und bitte keine langen Texte als Antwort jetzt, da MS hier alleinverantwortlich ist (tldr).
Wir müssen uns nur mit der Unfähigkeit herumschlagen :-)
Folgendes aus eigener Recherche hilft leider erst einmal auch nicht:
(1) Es gibt Hinweise darauf, dass ein Update der VC-Runtime die Verbindungsprobleme lösen könnte.
Versuchen Sie bitte die aktuelle Version davon auf Ihr System aufzuspielen:
https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170
(2) Weiter wurde vor einigen Tagen von Microsoft die KB5046740 ausgeliefert.
Diese beinhaltet u. a. die folgenden Änderungen:
Korrekturen und Verbesserungen durch die KB5046740
Task-Manager Korrektur: Die Anzahl der Gruppen auf der Registerkarte „Prozesse" ist falsch oder immer null (0). Dies tritt auf, wenn Sie „Nach Typ gruppieren" einschalten.
Windows Subsystem für Linux (WSL) Korrektur: Sie konnten nicht auf Ihr Dev Drive zugreifen.
Internetverbindung korrigiert: Eine kleine Anzahl von Geräten kann keine Verbindung zum Internet herstellen. Dies tritt auf, wenn eine DHCP-Serverantwort doppelte DHCP-Optionen enthält. Dies stoppt IPv4-Verbindungen in bestimmten Netzwerken.