L-321AGN: Disassociated due to station request (Unspecified)

marsbewohner · Beitrag von **marsbewohner** » 09 Feb 2011, 17:52

Hallo zusammen (und im besonderen Alf29),

nachdem das Problem mit den Resets durch das Atheros Chipproblem nun behoben ist, kämpfe ich weiter damit
das Stationen sich immer wieder Ab- und Anmelden, ohne das wir erkennen können warum.

Hier mal ein Log Auszug aus einer Testinstallation:

Code: Alles auswählen

02/08/2011 15:07:08;4;5;[WLAN-1] Authenticated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [];
02/08/2011 15:07:08;4;5;[WLAN-1] Associated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1];
02/08/2011 15:07:08;4;5;[WLAN-1] Key handshake with peer 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) successfully completed;
02/08/2011 15:07:08;4;5;[WLAN-1] Connected WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1];
02/08/2011 15:07:08;4;5;[WLAN-1] Determined IPv6 address for station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1]: fe80:0000:0000:0000:;
02/08/2011 15:07:09;4;5;[WLAN-1] Determined IPv4 address for station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1]: 192.168.0.15;
02/08/2011 15:07:33;4;5;[WLAN-1] Determined IPv4 address for station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1]: 192.168.100.138;
02/08/2011 15:31:57;4;5;[WLAN-1] Disassociated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1] due to station request (Unspec;
02/08/2011 15:31:57;4;5;[WLAN-1] Deauthenticated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1] (Unspecified Reason);
02/08/2011 15:45:04;4;5;[WLAN-1] Authenticated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [];
02/08/2011 15:45:04;4;5;[WLAN-1] Associated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1];
02/08/2011 15:45:04;4;5;[WLAN-1] Key handshake with peer 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) successfully completed;
02/08/2011 15:45:04;4;5;[WLAN-1] Connected WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1];
02/08/2011 15:45:04;4;5;[WLAN-1] Determined IPv4 address for station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1]: 192.168.100.138;
02/08/2011 18:50:39;4;5;[WLAN-1] Disassociated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1] due to station request (Unspec;
02/08/2011 18:50:39;4;5;[WLAN-1] Deauthenticated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1] (Unspecified Reason);
02/09/2011 10:25:59;4;5;[WLAN-1] Authenticated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [];
02/09/2011 10:25:59;4;5;[WLAN-1] Associated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1];
02/09/2011 10:25:59;4;5;[WLAN-1] Key handshake with peer 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) successfully completed;
02/09/2011 10:25:59;4;5;[WLAN-1] Connected WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1];
02/09/2011 10:25:59;4;5;[WLAN-1] Determined IPv6 address for station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1]: fe80:0000:0000:0000:;
02/09/2011 10:25:59;4;5;[WLAN-1] Determined IPv4 address for station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1]: 192.168.100.138;
02/09/2011 12:50:45;4;5;[WLAN-1] Disassociated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1] due to station request (Unspec;
02/09/2011 12:50:45;4;5;[WLAN-1] Deauthenticated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1] (Unspecified Reason);
02/09/2011 13:14:05;4;5;[WLAN-1] Authenticated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [];
02/09/2011 13:14:06;4;5;[WLAN-1] Associated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1];
02/09/2011 13:14:06;4;5;[WLAN-1] Key handshake with peer 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) successfully completed;
02/09/2011 13:14:06;4;5;[WLAN-1] Connected WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1];
02/09/2011 13:14:06;4;5;[WLAN-1] Determined IPv4 address for station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1]: 192.168.100.138;
02/09/2011 14:11:46;4;5;[WLAN-1] Disassociated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1] due to station request (Unspec;
02/09/2011 14:11:46;4;5;[WLAN-1] Deauthenticated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1] (Unspecified Reason);
02/09/2011 14:12:50;4;5;[WLAN-1] Authenticated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [];
02/09/2011 14:12:50;4;5;[WLAN-1] Associated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [LANCOM1];
02/09/2011 14:12:50;4;5;[WLAN-1] Key handshake with peer 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) successfully completed;
02/09/2011 14:12:50;4;5;[WLAN-1] Connected WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [LANCOM1];
02/09/2011 14:12:50;4;5;[WLAN-1] Determined IPv4 address for station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [LANCOM1]: 192.168.100.138;
02/09/2011 17:16:18;4;5;[WLAN-1] Disassociated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [LANCOM1] due to station request (Unspecified ;
02/09/2011 17:16:18;4;5;[WLAN-1] Deauthenticated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [LANCOM1] (Unspecified Reason);
02/09/2011 17:17:21;4;5;[WLAN-1] Authenticated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [];
02/09/2011 17:17:21;4;5;[WLAN-1] Associated WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1];
02/09/2011 17:17:21;4;5;[WLAN-1] Key handshake with peer 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) successfully completed;
02/09/2011 17:17:21;4;5;[WLAN-1] Connected WLAN station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1];
02/09/2011 17:17:22;4;5;[WLAN-1] Determined IPv4 address for station 00:21:5c:7e:0e:45 (Intel-Malaysia 7e:0e:45) [TESTCLIENT1]: 192.168.100.138;

