WLAN-AP verweigert Verbindung (nach Ping of Death ?)

[Natureshadow]

Moin,

schon ewig habe ich das Problem, dass mein US-Robotics-Access Point den kabellosen Zugang für einzelen CLients deaktiviert. Beteiligt sind daran der AP, ein Notebook mit Intel-Hardware und Linux (mehrere DIstributionen getestet) sowie ein Windows XP-Client mit Prism-Chip.

Der Windows-PC kann keine Wifi-Verbindung nach dem Notebook aufbauen, das Notebook bekommt nie Probleme. Beim AP geht nicht mal eine Verbindungsanfrage ein, der 4-way-Handshake (WPA-PSK) wird also nicht einmal gestartet.

Heute fiel mir dann in den Logs des Access Points ein merkwürdiges Verhalten seitens des Notebooks auf: http://www.naturalnik.de/Bildschirmfoto-3.png

192.168.159.202 ist das Notebook und haut offenbar ganz gewaltig mit Ping of Deaths gegen eine Adresse ein, die verstärkt an eine Multicast-Adresse erinnert (aber wahrscheinlich keine ist).

Ob diese beiden DInge etwas miteinander zu tun haben, weiß ich nicht - vielleicht hat dazu jemand eine Idee ...

Grüße,
Nik

[rendegast]

google PingPong-of-Death
http://de.wikipedia.org/wiki/Ping_of_Death

Der Windows-PC kann keine Wifi-Verbindung nach dem Notebook aufbauen,

Nach dem Notebook oder nach dem Robotics-AP?

das Notebook bekommt nie Probleme.

Dito, Verbindung mit dem AP oder Ping auf den Windows-PC?

Beim AP geht nicht mal eine Verbindungsanfrage ein, der 4-way-Handshake (WPA-PSK) wird also nicht einmal gestartet.

Ist dann wohl das Problem des Windows-PC?
Macht Windows (Zero-Conf, ich empfehle diese Variante) die Wifi-Verbindung oder ein Frontend-Programm, zBsp des Herstellers?
Mal die gespeicherte Verbindung löschen und neu anlegen,
vielleicht muß der PSK dabei per Hand eingetippt werden
(hatte schon Varianten, bei denen ein Copy+Paste nicht funktioniert hat).
Stimmen die automatisch ermittelten Verbindungsparameter, wie Verschlüsselung, Infra/Ad-hoc usw.?

Mit Prism (Karte? Stick?) kann das Linux-Notebook eine Verbindung aufbauen?
(Vielleicht ist ja die Hardware defekt?)

[Natureshadow]

Hi,

vielen Dank für die vielen Ideen. Leider passt aber nichts davon zu meinem Problem, da es hier ausschließlich um die Reihenfolge

- AP startet
- Lin-Notebook startet
- Win-PC startet

geht.

Was ein Ping of Death ist, ist mir durchaus geläufig, umso erstaunter bin ich, dass mein System solche vermurksten Pakete absetzt ...

Grüße,
Nik

[habakug]

Hallo!

Das sieht nach mDNS aus. Ist wohl harmlos.

Gruß, habakug

http://www.it-administrator.de/lexikon/ ... t-dns.html

[rendegast]

Der Windows-PC kann keine Wifi-Verbindung nach dem Notebook aufbauen, das Notebook bekommt nie Probleme.

Nie Probleme mit was?

da es hier ausschließlich um die Reihenfolge
- AP startet
- Lin-Notebook startet
- Win-PC startet
geht.

Warum sollte die Reihenfolge da wichtig sein?
?
Ich verstehe leider nicht, was das Problem ist.
EDIT
Warum sollte das Notebook der Win-PC eine Verbindung zum Linux-PC Linux-notebook aufbauen können,
wenn es nicht einmal in das Netz des AP gelangt?




----- EDIT , hier habe ich den ersten Post falsch gelesen,
----- daß die Ping als source-IP die des nicht verbindenden Win-PC hätten:

