I226-V kein DHCP möglich: Es kann keine Verbindung mit dem DHCP-Server hergestellt werden
Wir haben hier ein Netzwerk mit mind. 30 PCs an einer Fritzbox 6660 und dessen DHCP funktioniert bis jetzt tadellos.
Einen älteren Intel NUC haben wir ausgemustert und dessen Festplatte mit Win11 an einem neuen Asus NUC 14 Pro eingesetzt. Tatsächlich läuft der neue NUC tadellos und man kann arbeiten.
Der integrierte I226-V Netzwerkadapter ist natürlich ein anderer und mit dem Asus-Treiber-Package lässt sich dieser auf den Treiber v2.1.4.3 erfolgreich installieren. Im Gerätemanager gibt es keine Konflikte und alles i.O.
Allerdings handelt dieser NUC per DHCP nicht richtig eine IP aus, er gibt sich immer die 169er IP. In der Fritzbox taucht dieser tatsächlich auch auf als einziger Netzwerkteilnehmer mit solch einer IP auf:
Der Befehl ipconfig /release zeigt dies an:
ipconfig /renew zeigt dies an:
ipconfig /all zeigt dies an:
Testweise haben wir Win11 ohne Aktivierung komplett neuinstalliert und siehe da, er bekommt eine IP und das mit dem DHCP funktioniert! D.h. NUC-Hardware, Kabel, Switch und Fritzboxen müssten alle i.O. sein?
Allerdings ist das für uns keine Lösung, es sind so unglaublich viele Programme und Programmeinstellungen auf dem NUC, da wären wir Tage bis Wochen beschäftigt.
Naheliegender und einfacher wäre eine Lösung für das DHCP-Problem.
Allerdings finden wir keinen anderen oder neueren Treiber. Gibt es denn etwas, was man für dieses Verhalten, dass kein DHCP gefunden wird, testen kann? Was gäbe es denn für Fehlermöglichkeiten, wenn es offensichtlich nicht an der ganzen Hardware liegen sollte?
Oder gibt es noch etwas, an das wir nicht gedacht haben? Mag Win11 es nicht, wenn ein anderer Netzwerkadapter bzw. Mainboard reinkommt, warum klappt es dann nach Neuinstallation? Könnte man bei einem bestehendem Win11 etwas anstoßen, was bzgl. dem Netzwerkadapter genau dort etwas resettet, was es braucht?
Danke vorab!
Einen älteren Intel NUC haben wir ausgemustert und dessen Festplatte mit Win11 an einem neuen Asus NUC 14 Pro eingesetzt. Tatsächlich läuft der neue NUC tadellos und man kann arbeiten.
Der integrierte I226-V Netzwerkadapter ist natürlich ein anderer und mit dem Asus-Treiber-Package lässt sich dieser auf den Treiber v2.1.4.3 erfolgreich installieren. Im Gerätemanager gibt es keine Konflikte und alles i.O.
Allerdings handelt dieser NUC per DHCP nicht richtig eine IP aus, er gibt sich immer die 169er IP. In der Fritzbox taucht dieser tatsächlich auch auf als einziger Netzwerkteilnehmer mit solch einer IP auf:
Der Befehl ipconfig /release zeigt dies an:
ipconfig /renew zeigt dies an:
ipconfig /all zeigt dies an:
Testweise haben wir Win11 ohne Aktivierung komplett neuinstalliert und siehe da, er bekommt eine IP und das mit dem DHCP funktioniert! D.h. NUC-Hardware, Kabel, Switch und Fritzboxen müssten alle i.O. sein?
Allerdings ist das für uns keine Lösung, es sind so unglaublich viele Programme und Programmeinstellungen auf dem NUC, da wären wir Tage bis Wochen beschäftigt.
Naheliegender und einfacher wäre eine Lösung für das DHCP-Problem.
Allerdings finden wir keinen anderen oder neueren Treiber. Gibt es denn etwas, was man für dieses Verhalten, dass kein DHCP gefunden wird, testen kann? Was gäbe es denn für Fehlermöglichkeiten, wenn es offensichtlich nicht an der ganzen Hardware liegen sollte?
Oder gibt es noch etwas, an das wir nicht gedacht haben? Mag Win11 es nicht, wenn ein anderer Netzwerkadapter bzw. Mainboard reinkommt, warum klappt es dann nach Neuinstallation? Könnte man bei einem bestehendem Win11 etwas anstoßen, was bzgl. dem Netzwerkadapter genau dort etwas resettet, was es braucht?
Danke vorab!
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672997
Url: https://administrator.de/forum/i226-v-kein-dhcp-moeglich-es-kann-keine-verbindung-mit-dem-dhcp-server-hergestellt-werden-672997.html
Ausgedruckt am: 16.06.2025 um 21:06 Uhr
21 Kommentare
Neuester Kommentar
Moin,
hast Du mal eine feste LAN IP ausprobiert?
Ich vermute mal, dass es kein DHCP-Problem sondern eini allgemeines LAN-Problem ist.
Wenn das mit der feste IP funktioniert, würde ich es dabei belassen und am Anfang und/oder Ende einen Bereich im DHCP ausnehmen.
Stefan
hast Du mal eine feste LAN IP ausprobiert?
Ich vermute mal, dass es kein DHCP-Problem sondern eini allgemeines LAN-Problem ist.
Wenn das mit der feste IP funktioniert, würde ich es dabei belassen und am Anfang und/oder Ende einen Bereich im DHCP ausnehmen.
Stefan
Hi,
schon mal mit einer statischen IP außerhalb des DHCP-Bereichs versucht?
btw - IPs aus dem Bereich 169.254.0.0/16 sind APIPA-Adressen ( https://de.wikipedia.org/wiki/Private_IP-Adresse -> "Link Local"), die sich ein Gerät selbst vergibt, wenn der DHCP-Prozess nicht abgeschlossen wird.
Gruß
TA
Edit:
Und dann wäre noch die Frage, ob
schon mal mit einer statischen IP außerhalb des DHCP-Bereichs versucht?
btw - IPs aus dem Bereich 169.254.0.0/16 sind APIPA-Adressen ( https://de.wikipedia.org/wiki/Private_IP-Adresse -> "Link Local"), die sich ein Gerät selbst vergibt, wenn der DHCP-Prozess nicht abgeschlossen wird.
Gruß
TA
Edit:
Und dann wäre noch die Frage, ob
- noch IPs aus dem DHCP-Scope vorhanden/frei sind, die vergeben werden können
- die Fritte neue Geräte akzeptiert ( -> MAC-Filter)
mit dem Asus-Treiber-Package
Niemand nutzt die NIC Treiber vom Hersteller. Auch ein Laie verwendet dafür immer die original Treiber des NIC Chipsatzherstellers!! (Aktuelle Winblows Version 30.1 v. 29.4.25!)https://www.intel.de/content/www/de/de/products/sku/210599/intel-etherne ...
Damit klappt auch die DHCP Funktion fehlerlos.
2
Zitat von @StefanKittel:
hast Du mal eine feste LAN IP ausprobiert?
Ich vermute mal, dass es kein DHCP-Problem sondern eini allgemeines LAN-Problem ist.
Wenn das mit der feste IP funktioniert, würde ich es dabei belassen und am Anfang und/oder Ende einen Bereich im DHCP ausnehmen.
hast Du mal eine feste LAN IP ausprobiert?
Ich vermute mal, dass es kein DHCP-Problem sondern eini allgemeines LAN-Problem ist.
Wenn das mit der feste IP funktioniert, würde ich es dabei belassen und am Anfang und/oder Ende einen Bereich im DHCP ausnehmen.
Tatsächlich noch nicht. Ich dachte das geht sowieso, aber es wäre schön wenn die Fritzbox sämtliche Adressen managed und man nicht drandenken muss dass hier und da ein Gerät eine feste hat.
Bereich ist schon ausgespart, geht von 50-200 nur.
Zitat von @TwistedAir:
schon mal mit einer statischen IP außerhalb des DHCP-Bereichs versucht?
btw - IPs aus dem Bereich 169.254.0.0/16 sind APIPA-Adressen ( https://de.wikipedia.org/wiki/Private_IP-Adresse -> "Link Local"), die sich ein Gerät selbst vergibt, wenn der DHCP-Prozess nicht abgeschlossen wird.
Gruß
TA
Edit:
Und dann wäre noch die Frage, ob
schon mal mit einer statischen IP außerhalb des DHCP-Bereichs versucht?
btw - IPs aus dem Bereich 169.254.0.0/16 sind APIPA-Adressen ( https://de.wikipedia.org/wiki/Private_IP-Adresse -> "Link Local"), die sich ein Gerät selbst vergibt, wenn der DHCP-Prozess nicht abgeschlossen wird.
Gruß
TA
Edit:
Und dann wäre noch die Frage, ob
- noch IPs aus dem DHCP-Scope vorhanden/frei sind, die vergeben werden können
- die Fritte neue Geräte akzeptiert ( -> MAC-Filter)
Wie oben erwähnt, dachte das geht sowieso. Aber wir werden es noch testen.
Das mit den APIPA-Adressen weiß ich natürlich, ich schrieb auch der PC hat sich die selbst gegeben. Aber interessant, dass die Fritzbox den Teilnehmer so aufführt? Wahrscheinlich sieht die den einfach und listet auf (und das obwohl anderes Subnetz.... keine Ahnung).
Ja, es sind noch genügend freie IPs aus dem DHCP-Bereich 50-200 vorhanden, wie gesagt nur um die 30 PCs.
MAC-Filter gibt's nicht und alles andere läuft tadellos (auch neu angeschlossene unbekannte Geräte).
Zitat von @aqui:
https://www.intel.de/content/www/de/de/products/sku/210599/intel-etherne ...
Damit klappt auch die DHCP Funktion fehlerlos.
mit dem Asus-Treiber-Package
Niemand nutzt die NIC Treiber vom Hersteller. Auch ein Laie verwendet dafür immer die original Treiber des NIC Chipsatzherstellers!! (Aktuelle Winblows Version 30.1 v. 29.4.25!)https://www.intel.de/content/www/de/de/products/sku/210599/intel-etherne ...
Damit klappt auch die DHCP Funktion fehlerlos.
Danke mich als "unterhalb von Laie" zu bezeichnen. Ich dachte vielleicht zu kompliziert, nämlich ASUS hat ein Produkt auf den Markt gebracht und kennt besser als Intel die Kompatibilität untereinander, sozusagen das Gesamtprodukt wie es funktionieren muss?
Auf der Intel-Downloadseite war ich auch schon und dann wieder zurückgerudert und dachte, das ist der falsche Weg. Aber gut, wir werden es damit testen.
Was meinst Du mit:
Damit klappt auch die DHCP Funktion fehlerlos.
Hattest Du etwa exakt das gleiche Problem? Warum soll DHCP mit den Intel-Treiber auf der Asus-Seite nicht funktionieren? Glaubst du etwa die bieten Treiber zum Download an die überhaupt nicht tun?
und kennt besser als Intel die Kompatibilität untereinander
Nein, das ist bei chinesischen Consumer Produkten nie der Fall. Die nehmen bekanntlich irgendeine Uralt Version bündeln die in ihr Treiber Package und vergessen es dann. Update Fehlanzeige.das ist der falsche Weg.
Kein verantwortungsvoller Administrator "denkt" das.... Das sind alles allgemeine Binsenweisheiten die man als Administrator schon seit Jahren verinnerlicht haben sollte.Warum soll DHCP mit den Intel-Treiber auf der Asus-Seite nicht funktionieren?
Das musst du mal deine Fritzbox fragen oder den veralteten Treiber von der Asus Seite! Irgendwas läuft zwischen den beiden ja schief.Ein Wireshark Trace deinerseits der einmal den Ablauf der DHCP Kommunikation zw. NIC und Fritte en Detail zeigt und so Licht ins Dunkel der Raterei gebracht hätte war ja leider auch Fehlanzeige. Das zumindestet hätte der Community hier etwas mehr Details zum zielführenden Troubleshooting gezeigt.
Mit dem originalen Intel Treiber klappt es zu mindestens an einer alten Fritte (7490) und an einer brandneuen fehlerlos. Ebenso an einem Mikrotik, Kea DHCP Server und einem Cisco Router mit DHCP. Mehr Beweis geht eigentlich nicht...
Den Ranking Schuh musst du dir aber selber anziehen wenn man als Admin blind ein völlig veraltetes Treiberset verwendet und sich dann über Fehlfunktionen wundert.
Freitags Thread... 🐟1
wenn das mit der statischen IP nicht zum Ziel führt.... du hast geschrieben
Gruß
TA
Es kann kein Vorgang auf LAN-Verbindung* 10 ausgeführt werden, solange dessen Medium nicht...
Zehn (irgendwann mal) konfigurierte LAN-Verbindungen machen schon stutzig, vielleicht läuft der Traffic über den falschen Port? Habt ihr auch virtuelle LAN-Verbindungen, vielleicht eine Virtualisierungsumgebung (VirtualBox o. ä.) drauf? Man könnte drüber nachdenken, die Netzwerkeinstellungen komplett zurückzusetzen, ABER es sollte vorher ein Backup gemacht werden oder vorhanden sein, man könnte sich möglicherweise das Funktionieren mancher Anwendung darauf zerschießen. Weiß ja keiner, was installiert ist.Gruß
TA
1Zitat von @aqui:
Kein verantwortungsvoller Administrator "denkt" das.... Das sind alles allgemeine Binsenweisheiten die man als Administrator schon seit Jahren verinnerlicht haben sollte.
Immerhin ist Asus offizieller Intel NUC - Nachfolger, so ganz abgedriftet werden die auch nicht sein?Kein verantwortungsvoller Administrator "denkt" das.... Das sind alles allgemeine Binsenweisheiten die man als Administrator schon seit Jahren verinnerlicht haben sollte.
Warum soll DHCP mit den Intel-Treiber auf der Asus-Seite nicht funktionieren?
Das musst du mal deine Fritzbox fragen oder den veralteten Treiber von der Asus Seite! Irgendwas läuft zwischen den beiden ja schief.Ein Wireshark Trace deinerseits der einmal den Ablauf der DHCP Kommunikation zw. NIC und Fritte en Detail zeigt und so Licht ins Dunkel der Raterei gebracht hätte war ja leider auch Fehlanzeige. Das zumindestet hätte der Community hier etwas mehr Details zum zielführenden Troubleshooting gezeigt.
Moment, was heißt "war" und "hätte"? Wer hat danach gefragt?
Natürlich kann ich mit der Fritte einen Wireshark-Trace aufnehmen, woher soll ich riechen, dass ihr das gerne hättet?
Allerdings steht das alles nicht bei mir hier, ich bin nicht vor Ort. Und vielleicht wisst ihr, wie schwer das ist andere "Unbedarfte" dazu zu bringen sowas zu machen. Ich schaue, ob das vielleicht machbar ist.
Mit dem originalen Intel Treiber klappt es zu mindestens an einer alten Fritte (7490) und an einer brandneuen fehlerlos. Ebenso an einem Mikrotik, Kea DHCP Server und einem Cisco Router mit DHCP. Mehr Beweis geht eigentlich nicht...
Den Ranking Schuh musst du dir aber selber anziehen wenn man als Admin blind ein völlig veraltetes Treiberset verwendet und sich dann über Fehlfunktionen wundert. Freitags Thread... 🐟
Den Ranking Schuh musst du dir aber selber anziehen wenn man als Admin blind ein völlig veraltetes Treiberset verwendet und sich dann über Fehlfunktionen wundert.
Freitags Thread... 🐟Bitte was willst Du von mir???
Ganz konkret: Gibt's einen neueren Treiber als v2.1.4.3? Woher willst Du wissen, ob ich "völlig" veraltete Treiber verwende? Win11 scheint sowieso den aktuelleren (im Asus-Treiberpaket ist wohl 2.1.4.2 drin) sich zu laden, daher eher die Frage, hat vielleicht der neueste Treiber ein Manko und mit dem davor läuft es besser?
Im Intel 30.1 - Release gibt's ja kein Setup. Man wählt vom Gerätemanager die Treiber manuell aus, aber es bleibt dabei, man hat schon den neuesten Treiber wird gemeldet.
Wäre der Unterordner "Release_30.1\PRO2500\Winx64\W11" richtig? Dort steckt nämlich nur der v2.1.4.3 drin, der bereits installiert ist auf dem NUC.
Was schreibst Du mir mit Fritte 7489, Mikrotik Kea etc., geht es hier nicht um unser Setup? Warum bist Du so felsenfest davon überzeugt das v2.1.4.3 geht und glaubst mir nicht, dass es damit bei uns nicht geht?
Moin,
Läuft der Dienst „DHCP-Client“ überhaupt?
Läuft der Dienst „DHCP-Client“ überhaupt?
Zitat von @TwistedAir:
Zehn (irgendwann mal) konfigurierte LAN-Verbindungen machen schon stutzig, vielleicht läuft der Traffic über den falschen Port? Habt ihr auch virtuelle LAN-Verbindungen, vielleicht eine Virtualisierungsumgebung (VirtualBox o. ä.) drauf? Man könnte drüber nachdenken, die Netzwerkeinstellungen komplett zurückzusetzen
Zehn (irgendwann mal) konfigurierte LAN-Verbindungen machen schon stutzig, vielleicht läuft der Traffic über den falschen Port? Habt ihr auch virtuelle LAN-Verbindungen, vielleicht eine Virtualisierungsumgebung (VirtualBox o. ä.) drauf? Man könnte drüber nachdenken, die Netzwerkeinstellungen komplett zurückzusetzen
Ja, in der Tat, ich weiß nicht was es mit diesem Wifi-direct auf sich hat?
Wir haben jetzt den NCP gelöscht, aktuell sind noch Ethernet, WLAN und zusätzlich der Wifi-direct in ipconfig /all zu sehen. Ist der Wifi-direct irgendwie ein Problem?
Die Netzwerkeinstellungen zurücksetzen wie Du oben vorgeschlagen hast von heise haben wir gerade gemacht, leider nix gebracht. Natürlich neustart, nochmal I226-V neu Treiber laden, DHCP -statisch hin und her, ist leider nicht besser.
Auch das mit dem Intel-Treiberpaket soeben verwendet, aber Gerätemanager sagt der neueste Treiber ist bereits drauf.
Wir versuchen mal einen Wireshark-Mitschnitt...
Wir haben soeben ein paar Wiresharks in der Fritzbox aufgenommen, das sieht dort so aus:
Alle LAN-Kabel raus, und dann nur den NUC auf LAN1 eingesteckt so dass er das DHCP verhandeln müsste. Das ganze 4mal von eth0/1, lan und oben Schnittstelle 1. Hab's hier hochgeladen, weil man hier im Forum offensichtlich keine Dateien teilen kann?
limewire.com/d/UO8bz#IpuRSEfROh
Möchte einmal jemand reinsehen, vielleicht @aqui?
Hab ich was falsch gemacht, wenn ja, wie nimmt man richtig auf?
Alle LAN-Kabel raus, und dann nur den NUC auf LAN1 eingesteckt so dass er das DHCP verhandeln müsste. Das ganze 4mal von eth0/1, lan und oben Schnittstelle 1. Hab's hier hochgeladen, weil man hier im Forum offensichtlich keine Dateien teilen kann?
limewire.com/d/UO8bz#IpuRSEfROh
Möchte einmal jemand reinsehen, vielleicht @aqui?
Hab ich was falsch gemacht, wenn ja, wie nimmt man richtig auf?
Meinst Du das?
Soeben nachgeschaut und ja, der läuft definitiv. Schade, irgendwas muss es doch sein?
Wär super wenn wir das Rätsel gelöst bekommen
Was kannst du daraus ableiten?
- der Client spricht mit dem Netzwerk, der Treiber ist ok
- der Client vollendet den DHCP-Prozess nicht
- wenn der Client schon kein DHCP will, dann gib ihm endlich eine statische IP
Gruß
TA
Vielen lieben Dank für's Nachsehen.
Die statische IP haben wir bereits versucht (bei uns die .28 am Ende) und die Fritzbox zeigt das tatsächlich so an, wunderbar!
Aber es kommt keine Verbindung zustande, die fritz.box - (bzw. .1-IP) lädt nicht und natürlich auch nichts vom Internet.
Scheint also etwas grundlegend nicht zu stimmen.
Soll ich in dem Zustand mit Static-IP auch einen Trace aufnehmen? Wenn ja, welche der vielen Schnittstellen ist eigentlich richtig (bzw. welchen Trace hast Du Dir angesehen)?
Noch zur Info, hier sieht es so aus, offiziell nur diese beiden (trotzdem in ipconfig /all mehr zu sehen mit wifi-direct...):
In der Win11-Systemsteuerung, Erweiterte Netzwerkeigenschaften -> Hardware- und Verbindungseigenschaften fällt der Name "I225-LM" auf und der Intel-NUC davor hatte den Adapter:
Wieso ist das hier zu sehen, wenn doch der jetzige NUC den I226-V hat?
Und jetzt wird ganz spannend! Im Gerätemanager auf den I226-V - Adapter zeigt der Tab Treiber nichts an:
Kann es sein, dass Windows versucht mit dem I225-Treiber den I226 anzusteuern?
Wenn ja, wie ums verecken bekommt man den I225-Treiber aus dem System raus?
Name: Bluetooth-Netzwerkverbindung
Beschreibung: Bluetooth Device (Personal Area Network)
Physische Adresse (MAC): dc:45:46:94:88:64
Status: Nicht vorhanden
Maximale Übertragungseinheit: 0
Verbindung (IPv4/IPv6): Getrennt
Name: Ethernet 3
Beschreibung: Intel(R) Ethernet Controller (3) I225-LM
Physische Adresse (MAC): 48:21:0b:2e:42:11
Status: Nicht vorhanden
Maximale Übertragungseinheit: 0
Verbindung (IPv4/IPv6): Getrennt
Name: WLAN
Beschreibung: Intel(R) Wi-Fi 6 AX201 160MHz
Physische Adresse (MAC): ac:74:b1:48:1b:97
Status: Nicht vorhanden
Maximale Übertragungseinheit: 0
Verbindung (IPv4/IPv6): Getrennt
Name: LAN-Verbindung* 1
Beschreibung: Microsoft Wi-Fi Direct Virtual Adapter #3
Physische Adresse (MAC): ac:74:b1:48:1b:98
Status: Nicht vorhanden
Maximale Übertragungseinheit: 0
Verbindung (IPv4/IPv6): Getrennt
Automatische Proxy-Erkennung: EinWieso ist das hier zu sehen, wenn doch der jetzige NUC den I226-V hat?
Und jetzt wird ganz spannend! Im Gerätemanager auf den I226-V - Adapter zeigt der Tab Treiber nichts an:
Kann es sein, dass Windows versucht mit dem I225-Treiber den I226 anzusteuern?
Wenn ja, wie ums verecken bekommt man den I225-Treiber aus dem System raus?
Zitat von @riegeler:
Die statische IP haben wir bereits versucht (bei uns die .28 am Ende) und die Fritzbox zeigt das tatsächlich so an, wunderbar!
Die statische IP haben wir bereits versucht (bei uns die .28 am Ende) und die Fritzbox zeigt das tatsächlich so an, wunderbar!
es sind noch genügend freie IPs aus dem DHCP-Bereich 50-200 vorhanden
Bitte noch einmal die Einstellungen bzgl. DHCP-Range auf der Fritte checken - üblicher Weise ist dort .20 - .200 eingestellt. Oder es hat jemand Hand angelegt.
Aber es kommt keine Verbindung zustande, die fritz.box - (bzw. .1-IP) lädt nicht und natürlich auch nichts vom Internet.
???
Eine Verbindung zwischen Fritte und Client ist doch da? Also erst das lokale Netzwerk in Ordnung bringen; das Internet kommt später.
- Wie sind die aktuellen Einstellungen des Interfaces mit der statischen IP?
ipconfig /all- Firewall auf Client für die Diagnosezwecke deaktivieren. Nach Abschluss wieder aktivieren.
- IP-Check
ping -n 2 127.0.0.1 # localhost
ping -n 2 192.168.139.50 # Client-Ip
ping -n 2 192.168.139.1 # Fritte, bestenfalls auch Standard-Gateway (vgl. ipconfig)
ping -n 2 8.8.8.8 # extern- DNS-Check
nslookup administrator.de # DNS Client-Konfig
nslookup administrator.de 192.168.139.1 # DNS Fritte
nslookup administrator.de 8.8.8.8 # DNS externSoll ich in dem Zustand mit Static-IP auch einen Trace aufnehmen?
Erst mal nicht, erst die Basics.Wenn ja, welche der vielen Schnittstellen ist eigentlich richtig (bzw. welchen Trace hast Du Dir angesehen)?
Alle. Aber die unterscheiden sich nur unwesentlich.Und man könnte die Tests zusätzlich auch über das WLAN-Interface durchführen - Fritte und Client sind dazu ja fähig. Somit umgehst du das LAN, wo du Treiberprobleme vermutest. Kabel ist dabei selbstverständlich gezogen.
Alternativ mit einem Ethernet-USB-Adapter, wenn vorhanden, testen.
Gruß
TA
1
Hi @TwistedAir,
wir haben den DHCP Bereich vor langer Zeit bereits auf 50-200 eingeschränkt, daher nicht wundern.
Ja, die physikalische Verbindung zur Fritte ist vorhanden, denn ein anderer PC oder auch wie ganz oben erwähnt der gleiche NUC aber komplett Win11 neu installiert funktioniert. Auch die LEDs blinken einwandfrei.
Ich wollte nur klarmachen, dass eine Static-IP tatsächlich nicht funktioniert, obwohl ich selbst davon ausgegangen bin das mussfunktionieren.
Hier die Tests mit der Static-IP, es ist das eingestellt (ich bin nicht vor Ort und bekam leider kein ipconfig /all):
Die Befehle sehen dann so aus (feste IP .28 und nicht .50):
Könnte von euch jemand auf meinen Beitrag gestern um 21:39:54 eingehen mit den leeren Feldern im Treiber-Fenster und warum im Untermenü Systemsteuerung-Netzwerkeigenschaften-erweitert etc. auf einmal "I225" auftaucht?
wir haben den DHCP Bereich vor langer Zeit bereits auf 50-200 eingeschränkt, daher nicht wundern.
Ja, die physikalische Verbindung zur Fritte ist vorhanden, denn ein anderer PC oder auch wie ganz oben erwähnt der gleiche NUC aber komplett Win11 neu installiert funktioniert. Auch die LEDs blinken einwandfrei.
Ich wollte nur klarmachen, dass eine Static-IP tatsächlich nicht funktioniert, obwohl ich selbst davon ausgegangen bin das mussfunktionieren.
Hier die Tests mit der Static-IP, es ist das eingestellt (ich bin nicht vor Ort und bekam leider kein ipconfig /all):
Die Befehle sehen dann so aus (feste IP .28 und nicht .50):
Könnte von euch jemand auf meinen Beitrag gestern um 21:39:54 eingehen mit den leeren Feldern im Treiber-Fenster und warum im Untermenü Systemsteuerung-Netzwerkeigenschaften-erweitert etc. auf einmal "I225" auftaucht?
Ich glaube wir haben es soeben gelöst und das fast durch Zufall.
Wenn ich selbst vor Ort wäre, hätte ich's wahrscheinlich alles viel schneller geschafft, aber aus der Ferne dauert das natürlich immer.
Im Gerätemanager fiel auf, dass noch ein virtual VPN-Adapter von Shrew drin hing und es war noch ein Shrew-Client installiert. Da wir Wireguard nutzen haben wir Shrew komplett deinstalliert.
Danach noch mit manueller Treiberinstallation rumprobiert, cmd-Befehle etc.
Wir haben sogar einen USB-Ethernet Adapter getestet, lief ohne Probleme.
Und so zwischendurch wieder mit dem I226-V, mit statischer IP gings. Hmm ging doch davor nicht? Okay, dann testen wir per DHCP, geht auch! Internet, pings, etc. alles da.
Die einzige wirkliche Änderung war der Shrew-Client und das nur beiläufig gesehen, was ein Zufall.
Ich erinnere mich, dass Shrew vor Jahren schon Probleme machte und dazu gibt es hier meinen alten umfangreichen Thread:
[content:1538742337]
Die leeren Felder im Treiber-Reiter/Fenster waren nur deshalb, weil die sys und dll nicht angewählt waren, also kein Fehler.
Bleibt noch die Frage, warum in den erweiterten Netzwerkeinstellungen -> Hardware- und Verbindungseigenschaften so viele mehr Adapter (auch der I225) zu sehen waren als im ipconfig /all und auch auf einer Ebene davor?
Vielleicht ist dort eine Historie gespeichert und nur ipconfig /all ist wirklich live und aktuell? D.h. man darf sich hier nicht verwirren lassen?
Danke euch allen für die vielen Tipps und Anregungen, das Forum hier ist wirklich super.
Wenn ich selbst vor Ort wäre, hätte ich's wahrscheinlich alles viel schneller geschafft, aber aus der Ferne dauert das natürlich immer.
Im Gerätemanager fiel auf, dass noch ein virtual VPN-Adapter von Shrew drin hing und es war noch ein Shrew-Client installiert. Da wir Wireguard nutzen haben wir Shrew komplett deinstalliert.
Danach noch mit manueller Treiberinstallation rumprobiert, cmd-Befehle etc.
Wir haben sogar einen USB-Ethernet Adapter getestet, lief ohne Probleme.
Und so zwischendurch wieder mit dem I226-V, mit statischer IP gings. Hmm ging doch davor nicht? Okay, dann testen wir per DHCP, geht auch! Internet, pings, etc. alles da.
Die einzige wirkliche Änderung war der Shrew-Client und das nur beiläufig gesehen, was ein Zufall.
Ich erinnere mich, dass Shrew vor Jahren schon Probleme machte und dazu gibt es hier meinen alten umfangreichen Thread:
[content:1538742337]
Die leeren Felder im Treiber-Reiter/Fenster waren nur deshalb, weil die sys und dll nicht angewählt waren, also kein Fehler.
Bleibt noch die Frage, warum in den erweiterten Netzwerkeinstellungen -> Hardware- und Verbindungseigenschaften so viele mehr Adapter (auch der I225) zu sehen waren als im ipconfig /all und auch auf einer Ebene davor?
Vielleicht ist dort eine Historie gespeichert und nur ipconfig /all ist wirklich live und aktuell? D.h. man darf sich hier nicht verwirren lassen?
Danke euch allen für die vielen Tipps und Anregungen, das Forum hier ist wirklich super.
Schön, dass es jetzt läuft. 
Ja, so eine vergessene Altlast kann einen schon ärgern.
Ja, so eine vergessene Altlast kann einen schon ärgern. 1
Ich habs zu spät gelesen, die Deinstallation des hat vermutlich eine Reorganization der übrigen Schnittstellen ausgelöst. Was ich persönlich oft gesehen habe: Es gibt im Gerätemanager sicherlich einige ausgeblendete Netzwerk Schnittstellen, wenn eine davon in der Konfiguration noch die IP hat, die auch der DHCP Server vorschlägt, dann kommt Windows auch durcheinander. Oft hilft es im Geräte-Manager die ausgeblendeten Geräte einzublenden und alle grau hinterlegten Netzwerkschnittstellen zu löschen. Ich persönlich lösche (erst danach) dann auch die aktive Schnittstelle - alles Netzwerktechnische weg - und lasse sie neu erkennen. Dann klappt es eigentlich...
1Dann klappt es eigentlich...
Guter und sehr sinnvoller Punkt, denn am Shrew selber liegt es nicht!Yep, für's nächste Mal habe ich dazugelernt.
Du magst recht haben, dass es prinzipiell nicht am Shrew lag. Dennoch scheint er einen klaren Einfluss gehabt zu haben, sonst hätte die Deinstallation nicht geholfen?
Und sei es nur, dass dessen Deinstallation eine Reorganisation aller Schnittstellen ausgelöst hat, vielleicht war das der Trigger, den es gebraucht hat.
Und wie Du hier hier nachlesen kannst, lief damals der Shrew nicht richtig, vielleicht war damals schon was verbockt, was bis vorgestern immer noch nicht gelöst war.
