Großer allgemeiner "WLAN-Probleme-Thread!!

T

tgraupne

New member
Themenstarter
Registriert
25 Feb. 2008
Beiträge
2.008
Da ähnliche Probleme zur Zeit sehr häufig auftreten, wollte ich die Diskussion aus dem "iwlagn power save" thread mal raus holen.

Bei mir wird es gerade so schlimm, dass ich kaum noch mit dem Gerät in der Uni arbeiten kann. Es handelt sich bei mir um ein X61s mit Intel 5100 WLAN Card. Diese beherrscht 5GHz und 150MB/s, normalerweise ;)

Ich nutze den Kernel 2.6.32-5-686, imo Standard bei Debian 6 stable.

Nun zu meinen Problemen:

  1. Beim Booten zeigt mir mein Kernel, dass die Version meiner WLAN firmware nicht aktuell ist und empfiehlt ein update. Die Daten soll es bei www.linuxwireless.org geben. Abgesehen davon, dass ich sie dort nicht finde, habe ich auch ein paar Erfahrungsberichte gefunden, die sagen, dass neuere Versionen noch weniger funktionieren sollen.
  2. Bestehende WLAN Verbindungen sind sehr sehr instabil. Alle paar Sekunden verliere ich die Verbindung. Das thinkpad versucht dann neu zu verbinden, doch dann bekomme ich hier im Uni- WLAN ein paar timeouts und so dauert es sehr lange. Dadurch werden die Abbrüche immer spürbar. Ich habe bereits gelesen, dass dies wohl sehr oft auftritt, Ubuntu nur irgendwann aufgehört hat den Abbruch direkt anzuzeigen sondern im Hintergrund einfach immer wieder neu verbindet.

    Hier ein exemplarischer dmesg output:
    Code: 
    [ 3513.728084] wlan1: deauthenticating from c4:7d:4f:57:82:5d by local choice (reason=3)
