[gelöst] Probleme beim DHCPDISCOVER on wlan0/ath0

[luusa]

Hallo,

Distri Lenny, Kernel 2.6.26-1-686 [seit Anfang Juli 2.6.26-2-686]

lspci | grep Ethernet

Code: Alles auswählen

02:00.0 Ethernet controller: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)

/sbin/route

Code: Alles auswählen

Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.178.0   *               255.255.255.0   U     0      0        0 wlan0
link-local      *               255.255.0.0     U     1000   0        0 wlan0
default         foo             0.0.0.0         UG    0      0        0 wlan0

cat /etc/network/interfaces

Code: Alles auswählen

# The loopback network interface
auto lo
iface lo inet loopback

# WLAN - dhcp - wpa_supplicant
auto wlan0
iface wlan0 inet dhcp
	wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

cat /etc/wpa_supplicant/wpa_supplicant.conf

Code: Alles auswählen

ctrl_interface=/var/run/wpa_supplicant
eapol_version=1
ap_scan=1
network={
        ssid="foo"
        scan_ssid=1
        proto=WPA
        key_mgmt=WPA-PSK
        pairwise=TKIP
        group=TKIP 
        psk="meinschluessel"
}

So und nun zum Problem bzw. der Herausforderung! Ich habe WICD ausprobiert, mal den Madwifi und mal den Ndiswrapper (bei dem ich vor einigen Tagen wieder gelandet bin, wie zu guten alten Etch-Zeiten). Ein iwlist wlan0 scan http://nopaste.debianforum.de/21762 zeigt mir in allen Fällen genug APs (auch meinen mit dem richtigen Schlüssel ), nur beim Aushandeln des DHCPDISCOVER benötige ich in vielen Fällen mehrere Versuche (manchmal bis zu 10 x /etc/init.d/networking restart)! Zuerst dache ich, es sei ein WICD-Problem. Dort habe ich den Schlüssel immer wieder neu eingetragen (copy and paste). Dann habe ich es nach Studium einiger HOWTOs manuell eingerichtet, wie oben kurz skizziert. Der WICD war mir auch immer etwas undurchsichtig, aber schon schön "windowslike" .

Die entsprechenden Module ndiswrapper sind bei ath0 bzw. ath5k, mac80211, cfg80211 bei wlan0 "geblacklistet". Auch habe ich vor einigen Tagen den Madwifi für die Installation des Ndiswrapper spurenlos entfernt. So wie vorher beim Madwifi den Ndiswrapper. Mein Router ist eine Fritzbox 7113. Mit meinem Smartphone habe ich keine Einwahlprobleme. Ich resette auch oft parallel den Router. Was läuft da falsch? Die Sache nervt mittlerweile, weil manchmal möchte man schon gerne mal schnell ins Internet.

Wer weiß was?

Luusa

[luusa]

Ich fasse das nochmal kurz zusammen, weil man in dem vorigen Beitrag möglicherweise nicht das Wesentliche erkennt:

1. WLAN läuft, weil Module werden geladen, AP wird erkannt.
2. Nur die Übermittlung der DHCP endet beim Booten mit diesem hier:

Code: Alles auswählen

Listening on LPF/wlan0/00:16:ag:97:49:05
Sending on   LPF/wlan0/00:16:ag:97:49:05
Sending on   Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 21
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

Es bedarf dann z. T. mehrerer "/etc/init.d/networking restart" um das hier zu erreichen:

Code: Alles auswählen

Listening on LPF/wlan0/00:16:ag:97:49:05
Sending on   LPF/wlan0/00:16:ag:97:49:05
Sending on   Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4
DHCPOFFER from 192.168.178.1
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPACK from 192.168.178.1
bound to 192.168.178.27 -- renewal in 344220 seconds.
done.

Die Einstellungen der network/interfaces und des wpa_supplicant stehen im vorigen Post!

Das Notebook ist im Router mit der MAC-Adresse eingetragen und soll die 192.168.178.27 zugewiesen bekommen:

Code: Alles auswählen