Der Testaufbau:

AP: L-321AGN mit 8.5 RC Firmware
Client: Client ist ein Lenovo Gerät mit Intel Chip, neuster Treiber, Festeinbau in Dockingstation, Empfang etwas um die 50%

Wie man sehen kann wird der Client immer mal wieder An- und Abgemeldet, ohne das wir jedoch erkennen können warum,
da das Gerät nicht bewegt wird und auch sonst auf Dauerstrom steht.

Weiter ist interessant für mich, das obwohl die MAC immer die selbe ist, der Name dahinter nicht immer richtig übernommen wird.
TESTCLIENT1 ist der Clientname, LANCOM1 ist der Name des APs.

Was kann der Grund für so ein Verhalten sein?

Danke & Gruß,

alf29 · Beitrag von **alf29** » 09 Feb 2011, 23:00

Moin,

also 'due to station request' heißt, daß der Client *sich selber* abgemeldet hat, das LANCOM
hat ihn nicht rausgeworfen. Warum der Client das macht, mußt Du Intel fragen...ich kenne das
z.T. von Intel-Clients, daß sie wie wild anfangen, hin- und herzuspringen, wenn mehrere APs
mit ungefähr gleicher Feldstärke in der Nähe sind. Zumindest bei den Intel-Client-Utilities hatte
man früher mal einen Schieberegler, mit dem man die 'Roamingfreudigkeit' einstellen konnte...

Der Stationsname wird aus einer Cisco/Aironet-Erweiterung bei der Assoziation gewonnen,
mit der sich Client und AP gegenseitig einen Namen mitteilen können. Bisweilen geben
Intel-Clients bei der Anmeldung jedoch nicht ihren eigenen Namen an, sondern den des
APs. Habe ich schon öfters bei Intel-Clients gesehen, ist wohl eine Macke in den Intel-Treibern.
Daß der Name in den 'Authenticated...'-Meldungen nicht drin ist, liegt daran, daß dieses
Ereignis vor der Assoziation liegt, zu diesem Zeitpunkt hat der AP den Namen des Clients
einfach noch nicht. Inden 'Key Handshake..'-Meldungen steht der Name nicht drin, weil das
eine allgemeine Meldung ist, die nicht nur für Clients kommt, sondern auch z.B. für P2P-Partner.

Gruß Alfred

marsbewohner · Beitrag von **marsbewohner** » 10 Feb 2011, 07:34

Hallo Alfred,

danke für die Erklärungen, wobei mir die das Leben auch nicht leichter machen

Bisher kommen in dem Zusammenhang Apple APs zum Einsatz, und mit denen tauchen diese Probleme nicht auf,
was den Kunden natürlich zweifeln und fragen lässt, warum er jetzt die Lancoms mit den Problemen nutzen soll

Mal sehen, vielleicht kann ich ja über den Treiber noch etwas Feintuning machen.

Das erklärt zumindest aber schon mal, warum die Clients nach dem Aufbau von mehr als einem AP und teilweise sich
überdeckenden Funkbereichen ohne eigentlichen Bedarf wie wild das wechseln angefangen haben,
und die APs nicht mehr hinter her kamen welcher Client jetzt wo eingebucht ist....

Gruß,

alf29 · Beitrag von **alf29** » 10 Feb 2011, 11:20

Moin,