[ 3513.729464] wlan1: direct probe to AP c4:7d:4f:57:82:52 (try 1)
[ 3513.928306] wlan1: direct probe to AP c4:7d:4f:57:82:52 (try 2)
[ 3514.128139] wlan1: direct probe to AP c4:7d:4f:57:82:52 (try 3)
[ 3514.328059] wlan1: direct probe to AP c4:7d:4f:57:82:52 timed out
[ 3526.614831] wlan1: direct probe to AP c4:7d:4f:57:82:5d (try 1)
[ 3526.812132] wlan1: direct probe to AP c4:7d:4f:57:82:5d (try 2)
[ 3526.812933] wlan1: direct probe responded
[ 3526.812942] wlan1: authenticate with AP c4:7d:4f:57:82:5d (try 1)
[ 3526.814559] wlan1: authenticated
[ 3526.814649] wlan1: associate with AP c4:7d:4f:57:82:5d (try 1)
[ 3526.816900] wlan1: RX AssocResp from c4:7d:4f:57:82:5d (capab=0x111 status=0 aid=6)
[ 3526.816907] wlan1: associated
[ 3526.818914] wlan1: deauthenticated from c4:7d:4f:57:82:5d (Reason: 4)
[ 3526.966682] wlan1: direct probe to AP c4:7d:4f:57:8f:1d (try 1)
[ 3527.164291] wlan1: direct probe to AP c4:7d:4f:57:8f:1d (try 2)
[ 3527.364294] wlan1: direct probe to AP c4:7d:4f:57:8f:1d (try 3)
[ 3527.564084] wlan1: direct probe to AP c4:7d:4f:57:8f:1d timed out
[ 3529.354686] wlan1: direct probe to AP c4:7d:4f:57:82:5d (try 1)
[ 3529.356977] wlan1: direct probe responded
[ 3529.356981] wlan1: authenticate with AP c4:7d:4f:57:82:5d (try 1)
[ 3529.358800] wlan1: authenticated
[ 3529.358821] wlan1: associate with AP c4:7d:4f:57:82:5d (try 1)
[ 3529.360762] wlan1: RX AssocResp from c4:7d:4f:57:82:5d (capab=0x111 status=0 aid=6)
[ 3529.360766] wlan1: associated
[ 3542.940574] iwlagn 0000:03:00.0: iwl_tx_agg_start on ra = c4:7d:4f:57:82:5d tid = 0
[ 3653.460073] wlan1: deauthenticating from c4:7d:4f:57:82:5d by local choice (reason=3)
[ 3653.477379] wlan1: direct probe to AP c4:7d:4f:52:73:d2 (try 1)
[ 3653.680056] wlan1: direct probe to AP c4:7d:4f:52:73:d2 (try 2)
[ 3653.682057] wlan1: direct probe responded
[ 3653.682061] wlan1: authenticate with AP c4:7d:4f:52:73:d2 (try 1)
[ 3653.683588] wlan1: authenticated
[ 3653.683608] wlan1: associate with AP c4:7d:4f:52:73:d2 (try 1)
[ 3653.686888] wlan1: RX AssocResp from c4:7d:4f:52:73:d2 (capab=0x431 status=0 aid=5)
[ 3653.686891] wlan1: associated
[ 3713.620296] wlan1: deauthenticating from c4:7d:4f:52:73:d2 by local choice (reason=3)
[ 3713.621633] wlan1: direct probe to AP c4:7d:4f:52:63:22 (try 1)
[ 3713.820306] wlan1: direct probe to AP c4:7d:4f:52:63:22 (try 2)
[ 3714.020161] wlan1: direct probe to AP c4:7d:4f:52:63:22 (try 3)
[ 3714.220079] wlan1: direct probe to AP c4:7d:4f:52:63:22 timed out
[ 3726.494816] wlan1: direct probe to AP c4:7d:4f:57:82:5d (try 1)
[ 3726.692263] wlan1: direct probe to AP c4:7d:4f:57:82:5d (try 2)
[ 3726.693138] wlan1: direct probe responded
[ 3726.693144] wlan1: authenticate with AP c4:7d:4f:57:82:5d (try 1)
[ 3726.693896] wlan1: authenticated
[ 3726.693938] wlan1: associate with AP c4:7d:4f:57:82:5d (try 1)
[ 3726.696257] wlan1: RX AssocResp from c4:7d:4f:57:82:5d (capab=0x111 status=0 aid=6)
[ 3726.696262] wlan1: associated
[ 3793.276385] wlan1: deauthenticating from c4:7d:4f:57:82:5d by local choice (reason=3)
[ 3793.277922] wlan1: direct probe to AP c4:7d:4f:52:63:22 (try 1)
[ 3793.476302] wlan1: direct probe to AP c4:7d:4f:52:63:22 (try 2)
[ 3793.676143] wlan1: direct probe to AP c4:7d:4f:52:63:22 (try 3)
[ 3793.876333] wlan1: direct probe to AP c4:7d:4f:52:63:22 timed out
[ 3806.179293] wlan1: direct probe to AP c4:7d:4f:57:82:5d (try 1)
[ 3806.376443] wlan1: direct probe to AP c4:7d:4f:57:82:5d (try 2)
[ 3806.377185] wlan1: direct probe responded
[ 3806.377193] wlan1: authenticate with AP c4:7d:4f:57:82:5d (try 1)
[ 3806.378262] wlan1: authenticated
[ 3806.378353] wlan1: associate with AP c4:7d:4f:57:82:5d (try 1)
[ 3806.380139] wlan1: RX AssocResp from c4:7d:4f:57:82:5d (capab=0x111 status=0 aid=6)
[ 3806.380148] wlan1: associated
[ 3807.958233] iwlagn 0000:03:00.0: iwl_tx_agg_start on ra = c4:7d:4f:57:82:5d tid = 0
[ 3875.149163] CE: hpet increasing min_delta_ns to 22500 nsec
[ 3893.896302] wlan1: deauthenticating from c4:7d:4f:57:82:5d by local choice (reason=3)
[ 3893.897925] wlan1: direct probe to AP c4:7d:4f:51:e7:32 (try 1)
[ 3894.096318] wlan1: direct probe to AP c4:7d:4f:51:e7:32 (try 2)
[ 3894.296109] wlan1: direct probe to AP c4:7d:4f:51:e7:32 (try 3)
[ 3894.496095] wlan1: direct probe to AP c4:7d:4f:51:e7:32 timed out
[ 3906.678436] wlan1: direct probe to AP c4:7d:4f:57:8c:12 (try 1)
[ 3906.876334] wlan1: direct probe to AP c4:7d:4f:57:8c:12 (try 2)
[ 3907.076267] wlan1: direct probe to AP c4:7d:4f:57:8c:12 (try 3)
[ 3907.276085] wlan1: direct probe to AP c4:7d:4f:57:8c:12 timed out
[ 3912.093325] wlan1: direct probe to AP c4:7d:4f:57:8c:12 (try 1)
[ 3912.292331] wlan1: direct probe to AP c4:7d:4f:57:8c:12 (try 2)
[ 3912.492112] wlan1: direct probe to AP c4:7d:4f:57:8c:12 (try 3)
[ 3912.692273] wlan1: direct probe to AP c4:7d:4f:57:8c:12 timed out
[ 3924.862992] wlan1: direct probe to AP c4:7d:4f:57:82:5d (try 1)
[ 3925.060332] wlan1: direct probe to AP c4:7d:4f:57:82:5d (try 2)
[ 3925.260299] wlan1: direct probe to AP c4:7d:4f:57:82:5d (try 3)
[ 3925.261237] wlan1: direct probe responded
[ 3925.261246] wlan1: authenticate with AP c4:7d:4f:57:82:5d (try 1)
[ 3925.262198] wlan1: authenticated
[ 3925.262289] wlan1: associate with AP c4:7d:4f:57:82:5d (try 1)
[ 3925.264488] wlan1: RX AssocResp from c4:7d:4f:57:82:5d (capab=0x111 status=0 aid=6)
[ 3925.264496] wlan1: associated
[ 3956.047469] iwlagn 0000:03:00.0: iwl_tx_agg_start on ra = c4:7d:4f:57:82:5d tid = 0
[ 3982.009170] CE: hpet increasing min_delta_ns to 33750 nsec
[ 4003.382449] wlan1: deauthenticated from c4:7d:4f:57:82:5d (Reason: 1)
[ 4006.224951] wlan1: direct probe to AP c4:7d:4f:57:8f:12 (try 1)
[ 4006.424282] wlan1: direct probe to AP c4:7d:4f:57:8f:12 (try 2)
[ 4006.624146] wlan1: direct probe to AP c4:7d:4f:57:8f:12 (try 3)
[ 4006.824079] wlan1: direct probe to AP c4:7d:4f:57:8f:12 timed out
[ 4019.257842] wlan1: direct probe to AP c4:7d:4f:52:73:d2 (try 1)
[ 4019.457074] wlan1: direct probe to AP c4:7d:4f:52:73:d2 (try 2)
[ 4019.657318] wlan1: direct probe to AP c4:7d:4f:52:73:d2 (try 3)
[ 4019.856116] wlan1: direct probe to AP c4:7d:4f:52:73:d2 timed out
[ 4022.726889] wlan1: direct probe to AP c4:7d:4f:57:82:5d (try 1)
[ 4022.925194] wlan1: direct probe to AP c4:7d:4f:57:82:5d (try 2)
[ 4022.926600] wlan1: direct probe responded
[ 4022.926610] wlan1: authenticate with AP c4:7d:4f:57:82:5d (try 1)
[ 4022.927549] wlan1: authenticated
[ 4022.927619] wlan1: associate with AP c4:7d:4f:57:82:5d (try 1)
[ 4022.929779] wlan1: RX AssocResp from c4:7d:4f:57:82:5d (capab=0x111 status=0 aid=6)
[ 4022.929788] wlan1: associated
[ 4041.684051] iwlagn 0000:03:00.0: iwl_tx_agg_start on ra = c4:7d:4f:57:82:5d tid = 0
[ 4163.380173] wlan1: deauthenticating from c4:7d:4f:57:82:5d by local choice (reason=3)
[ 4166.210074] wlan1: direct probe to AP c4:7d:4f:57:82:5e (try 1)
[ 4166.211205] wlan1: direct probe responded
[ 4166.211213] wlan1: authenticate with AP c4:7d:4f:57:82:5e (try 1)
[ 4166.213091] wlan1: authenticated
[ 4166.213124] wlan1: associate with AP c4:7d:4f:57:82:5e (try 1)
[ 4166.413260] wlan1: associate with AP c4:7d:4f:57:82:5e (try 2)
[ 4166.415329] wlan1: RX AssocResp from c4:7d:4f:57:82:5e (capab=0x101 status=12 aid=0)
[ 4166.415338] wlan1: AP denied association (code=12)

    Betreffend dazu fand ich diesen bug report im ubuntu lunchpad:
    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/548992
    Nach den Erfahrungen dort, werde ich auch versuchen den gnome-nm gegen wicd zu tauschen. Doch, wird wicd denn überhaupt noch weiter entwickelt?

    Manchmal geht das ganz auch soweit, dass meine Karte gar nicht mehr verbinden möchte. Sie wird dann nur sehr heiß. Ich habe das Gefühl, dass das ganze bei Draft-N Netzwerken öfter passiert. Kann es leider nur nicht nachweisen. Gibt es dazu eine Möglichkeit den WLAN g- Standard zu erzwingen?

    Unser Uni WLAN besteht aus 2 Netzwerken, einmal eduroam, was einige kennen werden, dieses ist per WPA2 Enterprise gesichert. Und einem sogn. VPN/WEB, welches zunächst offen und dann über IPSec o.ä. gesichert ist.
    Die Abbrüche treten bei beiden auf!
 
