
117752
08.09.2014, aktualisiert am 10.09.2014
WLAN: Kein Internetzugriff mit einem bestimmten Gerät möglich
Hallo Administrator-Community,
ich habe folgendes Problem: Ich habe ein Asus-Notebook mit einem Intel Centrino Wireless N-100 - Modul, dass unter Windows 8.1 wie unter Ubuntu Live keine Internetverbindung bekommt, obwohl es mit meinem W-LAN verbunden ist. Unter Windows wird dann das Netzwerk als „begrenzt“ angezeigt.
Mein Netzwerk-Aufbau:
Fritz!Box 7170 (DHCP-Server) - Netgear-Gigabit-Switch - Buffalo WBMR-HP-G300H mit DD-WRT (nur AP)
Außer mit dieses Notebook kommt jedes Gerät, seien es Smartphones oder andere Notebooks, problemlos in Netz. Mit dem Notebook komme ich auf die Konfig-Seite von DD-WRT, nicht aber auf die der Fritz!Box, welche sogar als Standardgateway erkannt wird und auch eine IP-Adresse vergibt. Sie ist auch nicht „anpingbar“.
Vielen Dank schon mal für eure Tipps und Ratschläge.
Bitte melden, sofern mehr Infos benötigt werden.
Grüße
T.Walter
Edit #1: Auf mein NAS kann das Notebook zugreifen, auch sind einige Netzwerk-Geräte sichtbar.
Edit #2:
Zusammenfassung
Edit #3:
Lösung
ich habe folgendes Problem: Ich habe ein Asus-Notebook mit einem Intel Centrino Wireless N-100 - Modul, dass unter Windows 8.1 wie unter Ubuntu Live keine Internetverbindung bekommt, obwohl es mit meinem W-LAN verbunden ist. Unter Windows wird dann das Netzwerk als „begrenzt“ angezeigt.
Mein Netzwerk-Aufbau:
Fritz!Box 7170 (DHCP-Server) - Netgear-Gigabit-Switch - Buffalo WBMR-HP-G300H mit DD-WRT (nur AP)
Außer mit dieses Notebook kommt jedes Gerät, seien es Smartphones oder andere Notebooks, problemlos in Netz. Mit dem Notebook komme ich auf die Konfig-Seite von DD-WRT, nicht aber auf die der Fritz!Box, welche sogar als Standardgateway erkannt wird und auch eine IP-Adresse vergibt. Sie ist auch nicht „anpingbar“.
Vielen Dank schon mal für eure Tipps und Ratschläge.
Bitte melden, sofern mehr Infos benötigt werden.
Grüße
T.Walter
Edit #1: Auf mein NAS kann das Notebook zugreifen, auch sind einige Netzwerk-Geräte sichtbar.
Edit #2:
Zusammenfassung
- Notebook bekommt unter Win und Ubuntu IP-Adresse aus Vergabebereich der Fritz!Box
- Gleiches Problem auch bei unverschlüsseltem Netz
- Ping an Fritz!Box nicht erfolgreich, an DD-WRT schon
- AP scheint richtig eingestellt zu sein, da andere Geräte problemlos funktionieren
- Notebook-WLAN funktioniert mit anderen W-LAN-Netzen
- Anderer WLAN-Adapter (funktionierend getestet an Win-PC) verbindet sich auch nur „begrenzt“ unter Windows
Edit #3:
Lösung
- Notebook in Flugmodus versetzt
- Gerät aus Fritz!Box entfernt
- Fritz!Box neugestartet
- feste IP für die MAC-Adresse des Notebooks in der Fritz!Box festgelegt
- Notebook WLAN wieder aktiviert
- Freude
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 248576
Url: https://administrator.de/forum/wlan-kein-internetzugriff-mit-einem-bestimmten-geraet-moeglich-248576.html
Ausgedruckt am: 30.04.2025 um 03:04 Uhr
26 Kommentare
Neuester Kommentar