Beim AP geht nicht mal eine Verbindungsanfrage ein, der 4-way-Handshake (WPA-PSK) wird also nicht einmal gestartet.

Wenn die Karte? / Stick? kaputt wäre und nicht sendet,
kann auch nichts beim AP registriert werden.
Die am AP registrierten Pings können dann auch nicht vom Windows-PC stammen,
das wäre ein anderes Problem(?).

Das sieht nach mDNS aus. Ist wohl harmlos.

Oder stammen die Ping wirklich vom Windows-PC, dann hat er ja Verbindung zum AP.
Und die Ping kommen dann von einem Windows-Dienst oder einem Schadprogramm?

[Natureshadow]

Hallo,

aus meinem allerersten Beitrag geht hervor, dass:

• die Pings vom Linux-Notebook kommen
• die Verbindung vom WIndows-PC möglich ist, außer ....
• .... wenn das Linux-Notebook sich vorher vrbindet

-nik

[Natureshadow]

mDNS scheidet meiner Meinung nach übrigens aus, da ich schon ziemlich genau weiß, was in meinem Netzwerk abgeht. Und mDNS sollte definitiv nicht dazu gehören , hier wird immer noch klassisch mit ISC-Software für DHCP und DNS gearbeitet (was mDNS noch nicht ausschließen würde, aber seid versichert: hier gibt's kein mDNS ).

-nik

[rendegast]

aus meinem allerersten Beitrag geht hervor, dass:
* die Pings vom Linux-Notebook kommen

Da habe ich ja wirklich die Maschinen vertauscht, tut mir leid, werde mich bessern.

aus meinem allerersten Beitrag geht hervor, dass:
* die Verbindung vom WIndows-PC möglich ist, außer ....
* .... wenn das Linux-Notebook sich vorher vrbindet

Nein, erst jetzt

Den Versender der Ping sollte sich mit 'netstat -tpaun' o.ä. schnell klären lassen

Ist das notebook auch über WLAN angeschlossen?
Oder ist aus Nichterwähnung dessen darauf zu schließen, das es über Kabel angeschlossen ist?

Typ des AP? firmware-Version?

[123456]

ok, von mir auch ein bisschen Senf...

zuerst: google mal nach "u.s.robotics und ping of death".

und habakugs Hinweis mit dem mdns finde ich passend, da es genau die IP ist den der Robotics anmeckert.
Wenns als kein mdns ist schau mal, ob auf dem Linux Laptop ein zeroconf läuft - den würde ich dann testweise mal deaktivieren. Der könnte bsp. den Robotics antriggern die Fehlermeldungen auszuspucken.

[Natureshadow]

Und tatsächlich, auf dem Notebook läuft ein böser mDNS-Dienst (schäm), aber auch nur unter Ubuntu .... unter Debian und Gentoo tut er das nicht, da gibt's auch keine "Pings of Death". DIe Symptomatik bleibt aber die gleiche.

Wir streichen die Pings of Death also aus diesem Thread und überlegen, wieso der WIndows-PC nicht ins WLAN darf.

Das Notebook ist auch per WLAN angebunden.

Welches AP-Modell das ist muss ich mal irgendwie raus finden, komme da geraden icht physikalisch ran ...

-nik

[123456]

Wir streichen die Pings of Death also aus diesem Thread und überlegen, wieso der WIndows-PC nicht ins WLAN darf.

rendegast hat ja schon Vorschäge gemacht.

unabhängig von einer aktuellen Firmware würde ich auf dem Robotics mal schauen, ob dort die HW Adressen der Clients extra zugelassen werden müssen, oder ob der Win PC vielleicht geblockt wird.

[Natureshadow]

Hi,

alles das, was hier vorgeschlagen wird, wäre dann akkurat, wenn der PC *nie* ins WLAN dürfte.

Noch einmal: Es gibt nur Probleme, wenn das Notebook _vor_ dem WIndows-PC verbindet. Wenn es das nicht tut, kommt der WIndows-PC problemlos rein.

-nik

[rendegast]

Welches AP-Modell das ist muss ich mal irgendwie raus finden, komme da geraden icht physikalisch ran ...

Du hast doch Zugang zum Web-Interface,
Dort müßten auch irgendwo Typ und firmware verzeichnet sein. > "Status" zBsp.

Wenn sich bei allen gestarteten Systemen auf dem Notebook das Verhalten gleicht, so liegt es auch nicht an deren Einstellungen.
Scheint eher beim Robotics etwas verstellt.

Kannst Du das Gerät auf Werkseinstellungen zurücksetzen?
Und von da aus wieder neu konfigurieren.
(DSL-Zugangsdaten sollten dann zur Hand sein.)

[Natureshadow]

Hi,

nein, das furchtbar schlaue Webinterface gibt dazu keine Infos.

Mit den Werkseinstellungen versuche ich mal .... aber ich bin mir recht sicher, durchaus einen AP korrekt konfigurieren zu können .

Das DIng spielt übrigens ausschließlich AP. Weder DHCP- noch DNS-Server, kein Gateway (nicht mal intern, Wifi- und Ethernet sind interne gebridged) und sonst auch nix. EInfach nur AP.

-nik

[habakug]

Hallo!

Das DIng spielt übrigens ausschließlich AP. Weder DHCP- noch DNS-Server, kein Gateway (nicht mal intern, Wifi- und Ethernet sind interne gebridged) und sonst auch nix. EInfach nur AP.

Das hört sich ziemlich seltsam an, was du da erzählst. Warum darf dein AP nicht einfach im "Schweine-Standard-Modus" laufen? Welchen DNS/Gateway teilst du den Rechnern denn zu?

Gruß, habakug

[Natureshadow]

Im Netz hängt ein Debian-Server.

Ist das ok für dich ?

-nik

[rendegast]

Mit den Werkseinstellungen versuche ich mal .... aber ich bin mir recht sicher, durchaus einen AP korrekt konfigurieren zu können

Geht darum, das Gerät in einen definierten Zustand zu versetzen,
um Fehlerquellen auszuschließen und für Hardwareinhaber das Problem nachstellbarer zu machen.

mDNS scheidet meiner Meinung nach übrigens aus, da ich schon ziemlich genau weiß, was in meinem Netzwerk abgeht. Und mDNS sollte definitiv nicht dazu gehören

Und tatsächlich, auf dem Notebook läuft ein böser mDNS-Dienst (schäm),

Du hast noch keine Angaben zum Gerät/Treibersoftware/Windows des Windows-PC gemacht.
Dort Tausch der Hardware/Treibersoftware versuchen? Stick für 10-20 Euro?
(Ich habe hier DWA-140 (40Euro, rt2870), der direkt mit dem Treiber von ralinktech arbeiten kann.
Viele Sticks mit rt*-Chip können das so nicht, (alle?) schaffen es aber mit einem Eintrag der USB-ID in der *.inf,
Bsp DWL-G122, oder Belkin FD7050A v3.)



------------------------------

schon ewig habe ich das Problem

Hat es mit einem Update oder Hardwareanschaffung angefangen?
firmware-Updates versucht? Treiberupdates versucht? Schon bei anderer Hardware?
zBsp:
Vielleicht liegt noch irgendwo ein alter wireless-DSL-Router herum?
Wenn der die Clients gleichzeitig bindet, würde der Fehler beim Robotics liegen.

[Natureshadow]

Das Problem hat sich mehr oder weniger gelöst: Aus irgendwelchen Gründen macht hier irgendwas unter irgendwelchen Umständen nur 802.11b. Ich hab dem AP erlaubt im "Mixed Mode" zu arbeiten, nun gibts keine Probleme mehr.

Da daran win Windows beteiligt ist, spare ich mir weiteres Debuggen.

-nik