tgraupne schrieb:
Wobei ich eben sagen muss, dass es bei mir mit wicd nicht besser wurde.
Das war übrigens auch der erste Vorschlag, den mir unser Uni- Support Heute gab :)
Zum Vergrößern anklicken....
Wie gesagt, damit hat es nichts zu tun. Wirklich. Nichts. Öfter baue ich die Verbindung "manuell" über das Aufrufen von wpa_supplicant und dhclient auf, komplett ohne grafische Tools.. -> kein Unterschied.

Evilandi666 schrieb:
Ist das ein reiner Redhat Fix oder auch ein Upstream Fix?
Zum Vergrößern anklicken....

Red Hat. Wird evtl. upstream.. evtl auch nicht. Bisher: keine Besserung. Am schnellsten (eben wieder getestet!) ist noch immer der iwlagn aus dem .32 kernel in SL6..
 
Unser Rechenzentrum äußerte den Verdacht, dass es daran liegen könnte, dass wegen der hohen AP- Dichte der nmanager oft versucht den AP zu wechseln, dieser dann aber "voll" ist.
Aufgrund des ebenfalls hohen Nutzeranzahl. Ich werde mal direkt an sie weiter geben, dass bei manueller Verbindung die gleichen Fehler auftreten.
 
Such dir mal einen spezifischen AP raus und gib seine MAC Adresse im NM bei bssid ein. Wenn das hilft stimmt deren Aussage..