Du könntest mal probieren, in den Netzwerkeinstellungen
die Aironet-Erweiterungen ganz auszuschalten. Dann gibt's
zwar gar keine Namen mehr, aber dafür auch keine falschen...
des weiteren kann ich nicht zu 100% sagen, ob diese
Erweiterung im Rahmen von CCX irgendwelche Auswirkungen
auf Roaming hat. Da Cisco die dabei verwendeten
Infoelement nicht dokumentiert, sind andere AP-Hersteller
auf Reverse Engineering angewiesen...

Gruß Alfred

marsbewohner · Beitrag von **marsbewohner** » 11 Feb 2011, 19:53

Hallo Alfred,

anbei nochmal einen Ping Log von einem Client aus über das WLAN, wie du sehen kannst sind da doch einige Schwankungen drin:

Code: Alles auswählen

PING 192.168.100.1 (192.168.100.1): 56 data bytes
64 bytes from 192.168.100.1: icmp_seq=0 ttl=64 time=470.260 ms
64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=2.973 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=729.548 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=10.013 ms
Request timeout for icmp_seq 4
64 bytes from 192.168.100.1: icmp_seq=4 ttl=64 time=1118.332 ms
64 bytes from 192.168.100.1: icmp_seq=5 ttl=64 time=118.293 ms
64 bytes from 192.168.100.1: icmp_seq=6 ttl=64 time=3.025 ms
64 bytes from 192.168.100.1: icmp_seq=7 ttl=64 time=2.856 ms
64 bytes from 192.168.100.1: icmp_seq=8 ttl=64 time=3.070 ms
64 bytes from 192.168.100.1: icmp_seq=9 ttl=64 time=592.336 ms
64 bytes from 192.168.100.1: icmp_seq=10 ttl=64 time=7.359 ms
64 bytes from 192.168.100.1: icmp_seq=11 ttl=64 time=3.203 ms
64 bytes from 192.168.100.1: icmp_seq=12 ttl=64 time=804.194 ms
64 bytes from 192.168.100.1: icmp_seq=13 ttl=64 time=3.141 ms
64 bytes from 192.168.100.1: icmp_seq=14 ttl=64 time=3.047 ms
64 bytes from 192.168.100.1: icmp_seq=15 ttl=64 time=1307.570 ms
64 bytes from 192.168.100.1: icmp_seq=16 ttl=64 time=333.242 ms
64 bytes from 192.168.100.1: icmp_seq=17 ttl=64 time=3.039 ms
64 bytes from 192.168.100.1: icmp_seq=18 ttl=64 time=956.750 ms
64 bytes from 192.168.100.1: icmp_seq=19 ttl=64 time=3.085 ms
64 bytes from 192.168.100.1: icmp_seq=20 ttl=64 time=593.550 ms
64 bytes from 192.168.100.1: icmp_seq=21 ttl=64 time=387.433 ms
64 bytes from 192.168.100.1: icmp_seq=22 ttl=64 time=3.377 ms
64 bytes from 192.168.100.1: icmp_seq=23 ttl=64 time=1042.338 ms
64 bytes from 192.168.100.1: icmp_seq=24 ttl=64 time=46.472 ms
64 bytes from 192.168.100.1: icmp_seq=25 ttl=64 time=4.127 ms
Request timeout for icmp_seq 27
64 bytes from 192.168.100.1: icmp_seq=26 ttl=64 time=2551.757 ms
64 bytes from 192.168.100.1: icmp_seq=27 ttl=64 time=1553.421 ms
64 bytes from 192.168.100.1: icmp_seq=28 ttl=64 time=586.877 ms
64 bytes from 192.168.100.1: icmp_seq=29 ttl=64 time=3.021 ms
64 bytes from 192.168.100.1: icmp_seq=30 ttl=64 time=3.250 ms
64 bytes from 192.168.100.1: icmp_seq=31 ttl=64 time=203.974 ms
64 bytes from 192.168.100.1: icmp_seq=32 ttl=64 time=3.099 ms
64 bytes from 192.168.100.1: icmp_seq=33 ttl=64 time=544.808 ms
64 bytes from 192.168.100.1: icmp_seq=34 ttl=64 time=822.468 ms
64 bytes from 192.168.100.1: icmp_seq=35 ttl=64 time=3.179 ms
64 bytes from 192.168.100.1: icmp_seq=36 ttl=64 time=3.244 ms
64 bytes from 192.168.100.1: icmp_seq=37 ttl=64 time=1059.040 ms
64 bytes from 192.168.100.1: icmp_seq=38 ttl=64 time=74.717 ms
64 bytes from 192.168.100.1: icmp_seq=39 ttl=64 time=3.182 ms
64 bytes from 192.168.100.1: icmp_seq=40 ttl=64 time=3.052 ms
64 bytes from 192.168.100.1: icmp_seq=41 ttl=64 time=785.199 ms
64 bytes from 192.168.100.1: icmp_seq=42 ttl=64 time=433.561 ms
64 bytes from 192.168.100.1: icmp_seq=43 ttl=64 time=3.087 ms
64 bytes from 192.168.100.1: icmp_seq=44 ttl=64 time=1436.857 ms
64 bytes from 192.168.100.1: icmp_seq=45 ttl=64 time=462.053 ms
Request timeout for icmp_seq 48
Request timeout for icmp_seq 49
64 bytes from 192.168.100.1: icmp_seq=46 ttl=64 time=4293.911 ms
64 bytes from 192.168.100.1: icmp_seq=47 ttl=64 time=3320.333 ms
64 bytes from 192.168.100.1: icmp_seq=48 ttl=64 time=2320.358 ms
64 bytes from 192.168.100.1: icmp_seq=49 ttl=64 time=1320.706 ms
64 bytes from 192.168.100.1: icmp_seq=50 ttl=64 time=320.622 ms
64 bytes from 192.168.100.1: icmp_seq=51 ttl=64 time=2.755 ms
64 bytes from 192.168.100.1: icmp_seq=52 ttl=64 time=1136.367 ms
64 bytes from 192.168.100.1: icmp_seq=53 ttl=64 time=160.204 ms
64 bytes from 192.168.100.1: icmp_seq=54 ttl=64 time=3.053 ms
64 bytes from 192.168.100.1: icmp_seq=55 ttl=64 time=1256.881 ms
64 bytes from 192.168.100.1: icmp_seq=56 ttl=64 time=281.514 ms
64 bytes from 192.168.100.1: icmp_seq=57 ttl=64 time=3.071 ms
64 bytes from 192.168.100.1: icmp_seq=58 ttl=64 time=907.328 ms
64 bytes from 192.168.100.1: icmp_seq=59 ttl=64 time=2.947 ms
64 bytes from 192.168.100.1: icmp_seq=60 ttl=64 time=3.309 ms
64 bytes from 192.168.100.1: icmp_seq=61 ttl=64 time=1333.794 ms
64 bytes from 192.168.100.1: icmp_seq=62 ttl=64 time=333.762 ms
64 bytes from 192.168.100.1: icmp_seq=63 ttl=64 time=2.905 ms
^C
--- 192.168.100.1 ping statistics ---
64 packets transmitted, 64 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.755/564.005/4293.911/827.849 ms

