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 < [email protected]> 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 <[email protected]>: > 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 - [email protected] > https://ssl.schlittermann.de/mailman/listinfo/lug-dd >
_______________________________________________ Lug-dd maillist - [email protected] https://ssl.schlittermann.de/mailman/listinfo/lug-dd