Bei mir springt aber die Verbindung _nicht_ zwischen den APs hin und her.
 
Richtig coole Sache :)
Unser Rechenzentrum hat bei den Problem aufgegeben.

Zum Schluss habe ich mit einer Person gesprochen, die genau das selbe Problem mit ihrem X200 hatte.
Nach viel rumprobieren war die Lösung dann "ubuntu" :) Für mich eine unzufriedenstellende Lösung.

Auf die Frage hin, welche software dort genutzt wird bekam ich die Antwort:

network-manager:
Installed: 0.8.4~git.20110319t175609.d14809b-0ubuntu3

Ich bin also gerade dabei nm 0.8.889 zu compilieren.
Zusätzlich hätte ich noch den Treiber iwlwifi 0.32 aus dem debian unstable Zweig zum testen.

Sollte das alles auch fehlschlagen, bin ich wirklich ratlos =(


buddabrod, was sind deine Erfahrungen mit Linux 3??


edit: Ok, nachdem ich diverse Probleme hatte den nm und das nm-applet in Version 0.8.999 zu compilieren habe ich mich für 0.8.4
aus den backports entschieden. Da kann man ja wirklich alles finden :) +1
 
Zuletzt bearbeitet:
Ich habe hier NetworkManager 0.8.999. Mit kernel 3.0rc6 gabs keine wirkliche Besserung im Vergleich mit dem aktuellen .38 aus Fedora 15. Der ist jetzt gleichauf mit SL6.

