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