Hallo Leute,
ich wende mich hier an euch, da ihr meine letzte Hoffnung seit :-) Seit Jahren und seit vielen Linux- Versionen habe ich massive Probleme mit dem eduroam WLAN in der SLUB! Mein thinkpad kann einfach nie eine stabile Verbindung aufbauen, bricht immer wieder ab. Komischer Weise habe ich mit dem eduroam im BeyerBau keine Probleme.
Da ich nicht genau weiß welche Informationen hier wichtig sind möchte ich euch bitten, mit einfach mal durchzugeben, welche Informationen zur Klärung des Problems wichtig sind.
Gruß Tom
Da ich nicht genau weiß welche Informationen hier wichtig sind möchte ich euch bitten, mit einfach mal durchzugeben, welche Informationen zur Klärung des Problems wichtig sind.
Das eduroam in der Slub ist imho voll. Ich habe mal gehört, dass andere Betriebssysteme sehr aggressiv den Kanal spammen damit sie eine Verbindung bekommen.
Vielleicht hilft das um gezielter Informationen zu Sammeln um das Problem zu klären. Weis nicht exakt wie man da vorgehen sollte. Weis wer anderes bestimmt besser :)
Gilbert
Das klingt ja interessant :-) Würde zumindest voll zur Philosophie von den "anderen" Betriebssystemen passen ^^
Ich habe jedoch auch schon beobachten können, dass ich diese Probleme hab wenn die SLUB nicht total überfüllt ist.
Mit meinem Android- Smartphone habe ich übrigens auch keine Probleme.
Ich kann ja schon mal sagen, dass ich ein X61s mit Intel 5100 Karte besitze. Als OS läuft Kubuntu 12.04.
LG Tom
Am 2. Juli 2012 16:03 schrieb Gilbert Röhrbein payload@lavabit.com:
Da ich nicht genau weiß welche Informationen hier wichtig sind möchte
ich euch
bitten, mit einfach mal durchzugeben, welche Informationen zur Klärung
des Problems
wichtig sind.
Das eduroam in der Slub ist imho voll. Ich habe mal gehört, dass andere Betriebssysteme sehr aggressiv den Kanal spammen damit sie eine Verbindung bekommen.
Vielleicht hilft das um gezielter Informationen zu Sammeln um das Problem zu klären. Weis nicht exakt wie man da vorgehen sollte. Weis wer anderes bestimmt besser :)
Gilbert
Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Hallo Leute,
ich habe ein wenig nachgeforscht und bin zu dem Entschluss gekommen mal einen aktuelleren Kernel auszuprobieren. Da bekommt man ja auch immer die aktuellen stable Treiber mit.
Ich habe also 3.4.4 und 3.5rc5 ausprobiert. bei letzterem hat er das Treiber Modul iwlwifi gar nicht gefunden :-(
Beim 3.4.4 habe ich nun "fast" das gleiche Fehlerbild, ich hänge dazu mal den #dmesg output an:
[ 70.717569] cfg80211: Regulatory domain changed to country: DE [ 70.717574] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 70.717582] cfg80211: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm) [ 70.717590] cfg80211: (5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm) [ 70.717597] cfg80211: (5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2000 mBm) [ 70.717604] cfg80211: (5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 2698 mBm) [ 80.800095] wlan0: no IPv6 routers present [ 89.520773] cfg80211: Found new beacon on frequency: 5200 MHz (Ch 40) on phy0 [ 89.923190] cfg80211: Found new beacon on frequency: 5240 MHz (Ch 48) on phy0 [ 92.748967] wlan0: authenticate with c4:7d:4f:52:61:30 [ 92.752661] wlan0: direct probe to c4:7d:4f:52:61:30 (try 1/3) [ 92.956052] wlan0: direct probe to c4:7d:4f:52:61:30 (try 2/3) [ 93.160056] wlan0: direct probe to c4:7d:4f:52:61:30 (try 3/3) [ 93.364047] wlan0: authentication with c4:7d:4f:52:61:30 timed out [ 93.364952] iwlwifi 0000:03:00.0: ACTIVATE a non DRIVER active station id 0 addr c4:7d:4f:52:61:30 [ 100.221709] wlan0: authenticate with c4:7d:4f:52:61:30 [ 100.225583] wlan0: send auth to c4:7d:4f:52:61:30 (try 1/3) [ 100.232186] wlan0: authenticated [ 100.232517] wlan0: waiting for beacon from c4:7d:4f:52:61:30 [ 100.328055] wlan0: associate with c4:7d:4f:52:61:30 (try 1/3) [ 100.331106] wlan0: RX AssocResp from c4:7d:4f:52:61:30 (capab=0x431 status=0 aid=1) [ 100.331114] wlan0: associated [ 134.831668] wlan0: authenticate with c4:7d:4f:57:82:f0 [ 134.838245] wlan0: direct probe to c4:7d:4f:57:82:f0 (try 1/3) [ 135.040049] wlan0: direct probe to c4:7d:4f:57:82:f0 (try 2/3) [ 135.244065] wlan0: direct probe to c4:7d:4f:57:82:f0 (try 3/3) [ 135.448058] wlan0: authentication with c4:7d:4f:57:82:f0 timed out [ 135.448955] iwlwifi 0000:03:00.0: ACTIVATE a non DRIVER active station id 0 addr c4:7d:4f:57:82:f0 [ 142.618926] wlan0: authenticate with c4:7d:4f:52:61:3f [ 142.621816] wlan0: send auth to c4:7d:4f:52:61:3f (try 1/3) [ 142.623143] wlan0: authenticated [ 142.624093] wlan0: associate with c4:7d:4f:52:61:3f (try 1/3) [ 142.625989] wlan0: RX AssocResp from c4:7d:4f:52:61:3f (capab=0x11 status=0 aid=1) [ 142.625993] wlan0: associated [ 156.918720] wlan0: deauthenticating from c4:7d:4f:52:61:3f by local choice (reason=3)
Freue mich auf eure Ideen.
Gruß Tom
Hallo Tom,
Am Dienstag, den 03.07.2012, 19:35 +0200 schrieb Tom Graupner:
[ 70.717569] cfg80211: Regulatory domain changed to country: DE [ 70.717574] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 70.717582] cfg80211: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm) [ 70.717590] cfg80211: (5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm) [ 70.717597] cfg80211: (5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2000 mBm) [ 70.717604] cfg80211: (5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 2698 mBm) [ 80.800095] wlan0: no IPv6 routers present [ 89.520773] cfg80211: Found new beacon on frequency: 5200 MHz (Ch 40) on phy0 [ 89.923190] cfg80211: Found new beacon on frequency: 5240 MHz (Ch 48) on phy0
Ich kenne das Netz in der SLUB zwar nicht, aber das hier deutet auf 11a oder 11n hin. Du könntest testweise versuchen den 11n Mode zu deaktivieren.
Dazu eine Datei /etc/modprobe.d/iwlwifi.conf (Name ist egal, .conf ist wichtig) erzeugen mit folgendem Inhalt:
options iwlwifi 11n_disable=1
Carsten
Hallo Carsten,
das Modul iwlwifi wird bereits mit dieser Option geladen. Im Kernel 3.5 soll es dann auch eine Option geben das 5GHz WLAN zu deaktivieren. Das wollte ich eigentlich bereits ausprobieren, doch mit dem 3.5er Kernel konnte ich das Modul gar nicht laden?!
Ich denke die Hauptprobleme müssen in folgende Zeilen sein:
wlan0: deauthenticating from c4:7d:4f:52:61:3f by local choice (reason=3)
oder
iwlwifi 0000:03:00.0: ACTIVATE a non DRIVER active station id 0 addr c4:7d:4f:57:82:f0
oder
cfg80211: Found new beacon on frequency: 5200 MHz (Ch 40) on phy0 cfg80211: Found new beacon on frequency: 5240 MHz (Ch 48) on phy0
Gruß Tom
On 04.07.2012 02:11, Carsten Luedtke wrote:
Ich kenne das Netz in der SLUB zwar nicht, aber das hier deutet auf 11a oder 11n hin. Du könntest testweise versuchen den 11n Mode zu deaktivieren.
Hallo Tom, Carsten,
ja, in der SLUB ist 11n verbaut. In der letzten Statistik, die ich gesehen habe, warn die 5GHz Kanäle relativ leer, wärend die 2.5Ghz Kanäle stark überbucht waren. Ich weiß nicht, wie sich die Situation inzwischen verändert hat. Soweit ich das Problem verstanden habe, wird das 5GHz Signal stärker gedämpft, sinkt daher mit der Entfernung vom AP schnell unter die Signalstärke des 2.5GHz Signal, was die meisten Treiber dazu veranlasst, auf den 2.5GHz Kanal zu wechseln. Eventuell wäre es daher eine Idee, die Nutzung der 5GHz Kanäle zu forcieren (bietet der Treiber sowas?).
Ein weiteres bekanntes Problem im Zusammenhang von Eduroam und Thinkpads, verstreut sich auf den gesamten Campus (betrifft nicht nur die SLUB) und schlägt bei gewissen Kombinationen von Intel-WLankarten und Accesspoints zu, tritt also nicht überall auf. Das Symptom ist ein Reconnect aller paar Minuten - bei Accesspoints die sicher nicht überbucht sind. Bisher ist mir keine andere Lösung bekannt, als eines der beiden Geräte zu tauschen oder wo möglich auf LAN zurückzugreifen.
- Joachim
Ja, also 11n habe ich wie gesagt bereits deaktiviert. Das meine Karte sich oft zunächst mit einem 5GHz AP verbindet und dann hin und her springt stimmt. Nur leider habe ich im Treiber des 3.4 Kernels keine Option gefunden 5GHz zu forcieren. Der Befehl modinfo zeigt:
filename: /lib/modules/3.4.0-030400-generic/kernel/drivers/net/wireless/iwlwifi/iwlwifi.ko alias: iwlagn license: GPL author: Copyright(c) 2003-2012 Intel Corporation < ilw@linux.intel.com> version: in-tree: description: Intel(R) Wireless WiFi Link AGN driver for Linux firmware: iwlwifi-5150-2.ucode firmware: iwlwifi-5000-5.ucode firmware: iwlwifi-6000g2b-6.ucode firmware: iwlwifi-6000g2a-5.ucode firmware: iwlwifi-6050-5.ucode firmware: iwlwifi-6000-4.ucode firmware: iwlwifi-100-5.ucode firmware: iwlwifi-1000-5.ucode firmware: iwlwifi-135-6.ucode firmware: iwlwifi-105-6.ucode firmware: iwlwifi-2030-6.ucode firmware: iwlwifi-2000-6.ucode srcversion: F5D2713DFD58733EF4A9066 alias: pci:v00008086d00000892sv*sd00000462bc*sc*i* depends: mac80211,cfg80211 intree: Y vermagic: 3.4.0-030400-generic SMP mod_unload modversions 686 parm: swcrypto:using crypto in software (default 0 [hardware]) (int) parm: 11n_disable:disable 11n functionality, bitmap: 1: full, 2: agg TX, 4: agg RX (uint) parm: amsdu_size_8K:enable 8K amsdu size (int) parm: fw_restart:restart firmware in case of error (int) parm: ucode_alternative:specify ucode alternative to use from ucode file (int) parm: antenna_coupling:specify antenna coupling in dB (defualt: 0 dB) (int) parm: bt_ch_inhibition:Enable BT channel inhibition (default: enable) (bool) parm: plcp_check:Check plcp health (default: 1 [enabled]) (bool) parm: ack_check:Check ack health (default: 0 [disabled]) (bool) parm: wd_disable:Disable stuck queue watchdog timer 0=system default, 1=disable, 2=enable (default: 0) (int) parm: bt_coex_active:enable wifi/bt co-exist (default: enable) (bool) parm: led_mode:0=system default, 1=On(RF On)/Off(RF Off), 2=blinking, 3=Off (default: 0) (int) parm: power_save:enable WiFi power management (default: disable) (bool) parm: power_level:default power save level (range from 1 - 5, default: 1) (int) parm: auto_agg:enable agg w/o check traffic load (default: enable) (bool) parm: no_sleep_autoadjust:don't automatically adjust sleep level according to maximum network latency (default: true) (bool)
Im iwlwifi Modul des 3.5er Kernels soll es dann wohl eine Option geben um 5GHz zu deaktivieren. Ich wollte es ja bereits ausprobieren, aber die Installation des 3.5er Ubuntu Kernels funktionierte eben nicht so wirklich.
Das mein Problem in definitiv nicht überfüllten Netzen auftritt habe ich auch schon spüren dürfen. Aber dann gibt es wie gesagt auch wieder Gebäude, in denen ich mit eduroam keinerlei Probleme habe.
Wahrscheinlich werde ich doch auf eine andere WLAN Karte umsteigen müssen :-(
LG Tom
Am 5. Juli 2012 10:54 schrieb Joachim Protze joachim.protze@tu-dresden.de:
On 04.07.2012 02:11, Carsten Luedtke wrote:
Ich kenne das Netz in der SLUB zwar nicht, aber das hier deutet auf 11a oder 11n hin. Du könntest testweise versuchen den 11n Mode zu deaktivieren.
Hallo Tom, Carsten,
ja, in der SLUB ist 11n verbaut. In der letzten Statistik, die ich gesehen habe, warn die 5GHz Kanäle relativ leer, wärend die 2.5Ghz Kanäle stark überbucht waren. Ich weiß nicht, wie sich die Situation inzwischen verändert hat. Soweit ich das Problem verstanden habe, wird das 5GHz Signal stärker gedämpft, sinkt daher mit der Entfernung vom AP schnell unter die Signalstärke des 2.5GHz Signal, was die meisten Treiber dazu veranlasst, auf den 2.5GHz Kanal zu wechseln. Eventuell wäre es daher eine Idee, die Nutzung der 5GHz Kanäle zu forcieren (bietet der Treiber sowas?).
Ein weiteres bekanntes Problem im Zusammenhang von Eduroam und Thinkpads, verstreut sich auf den gesamten Campus (betrifft nicht nur die SLUB) und schlägt bei gewissen Kombinationen von Intel-WLankarten und Accesspoints zu, tritt also nicht überall auf. Das Symptom ist ein Reconnect aller paar Minuten - bei Accesspoints die sicher nicht überbucht sind. Bisher ist mir keine andere Lösung bekannt, als eines der beiden Geräte zu tauschen oder wo möglich auf LAN zurückzugreifen.
- Joachim
Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
On 08.07.2012 00:12, Tom Graupner wrote:
Das mein Problem in definitiv nicht überfüllten Netzen auftritt habe ich auch schon spüren dürfen. Aber dann gibt es wie gesagt auch wieder Gebäude, in denen ich mit eduroam keinerlei Probleme habe.
Genau das Phänomen meinte ich. Das Problem betrifft eine ganze Reihe von Leuten und bisher gibt es keine bekannte Lösung. Teilweise ist es reine Glücksache, mit welchem erreichbaren AP man gerade verbunden ist.
- Joachim
lug-dd@mailman.schlittermann.de
-
Carsten Luedtke -
Gilbert Röhrbein -
Joachim Protze -
Tom Graupner