Läuft da eventuell ein Herstellerspezifisches WLAN-Tool, welches die WLAN-Einstellungen des Systems aushebelt?
Ich befürchte, Du wirst nicht um eine strategische Fehleranalyse herumkommen. Sind die per DHCP erhaltenen IP-Daten vollständig und korrekt? Kannst Du den Router anpingen? Funktioniert DNS-Auflösung usw.?
Ich befürchte, Du wirst nicht um eine strategische Fehleranalyse herumkommen. Sind die per DHCP erhaltenen IP-Daten vollständig und korrekt? Kannst Du den Router anpingen? Funktioniert DNS-Auflösung usw.?

Unter Windows mit ipconfig /all, unter Linux mit ifconfig
Wenn es systemunabhängig nicht funktioniert, ist das schon irgendwie seltsam. Vielleicht ein MAC-Filter auf dem DD-WRT?
Wenn es systemunabhängig nicht funktioniert, ist das schon irgendwie seltsam. Vielleicht ein MAC-Filter auf dem DD-WRT?
obwohl es mit meinem W-LAN verbunden ist. Unter Windows wird dann das Netzwerk als „begrenzt“ angezeigt.
Diese Aussage ist technischer Unsinn denn es ist ein Widerspruch in sich."Begrenzt" sagt das kein DHCP Server gefunden wurde. Das passiert wenn eben keine Netzwerk Verbindung besteht und logischerweise der DHCP Server so nicht erreichbar ist.
Interfaces bekommen dann eine sog. APIPA, Zeroconf IP Adresse aus dem Bereich 169.254.0.0
http://de.wikipedia.org/wiki/Zeroconf
Die Kommandos ipconfig -all (Win) bzw. ifconfig (Linux) zeigen dir die Vollständigkeit der korrekten IP Adressen dann auch an.
Fazit: Es besteht also keinerlei Verbindung zum WLAN.
Als allererster Verdacht kommt dann meist der Treiber auf der auch die Verschlüsselung regelt, was du ja schon richtigerweise versucht hast zu minimieren.
Wichtig ist hier zusätzlich das du im WLAN AP Setup des Accesspoint oder WLAN Router folgende Setup Regeln unbedingt beachtest:
- Niemals die Hersteller Default SSID verwenden (WLAN Name) ! Hier imm was eigenes individuelles wie "Bitschleuder" oder "Wurstsemmel" verwenden. Der WLAN Name (SSID) sollte keine Sonderzeichen und Umlaute enthalten !
- Als Verschlüsselung immer WPA-2 aktivieren OHNE TKIP oder Mischbetrieb mit TKIP. Hier immer ausschliesslich AES-CCMP einstellen. Ausnahme ist nur wenn du alte WLAN HW hast da hilft dann ggf. TKIP zu aktivieren
- Der WLAN Schlüssel soltte ebenfalls keine Sonderzeichen und Umlaute enthalten !
- Auf den 4 kanaligen Abstand zu Nachbar WLANs achten. Diverse Tools wie hier_Linux zeigen dir die Kanalverteilung in deinem Umfeld an.
Kommt eine Verbindung dann zustande ?

Fehlt irgendwo eine Route?
Normalerweise haben Fritz! Boxen eine IP aus dem Subnetz 192.168.178.0 Die Ausgabe mit den IP-Daten legt die Vermutung nahe, dass das Notebook den DD-WRT als Gateway benutzt. In dem Fall sollte im DD-WRT die Fritz!Box als Default Gateway eingetragen sein.
Normalerweise haben Fritz! Boxen eine IP aus dem Subnetz 192.168.178.0 Die Ausgabe mit den IP-Daten legt die Vermutung nahe, dass das Notebook den DD-WRT als Gateway benutzt. In dem Fall sollte im DD-WRT die Fritz!Box als Default Gateway eingetragen sein.
Abstand kann nicht eingehalten werden, da umliegende Netzwerke auf Kanal 1, 3, 7, 11 (eigenes auf 4)
Das ist per se schlecht, denn so kommt es zu Überlagerungsstörungen was zulasten der Performance geht !Wenn, dann solltest du den AP wenigstens auf Kanal 5 setzen denn da hast du den größt möglichen Abstand !
Das ist aber nicht das ursächliche Problem....
ipconfig zeigt ja auch an das soweit alles OK ist. Leider fehlt das Pendant ifconfig dazu für die Linux Seite aber gehen wir mal davon aus das das identisch ist ?!
Spannend noch die Frage WIE du den Buffalo als NUR WLAN Accesspoint angeschlossen hast ??
Bist du genau so vorgegangen wie es hier im Tutorial in der Alternative 3 beschrieben ist ??
Kopplung von 2 Routern am DSL Port
Oder routest du über den Buffalo ?? Lässt sich ahnen, da IP Netze an Fritzboxen in der Regel 192.168.178.0 /24 haben ! Und würde die Vermutung vom Kollegen FA-jka hier bestätigen.
Routing wäre hier aber grundfalsch und damit dann auch der Anschluss des Buffalo als nur WLAN Accesspoint in deinem Netz !!!
Wichtig ist bei solchem Setup das der WAN Port immer außen vor bleibt (nicht angeschlossen !) und... das der DHCP Server auf dem Buffalo deaktiviert ist !
Arbeitet die FB auch noch als WLAN Router bzw. ist das WLAN dort auch aktiv ?
Wenn ja hast du die Kanalwahl beachtet und das die SSID und Passwort mit dem Buffalo nur AP identisch ist ?