Bekannte Netzwerkgeräte - WLAN
IP-Adresse           MAC-Adresse           Datenrate       Eigenschaften
192.168.178.27    00:16:AG:97:49:05           48 MBit/s        WPA, WMM

Luusa

[chr.gogolin]

Ich weiß nicht ob ich weiterhelfen kann, aber:

Hast du mal versucht anstatt "/etc/init.d/networking restart" nur den dhcp-client zu killen und dann manuell neu zu starten, oder die Verbindung über wpa_cli durch "disconnect" und dann "reconnect" neu aufzubauen?

[luusa]

Heijo,

werde ich beim nächsten DHCPDISCOVER alles mal ausprobieren, wenn ich wieder an dem Rechner sitze.

Luusa

[luusa]

Heute habe ich mich dann mal wieder an den Rechner mit den vielen Herausforderungen gesetzt!

Wie üblich gab es beim Aushandeln mit dem Router keine Anbindung beim Booten.

Ob das

Code: Alles auswählen

wpa_cli reconfigure wlan0

wirklich den Router

Code: Alles auswählen

default         fuu  0.0.0.0         UG    0      0        0 wlan0

dem Rechner bekannt gemacht hat, so dass schließlich ein

Code: Alles auswählen

/etc/init.d/networking restart

die Anbindung geschafft hat, werde ich erst glauben können, wenn die Sache reproduzierbar ist. Blöderweise hatte ich vorher kein

Code: Alles auswählen

/sbin/route

aufgerufen. In der Vergangenheit stand aber immer, bei negativem Aushandeln, statt "fuu" kein Eintrag!

Also warten wir mal die nächsten Tage ab.

Ich habe ja auch immer noch die Hoffnung, dass sie Sache auch bereits beim Booten funktionieren sollte!

Wenn's läuft, läuft's mit dem Ndisrapper schon mal stabiler als mit dem Madwifi - das ist ja auch schon einmal was!

Schauen wir mal!

Wie ich gerade sehe, sollte ich

Hast du mal versucht anstatt "/etc/init.d/networking restart" nur den dhcp-client zu killen und dann manuell neu zu starten, oder die Verbindung über wpa_cli durch "disconnect" und dann "reconnect" neu aufzubauen?

kein reconfigure durchführen, sondern ein "disconnect" und dann ein "reconnect". Da ich hatte ich mir das doch gestern falsch gemerkt! Egal, ich werde den Rechner ja noch häufiger benutzen. Über die weitere Entwicklung gibt's dann hier demnächst mehr.


Luusa

[luusa]

Nicht reproduzierbar. Heute klappte es dafür nach einmal "networking restart ".

wpa_cli disconnect und reconnect half leider auch nicht weiter.

[luusa]

Zwischenstand - kein Aushandeln des DHCPDISCOVER beim Booten - hangele mich weiterhin mit "/etc/init.d/networking restart" durch.

[luusa]

Nach über vier Wochen im praktischen Gebrauch, kann ich sagen, dass es mit dem DHCPDISCOVER gelegentlich sofort klappt (also beim Booten), zumeist beim zweiten oder dritten Neustart des Netzwerkes (networking restart). Ganz selten dauert's mal vier oder mehr Versuche.

Aber nach welcher Gesetzmäßigkeit hier Router und Rechner ihre Abstimmung vornehmen, ist mit schleierhaft. Für die Linux-Hasser im Bekanntenkreis (also die ohne besonderen Bezug zu PCs; Computer müssen die Arbeit tun, mehr nicht) ein Grund mehr ihr schönes, benutzerfreundliches Windows zu loben. Ich stehe da so dazwischen. Ich mag Windows nicht, aber bei aller Liebe und allem Anderen, manchmal nervt es mich - besonders wenn es mal schnell gehen muss!

Kennt das Problem beim DHCPDISCOVER niemand sonst? Bin ich da wirklich alleine?

Luusa

[chr.gogolin]

Um das Problem ein wenig einzugrenzen wäre es interessant folgendes zu versuchen:

1) Booten
2) Warten bis DHCPDISCOVER fehlschlägt
3) Den dhclient killen
4) Den dhclient manuell neu starten 'dhclient wlan0'
5) Die Schritte 3 und 4 so lange wiederholen bis es klappt oder man sicher sein kann dass es nicht mehr klappen wird

Wenn sich duch mehrmaliges Neustarten des dhclient das Problem lösen lässt wäre dass ein starker Hinweis dass das Problem wirklich vom dhclient verursacht wird und ansonsten mit dem Netzwerk alles funktioniert.

[luusa]

Mit dem Netzwerk klappt sonst alles. Der am Router angekabelte Server läuft ohne Probs. Das per WLAN verbundene Smartphone (Symbian OS) hat auch keine Probleme sich einzuwählen. Das legt meiner Meinung nach ganz klar an Lenny! Oder gibt es Hardware, die hier Schuld sein könnte? Ich glaube das nicht so!

[123456]

Damit du nicht jedes Mal "/etc/init.d/networking start" eingeben musst und DHCP schon beim Starten bereitsteht, versuch mal.

Code: Alles auswählen

update-rc.d networking defaults

und neu booten.

[luusa]

Damit du nicht jedes Mal "/etc/init.d/networking start" eingeben musst und DHCP schon beim Starten bereitsteht, versuch mal.

Code: Alles auswählen

update-rc.d networking defaults

und neu booten.

"Start" gebe ich nicht ein. Networking steht schon beim Start bereit. Leider klappt's halt nicht immer, weil das Aushandeln mit dem Router über den DHCP-Client nicht immer funktioniert. Erst dann gebe ich im Terminalfenster ein Restart (kein Start) ein.

Das Killen des dhclient und anschließendes dhclient wlan0 - wie im vorigen Eintrag - gab bislang eine Trefferquote nach zwei Versuchen von eins. D. h. hier z. Z. keine Fehlversuche.

Ich werde das die nächsten Tage versuchen zu reproduzieren. Für mich bestätigt sich mittlerweile immer mehr, dass das eindeutig an der Software, nicht an der Hardware und auch nicht an meiner Konfiguration liegt.

Luusa

[123456]

und wenn du einfach eine statische IP nimmst?

[luusa]

und wenn du einfach eine statische IP nimmst?

Das mit der statischen IP habe ich mir bis zuletzt aufgespart. Das ist schließlich ein Notebook und damit will ich auch mal über andere Netzwerke bei Freunden (alles Windwos-User) ins Internet. Dabei möchte ich dann jedoch nur den wpa-supplicant anpassen. Prinzipsache halt! Ein paar Ansprüche habe ich schließlich auch noch, auch wenn ich wegen Linux schon einige Kompromisse eingehe! Man hat sich ja daran gewöhnt. DHCP läuft schließlich mittlerweile bei jedem.

Aber wenn alles nichts hilft, kommt die statische IP zum Zuge. Ganz zum Schluss steht dann auch wieder die Verkabelung! Es ist schon traurig. Wenn's mit den dauernden Restarts nicht geklappt hätte, wäre ich schon längst wieder soweit.

Schön ist aber auch schnurlos, mal vom Balkon oder vom jedem Zimmer aus, ins Internet zu können bzw. Daten auf den Server zu schieben, oder?

Luusa

[habakug]

Hallo!

Du kannst versuchen die SSID in die interfaces aufzunehmen:

Code: Alles auswählen

# WLAN - dhcp - wpa_supplicant
auto wlan0
iface wlan0 inet dhcp
   wpa-ssid FOO
   wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Die Eintrage in der wpa_supplicant.conf "ap_scan" und "scan_ssid" solltest du entfernen.
Am besten du erstellst die wpa_supplicant.conf so:

Code: Alles auswählen

wpa_passphrase "SSID" geheimesPasswort >> /etc/wpa_supplicant/wpa_supplicant.conf

Gruß, habakug

[luusa]

Gemacht, werde ich die nächsten Tage ausprobieren!

[chr.gogolin]

Also Entschuldigung Leute aber ne statische ip ist wohl keine Lösung.