Der Aufbau dahinter ist selbiger AP wie oben, der Client in ca. 5m Entfernung dazu und keine Last.

Wie kann es da zu solchen Schwankungen kommen?
Device ist in dem Fall folgendes:

Card Type: AirPort Extreme (0x14E4, 0x8D)
Firmware Version: Broadcom BCM43xx 1.0 (5.10.131.36.1)
Locale: ETSI
Country Code: EU

Gruß,

alf29 · Beitrag von **alf29** » 12 Feb 2011, 12:58

Moin,

Powersaving auf dem Client?

Gruß Alfred

marsbewohner · Beitrag von **marsbewohner** » 12 Feb 2011, 13:25

Moin,

Danke - wäre eine Option (muss ich prüfen), allerdings wenn ich auf einen AP einer anderen Marke umschalte habe ich diese Schwankungen nicht....?

Gruß,

alf29 · Beitrag von **alf29** » 12 Feb 2011, 13:35

Moin,

tja, da ich so einen Client nicht zur Verfügung habe, kann ich das nicht nachstellen. im Falle
des LANCOM kann man noch Traces machen, aber bei einem Fremd-AP wirst Du nicht umhinkommen,
Dich mit einem Sniffer danebenzustellen, um die Unterschiede herauszufinden...

Gruß Alfred

marsbewohner · Beitrag von **marsbewohner** » 12 Feb 2011, 16:15

Hallo,

das mit den Traces ist eine gute Idee, die lasse ich passend zum Syslog auch mal eine Woche mitlaufen zum durchschauen

Gruß,

marsbewohner · Beitrag von **marsbewohner** » 18 Feb 2011, 11:22