Zitat von @aqui:
Wichtig ist bei solchem Setup das der WAN Port immer außen vor bleibt (nicht angeschlossen !)
Wichtig ist bei solchem Setup das der WAN Port immer außen vor bleibt (nicht angeschlossen !)
Das würde sich ja mit meiner Vermutung (Default-Route im DD-WRT) decken. Und in dem Fall wüssten wir dann auch, wo der Traffic vom Notebook bleibt

Welcher Server antwortet Dir, wenn Du einen nslookup (z.B. auf www.heise.de) machst?
Wo "versandet" der Traffic, wenn Du dorthin tracest? (Unter Windows mit "tracert www.heise.de)
Wo "versandet" der Traffic, wenn Du dorthin tracest? (Unter Windows mit "tracert www.heise.de)
Na ja, nach der o.a. Beschreibung vom TO klingt das ja erstmal so als ob er alles richtig gemacht hat.
Die Tatsache das wirklich alle anderen Clients sauber arbeiten können ohne jegliche Einschränkungen untermauert das ja auch !
Das kann dann letztlich in der Tat einzig nur noch ein Problem des jeweiligen Clients sein.
Das das allerdings bei unterschiedlichen OS identisch ist, ist schon höchst ungewöhnlich. Zu 98% ist ja sowas immer irgendwelcher zusätzlicher Winblows Firewall Mist aber bei Linux entfällt das.
Da liegt der Verdacht dann doch nahe das das ein HW Fehler ist.
Da sollte man testweise mal in einen kleinen USB WLAN Stick investieren wie z.B. den hier:
http://www.reichelt.de/EDIMAX-EW-7811UN/3/index.html?&ACTION=3& ...
Den supporten beide OS.
Wenns damit ins WLAN klappt ist die WLAN HW des Laptops defekt !
Die Tatsache das wirklich alle anderen Clients sauber arbeiten können ohne jegliche Einschränkungen untermauert das ja auch !
Das kann dann letztlich in der Tat einzig nur noch ein Problem des jeweiligen Clients sein.
Das das allerdings bei unterschiedlichen OS identisch ist, ist schon höchst ungewöhnlich. Zu 98% ist ja sowas immer irgendwelcher zusätzlicher Winblows Firewall Mist aber bei Linux entfällt das.
Da liegt der Verdacht dann doch nahe das das ein HW Fehler ist.
Da sollte man testweise mal in einen kleinen USB WLAN Stick investieren wie z.B. den hier:
http://www.reichelt.de/EDIMAX-EW-7811UN/3/index.html?&ACTION=3& ...
Den supporten beide OS.
Wenns damit ins WLAN klappt ist die WLAN HW des Laptops defekt !

Oder z.B. ein MAC-Filter (z.B. in der Fritz!Box)
Könnte man in der Tat denken aber....
Dagegen spricht aber ganz klar das sich der Client ja mit dem WLAN assoziieren kann und wie man oben am ipconfig Auszug ja sehen kann auch eine korrekte IP Adresse von diesem bekommt !
Mit Mac Filter im AP würde schon die Assoziierung mit dem AP fehlschlagen und keine IP oder eine 169.254.x.x APIPA IP vergeben, was der TO ja anfänglich aber wohl fälschlicherweise so geschildert hatte ?!
Hier könnte man jetzt noch eine Amok laufende Winblows Firewall oder letztere mit einem falschen Profil vermuten, die dann outgoing Verkehr blockt ?!
Deshalb ja nochmal die Bitte an den TO diesen Output auch mit Ubuntu und ifconfig zu machen !
Da ist das Risiko einer dichgenagelten Firewall geringer bzw. man kann sie schnell im Setup ausschalten (wie bei Winblows natürlich auch)
Fazit ist aber klar das das ein rein Client spezifisches Problem ist !
Dagegen spricht aber ganz klar das sich der Client ja mit dem WLAN assoziieren kann und wie man oben am ipconfig Auszug ja sehen kann auch eine korrekte IP Adresse von diesem bekommt !
Mit Mac Filter im AP würde schon die Assoziierung mit dem AP fehlschlagen und keine IP oder eine 169.254.x.x APIPA IP vergeben, was der TO ja anfänglich aber wohl fälschlicherweise so geschildert hatte ?!
Hier könnte man jetzt noch eine Amok laufende Winblows Firewall oder letztere mit einem falschen Profil vermuten, die dann outgoing Verkehr blockt ?!
Deshalb ja nochmal die Bitte an den TO diesen Output auch mit Ubuntu und ifconfig zu machen !
Da ist das Risiko einer dichgenagelten Firewall geringer bzw. man kann sie schnell im Setup ausschalten (wie bei Winblows natürlich auch)
Fazit ist aber klar das das ein rein Client spezifisches Problem ist !

MAC-Filter auf der Fritz!Box... Wobei ich zugegebenermaßen nicht genau weiß, ob dieser auch bei Clients greift die via Kabel über einen externen Access Point kommen. Er kommt ja durch den AP durch auf das NAS usw.
Kannst Du eigentlich die Fritz!Box anpingen? Was sagt denn ein nslookup auf www.heise.de bzw. wer antwortet da?
Laufen unter Umständen zwei DHCP-Server (einer auf der Box, einer auf dem AccessPoint)?
ob dieser auch bei Clients greift die via Kabel über einen externen Access Point kommen
Nein ! Nur einzig und allein dediziert mit dem AP mit dem sich der WLAN Client verbindet. So wie du es schilderst käme der ja auch über seine Kable Mac Adresse rein die für die Mac Filter Funktion eines WLAN APs aber völlig unerheblich ist, da der Filter einzig und allein nur die WLAN Absender MAC Adressen berücksichtigt !
Probiere es mal per lan oder anderen wlan (z.b. Handy-Hotspot oder so)

Im nächsten Schritt würde ich mal testweise die IP-Daten des Clients "von Hand" eintragen und in dem Zug die Routing-Tabelle kontrollieren.
Des Weiteren könnte man mal den WLAN-AccessPoint auf einen anderen Port der Fritz!Box hängen und die Geräte einmal neu durchstarten. Nicht, dass da irgendwo ein ARP-Cache o.Ä. vollgelaufen ist
Des Weiteren könnte man mal den WLAN-AccessPoint auf einen anderen Port der Fritz!Box hängen und die Geräte einmal neu durchstarten. Nicht, dass da irgendwo ein ARP-Cache o.Ä. vollgelaufen ist

Hm. Vielleicht hat sich da wirklich irgend etwas "weggehängt"?!? Boot tut gut.

Zitat von @117752:
feste IP für die MAC-Adresse des WLAN des Notebooks festgelegt, Notebook WLAN wieder aktiviert
feste IP für die MAC-Adresse des WLAN des Notebooks festgelegt, Notebook WLAN wieder aktiviert
Uiiii - mein erster "Fall", bei dem ich unmittelbar zur Lösung beigetragen habe^^
Und wenn Du das jetzt wieder auf DHCP ohne feste IP umstellst?