Das Killen des dhclient und anschließendes dhclient wlan0 - wie im vorigen Eintrag - gab bislang eine Trefferquote nach zwei Versuchen von eins. D. h. hier z. Z. keine Fehlversuche.

Wie meinst du das? Klappt es immer nach dem ersten kill/Neustart des dhclient oder nach dem zweiten Versuch, oder manchmal so mal so?

Wenn das killen und Neustarten des dhclients ausreicht um das Problem zu beheben, dann liegt es am dhclient und dann müssen wir da weiter suchen.

[123456]

Also Entschuldigung Leute aber ne statische ip ist wohl keine Lösung.

Wenns funktioniert ist es schon ein Lösung.

Sonst würde ich es auch als a) Workaround und b) Test bezeichnen - dann sieht man ob dhcp wirklich das Problem ist.
Diese dhcpdiscover Meldungen kenne ich auch vor allem dann, wenn der Treiber unsauber lief, aber das nur am Rande.

[luusa]

Wie meinst du das? Klappt es immer nach dem ersten kill/Neustart des dhclient oder nach dem zweiten Versuch, oder manchmal so mal so?

Also nach dem Killen klappte es beim ersten Versuch.

Ich habe allerdings inzwischen alles (außer ssid und psk im network ) aus der supplicant-Konfiguration auskommentiert, sowie es habakug vorgeschlagen hatte:

Code: Alles auswählen

#ctrl_interface=/var/run/wpa_supplicant
#eapol_version=1
#ap_scan=1
network={
        ssid="foo"
        #scan_ssid=1
#        proto=WPA
#        key_mgmt=WPA-PSK
#        pairwise=TKIP
#        group=TKIP 
        psk="meingeheimerSchluessel"
}

Damit hatte ich gestern nach drei absichtlich vorgenommenen Boots nur einmal keinen Erfolg beim Booten, dafür dann aber direkt beim networking restart. Heute klappte es beim ersten Boot sofort. Sollte das die nächsten Tage so bleiben, ist das schon mehr als zuvor. Witzigerweise hatte ich meine ursprüngliche Konfiguration mit den vielen Parametern einem Howto für den Supplicant entnommen. Also geht's scheinbar auch mit weniger!? Da ich damals kein WPA2

Code: Alles auswählen

        proto=RSN
        pairwise=CCMP
        group=TKIP

, sondern nur WPA hinbekam, wundert es mich jetzt, dass ich ohne die vielen Parameter direkt eine Verbindung über WPA2 erhalte (der Router kann beides

Code: Alles auswählen

                    IE: IEEE 802.11i/WPA2 Version 1

                        Group Cipher : TKIP

                        Pairwise Ciphers (1) : CCMP

                        Authentication Suites (1) : PSK

                    IE: WPA Version 1

                        Group Cipher : TKIP

                        Pairwise Ciphers (1) : TKIP

                        Authentication Suites (1) : PSK

).



Es bleibt spannend. Über weitere Erfolge/Misserfolge demnächst mehr!

Luusa

[luusa]

Hallo,

also, das Problem scheint gelöst. Gestern mit der abgespeckten Konfiguration des Supplicant per DHCP ohne Probleme eingeloggt.

Ich ändere die Konfiguration jetzt wie folgt:

Code: Alles auswählen

network={
        ssid="foo"
        psk="meingeheimerSchluessel"
}

Schön, dass das auch so einfach geht.

Vielen Dank an alle, die mir geholfen haben.

Luusa

[chr.gogolin]

Freut mich, dass jetzt alles klappt und wir endlich eine wirkliche Lösung gefunden haben!

Wenn du noch Motivation hast könntest du dich ja mal mit den Entwicklern in Verbindung setzten um der Ursache des Übels auf den Grund zu gehen.

[luusa]

Jaaah, schön wäre es gewesen. Gestern Updates bekommen, nach Updates habe ich schon seit einiger Zeit Angst. Gerade das Notebook gestartet, um mal eben etwas machen. Normales Booten, kein DHCPDISCOVER - alles gecheckt (siehe Anfang dieses Threads), dmesg mit Auszügen hier:

Code: Alles auswählen

[   11.115185] ndiswrapper version 1.53 loaded (smp=yes, preempt=no)
[   11.233469] ndiswrapper: driver net5211 (,10/26/2007,5.3.0.85) loaded
[   11.233469] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 16
[   11.233469] PCI: Setting latency timer of device 0000:02:00.0 to 64
[   11.461959] usb-storage: device scan complete
[   11.481061] scsi 5:0:0:0: Direct-Access     Generic- xD/SDMMC/MS/Pro  1.00 PQ: 0 ANSI: 0 CCS
[   11.486077] sd 5:0:0:0: [sdb] Attached SCSI removable disk
[   11.646221] ndiswrapper: using IRQ 16
[   11.850501] wlan0: ethernet device 00:15:af:97:49:05 using serialized NDIS driver: net5211, version: 0x50003, NDIS version: 0x501, vendor: 'NDIS Network Adapter', 168C:001C.5.conf
[   11.857868] wlan0: encryption modes supported: WEP; TKIP with WPA, WPA2, WPA2PSK; AES/CCMP with WPA, WPA2, WPA2PSK
[   11.863450] usbcore: registered new interface driver ndiswrapper

WLAN-Lämpchen kurz vor dem Anmeldescreen (nach Starten des x-Servers) selbsttätig auf aus. Gestern die üblichen Updates gemäß update-notifier eingespielt. Heute geht da mal (wieder) WLAN-mäßig nichts. Ndisrapper-Modul geprüft, geladen. Rechner angehalten, neu hochgefahren, nichts. Kein Scannen von Netzwerken, das WLAN wohl wirklich nicht verfügbar (Lämpchen) - Router resettet, Rechner hochgefahren, diesmal blieb das WLAN-Lämpchen an! Die Chance! Zufall? Dann dhclient gekillt, dann

Code: Alles auswählen

 
dhclient wlan0 
[...]
Listening on LPF/wlan0/00:15:af:97:49:05
Sending on   LPF/wlan0/00:15:af:97:49:05
Sending on   Socket/fallback
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPACK from 192.168.178.1
bound to 192.168.178.27 -- renewal in 430123 seconds.

Ich halte mich für einen mehr oder weniger erfahrenen Anwender, der es geschafft hat, über mehrere Jahre seit 2003, jeden Rechner mit Debian ans Laufen zu kriegen! Den Fileserver von 2002 zähle ich nicht, da das nun wirklich zu einfach war. Dabei bin ich Einzelkämpfer, da im Bekanntenkreis keiner dabei, der ähnlich tickt. Aber dieses WLAN macht mich echt wahnsinnig! Wie gesagt, mit dem Smartphone (Symbian) keine Probleme, also halte ich den Router weiterhin für unschuldig! Debian-Stable habe ich mir ausgesucht, wegen "stable", ich bin kein Tester, bei mir sollen die Sachen laufen. Das taten sie auch bisher.

Luusa

[luusa]

Tja, diesem einen Ausfall von gestern kann ich mehrere einwandfreie Bootvorgänge, die ich absichtlich herbeigeführt habe, entgegenhalten.

Von der Installation und Konfiguration müsste alles einwandfrei funktionieren. Warum es zeitweise nicht klappt, kann ich nicht sagen. Da hilft nur weiter beobachten. Daher habe ich das Thema mal wieder auf "gelöst" gesetzt.

Luusa

[luusa]

Gestern wieder zwei Ausfälle beim Booten (kein DHCPOFFER, Router i. O.), danach networking restart, dann IP-Adresse erhalten. Warum das so ist? Keine Ahnung! Das Ding nervt, aber ich werde wohl damit leben müssen. Von wegen "stable", entweder hat sich Debian verschlechtert oder meine Anforderungen sind gestiegen!

[chr.gogolin]

Kannst du außschließen, dass es an der Hardware liegt? Bei völlig indeterministischen Fehlern ist das häufig der Grund...