Hallo Alfred,

ich habe jetzt heute mal sowohl Traces als auch Syslog mitlaufen lassen,
und dabei eine hohe Anzahl von Power-save Themen als auch Logs von den Apple Clients generieren können.

Da der Text hier das Forum sprengen würde, kann ich dir das irgendwie per PM als TXT zukommen lassen?

Danke & Gruß,

Henri · Beitrag von **Henri** » 23 Feb 2011, 10:01

Du bist nicht allein, habe die gleichen Problem mit einigen Apple MacBook Pros....

Henri

alf29 · Beitrag von **alf29** » 23 Feb 2011, 11:50

Moin,

Tja Leute, mein letzter Apple war ein Apple ][-Clone anno
1985, deshalb kann ich selber in der Hinsicht nichts nachstellen
und bin auf die QS angewiesen (wenn die so einen hat...).
Bisher habe ich nix davon gehört...

Gruß Alfred

marsbewohner · Beitrag von **marsbewohner** » 23 Feb 2011, 20:07

Henri hat geschrieben:Du bist nicht allein, habe die gleichen Problem mit einigen Apple MacBook Pros....

Hi Henri,

könntest du dazu eventuell mal ein paar Logs/Traces zur Verfügung stellen?
Wäre mal interessant im Vergleich ob wir eventuell technisch die gleichen Themen haben...

Ansonsten bin ich für eine Petition im Forum "Ein Mac für Alfred!"

Grüße,

Henri · Beitrag von **Henri** » 24 Feb 2011, 09:39

Hallo,

ich habe schon die gewünschten Traces für die Support ID 1101.2815.5851.ACAL gemailt, der Fall hat übrigens den gleichen Titel. Bei mir sieht es montan wie folgt aus:
Ich habe einen L-305, L-315 und L-322 plus 2*1823 an einen WLC 4006 angeschlossen. Bisher funktioniert der L-315 am Besten, bei dem L-322 (mit allen FW Version inkl. 8.50 RC1/RC2) gibt es allen 1-3 Minuten ca. 5 Sekunden "Denkpausen". Sehe ich daran, dass der Remote Desktop (MAC/RDC Windows) sich ein paar Sekunden nicht refreshed und die Maus bleibt auch hängen). Ich habe das Teil daher ausgeschaltet, da ich so nicht meiner vom Kunden bezahlten Tätigkeit nachgehen kann. Bei dem L-315 kommt die Message häufig, wenn ich vielen Daten (7-8 MByte/Sekunde) übertrage, dann sehe ich auf dem Mac eine Discconnect/Reconnect (DHCP Adresse wird neu vergeben).

In der Hoffnung auf Besserung und ein schönes Macbook Pro Alfred (es soll morgen Neue Modelle geben)..

Henri

TimTaler · Beitrag von **TimTaler** » 22 Jul 2011, 23:53

Hallo zusammen,

ich habe ganz ähnliche Probleme mit zwei MacBooks Pro würde mich deshalb gerne in die Diskusion einklinken. Im Einsatz sind zwei (zurzeit nur einer) L-321agn hinter einem 1721+. Wir hatten mit zwei baugleichen MacBooks Pro teilweise sehr häufig Verbindungsabbrüche und eine schlechtere Performance als mit den bisher eingesetzten Apple AirPort Basisstationen.

Die Verbindungsabbrüche konnten gefühlt verringert werden, durch das Ausschalten des Background Scan am AP.

Nach dem Update auf LCOS 8.5RU1 braucht das MacBook viele Minuten um sich erfolgreich ins WLAN einzubuchen. Ich werde das am kommenden Montag hoffentlich reproduzieren können und dann mal tracen.

Andere Geräte (Notebooks, iPad, iPhone) verhalten sich im WLAN ganz normal und können prima arbeiten.

Es ist ähnlich wie bei dir marsbewohner, dass der Kunde gerade von AirPort auf Lancm umgestiegen ist und das Ergebnis schlechter ist als vorher ...

Der Fall liegt auch schon beim Support, dem ich noch ein passenden Trace schuldig bin.

Also, ich werde berichten und freue mich auch regen Austausch.

Im Übrigen hatte ich auch mal ein cisco Small Business AP 4410N in diesem Netz. Das verhalten war sehr ähnlich.

schöne Grüße erstmal ...