Nur der 3.0 bringt einen höheren Stromverbrauch.. :(

Morgen habe ich vielleicht nochmal Zeit das zu testen.
 
Also, ich bin wirklich am verzweifeln.
Warum bekommt Ubuntu das hin????
 
tgraupne schrieb:
Also, ich bin wirklich am verzweifeln.
Warum bekommt Ubuntu das hin????
Zum Vergrößern anklicken....

Und warum gehts bei SL6?

Tja. Gute Fragen, bei denen man sich der Problematik intensiver widmen müsste.

Also kurzum: Bei SL6 und mit kernel 3 ging es. Bei beiden habe ich aber ca. 2W mehr Verbrauch.. Ob da ein Zusammenhang besteht ist zweifelhaft, aber im Mobilbetrieb sind mir die 2W durchaus wichtig.
 
Als ich gerade noch einmal etwas gegoogled habe, bin ich wieder auf relativ viele Aussagen gestoßen, die behaupten, dass iwlagn mit 5GHz AP's nicht so recht klar kommt. Ich hatte ja vor einiger Zeit schon einmal den Vorschlag zum Test in dieser Richtung gebracht, nur keine Möglichkeit gefunden es selbst zu testen.

Ich würde daher hier noch einmal fragen, ob es eine Möglichkeit gibt, zu verbieten, sich mit 5GHz AP's zu verbinden?

Des Weiteren habe ich im RedHat Bugzilla den betreffenden thread gefunden, @ buddabrod: kanntest du den schon?
https://bugzilla.redhat.com/show_bug.cgi?id=716602
 
tgraupne schrieb:
Als ich gerade noch einmal etwas gegoogled habe, bin ich wieder auf relativ viele Aussagen gestoßen, die behaupten, dass iwlagn mit 5GHz AP's nicht so recht klar kommt. Ich hatte ja vor einiger Zeit schon einmal den Vorschlag zum Test in dieser Richtung gebracht, nur keine Möglichkeit gefunden es selbst zu testen.
Zum Vergrößern anklicken....
Habe doch schon geschrieben: gib dem NM einfach die besagte MAC Adresse des 2,4GHz Routers vor..

Des Weiteren habe ich im RedHat Bugzilla den betreffenden thread gefunden, @ buddabrod: kanntest du den schon?
https://bugzilla.redhat.com/show_bug.cgi?id=716602
Zum Vergrößern anklicken....
Der wurde doch schon gepostet ;)

Übrigens: Auch unter SL6 habe ich die häufigen Verbindungsabbrüche. Unter Windows XP genauso, aber das verbindet direkt neu. Der NM macht das nicht..
Zuhause habe ich eben mal einen großen Datentransfer mit Windows versucht: Trotz angeblicher 300Mbit waren es nur ca. 2Mbyte/s, das ist nichtmal annähernd so schnell wie es sein sollte. Da habe ich unter Linux mehr.. ;)
 
Ich hol den Thread noch einmal hoch :DGibts bei euch etwas neues, an dieser Front?Ich habe imo mal zum testen Fedora 15 auf meinem X61s, dort scheint es meine besagten Probleme nicht zu geben....2.6.40 Kernel, NM Version weiß ich gerade nicht.In der Bibo ist mittlerweile viel weniger los und trotzdem ich habe die alten Probleme.eduraom --> deauthenticating by reason 3 ????Ich werde jetzt mal versuchen, ob ich über die backports o.g. Kernel bei meinem Debian nutzen kann....Sind die Probleme mit dem hohen Stromverbrauch beim Kernel 3.0 mittlerweile behoben?
 
2.6.40 = 3.0 ;) Hat Fedora nur umgenannt, damit alle Tools/Scripts weiterhin funktionieren :)

unter SL6 ist bei mir Wlan total stabil. Sofern ich keinen der Randkanäle nutze, habe ich auch locker 150Mbit Brutto, Verbindung stabil ohne Fehler.
Ich werde Kernel 3.1 mal testen, wenn er raus ist.

Stromverbrauch: einfach testen.
 
Also ich konnte Heute mit Fedora 14 und 2.6.40 nicht arbeiten =(Ebenfalls der Fehler, der mich schon immer quält;wlan1 : deauthenticating ... bla bla bla ... (reason 3) Habe Heute aber rausgefunden, dass mein smartphone auch seine WLAN Verbindung über USB weiterleiten kann, dass war meine Rettung ;)
 
tgraupne schrieb:
Also ich konnte Heute mit Fedora 14 und 2.6.40 nicht arbeiten =(Ebenfalls der Fehler, der mich schon immer quält;wlan1 : deauthenticating ... bla bla bla ... (reason 3) Habe Heute aber rausgefunden, dass mein smartphone auch seine WLAN Verbindung über USB weiterleiten kann, dass war meine Rettung ;)
Zum Vergrößern anklicken....

Es ist wirklich traurig. Die hochangepriesenen Intel Linux Treiber sind bei Wlan Chips und integrierter Grafik wirklich höchstens bescheiden. Als nächstes kaufe ich Atheros..
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben