Hallo Alfred,
mir hat der Support gesagt, er konnte das Problem nachstellen. Ich kann dir aber anbieten auf einer XP Session eueren Fastclient zu starten da kannst Du Traces etc. machen, allerdings bin ich mit diesem Notebook oft beim Kunden. Ggf. kann ich es mit einen älteren Reserve Notebook versuchen. Mein Problem ist, dass keine Lösung ich Sicht ist, auch nicht mit dem nächsten Macosx Update.
Mit vielen Grüßen
Henri
L-322: WLAN hängt
Moderator: Lancom-Systems Moderatoren
Kernel Panic bei Macs und WLAN kommt mir aus Berlin bekannt vor:
http://www.golem.de/1012/80395.html
Das war ein Mist...
http://www.golem.de/1012/80395.html
Das war ein Mist...
-
marsbewohner
- Beiträge: 532
- Registriert: 27 Mär 2007, 13:17
Hallo zusammen,
wir haben Mac OSX 10.6.7 jetzt bei allen betroffenen Probanden soweit installiert, und die ergebnisse sind durchwachsen.
Die bei denen es vorher schon gut war empfinden es als weiterhin gut, die bei denen es vorher ein Problem war klagen noch immer darüber.
Messwerte folgen später
Gruß,
wir haben Mac OSX 10.6.7 jetzt bei allen betroffenen Probanden soweit installiert, und die ergebnisse sind durchwachsen.
Die bei denen es vorher schon gut war empfinden es als weiterhin gut, die bei denen es vorher ein Problem war klagen noch immer darüber.
Messwerte folgen später
Gruß,
Hallo Alfred,
ich laboriere noch immer mit dem Support herum, der sagt, dass Problem liegt bei Apple. Ich habe jetzt via AppleCare ein Problem eröffnet, da geht es nicht weiter. Ich hatte schon einmal so einen Fall, da hat mein Notebook aller 2 Tage gepanict, Applecare hat angeblich das Lab informiert aber herausgekommen ist nichts. Schuld war dann der CISCO VPN Treiber der ohne erkennbaren Grund und ohne eine VPN Verbindung zu haben Panics verursacht hat. Ich hatte erst nach 6 Monaten zufällig herausgefunden was die Ursache war und habe keine Lust wieder 6 Monate mit diesem Problem zu verbringen. Was kann ich tun damit es hier weiter geht?
Vielen Dank und viele Grüße
Henri
ich laboriere noch immer mit dem Support herum, der sagt, dass Problem liegt bei Apple. Ich habe jetzt via AppleCare ein Problem eröffnet, da geht es nicht weiter. Ich hatte schon einmal so einen Fall, da hat mein Notebook aller 2 Tage gepanict, Applecare hat angeblich das Lab informiert aber herausgekommen ist nichts. Schuld war dann der CISCO VPN Treiber der ohne erkennbaren Grund und ohne eine VPN Verbindung zu haben Panics verursacht hat. Ich hatte erst nach 6 Monaten zufällig herausgefunden was die Ursache war und habe keine Lust wieder 6 Monate mit diesem Problem zu verbringen. Was kann ich tun damit es hier weiter geht?
Vielen Dank und viele Grüße
Henri
Moin,
Du hattest ja schon einiges getan, nur nach den Traces, die Du mir geschickt hast, habe ich
zumindest für die groben Ausreißer (also die über 100 ms) nicht gesehen, daß die Pakete
irgendwo im LANCOM 'versauern' würden. Ich hatte Dir ja den Tip gegeben, mal die Aggregierung
auf dem LANCOM auszuschalten, hatte das etwas gebracht? Im Extremfall kann man auch mal
den n-Modus auf dem LANCOM ganz ausmachen, um einzukreisen, ob das evtl. etwas mit
irgendwelchen 11n-Funktionen zu tun hat.
Gruß Alfred
Du hattest ja schon einiges getan, nur nach den Traces, die Du mir geschickt hast, habe ich
zumindest für die groben Ausreißer (also die über 100 ms) nicht gesehen, daß die Pakete
irgendwo im LANCOM 'versauern' würden. Ich hatte Dir ja den Tip gegeben, mal die Aggregierung
auf dem LANCOM auszuschalten, hatte das etwas gebracht? Im Extremfall kann man auch mal
den n-Modus auf dem LANCOM ganz ausmachen, um einzukreisen, ob das evtl. etwas mit
irgendwelchen 11n-Funktionen zu tun hat.
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Hallo Alfred,
ich hatte die Aggregierung schon ausgeschaltet, euer Support hatte mir ein WLC Profile ohne Bundling und ohne Greenfield Mode geschickt, das ging etwas besser hat aber trotzdem das Problem nicht gelöst.
Leider bringt mir das nichts, ich habe hier alle wichtigen Daten der Notebooks in AES Encyr. Sparsebundels und sichere daher pro Notebook Nachts etwa 40-60 Gigabyte, so dass ich den N Modus unbedingt brauche. Mit Macosx 10.6.7 und RC3 ist es schon etwas besser geworden, sobald ich habe ein paar parallele HTTP Downloads oder so etwas starte habe ich wieder das Problem.
Danke vorab wie immer
Henri
ich hatte die Aggregierung schon ausgeschaltet, euer Support hatte mir ein WLC Profile ohne Bundling und ohne Greenfield Mode geschickt, das ging etwas besser hat aber trotzdem das Problem nicht gelöst.
Leider bringt mir das nichts, ich habe hier alle wichtigen Daten der Notebooks in AES Encyr. Sparsebundels und sichere daher pro Notebook Nachts etwa 40-60 Gigabyte, so dass ich den N Modus unbedingt brauche. Mit Macosx 10.6.7 und RC3 ist es schon etwas besser geworden, sobald ich habe ein paar parallele HTTP Downloads oder so etwas starte habe ich wieder das Problem.
Danke vorab wie immer
Henri
Hallo Alfred,
noch ein Update, nach dem ich RC3 auf den L322 aufgespielt habe funktioniert jetzt kein Ping mehr mit einen MacBook Pro (late 2010 Intel I7). Mit einen MacBook Pro Unibody (erstes Model) funktioniert es noch. Mit einem L315 RC3 funktionieren beide Modelle.
Habe ca. 2 Stunden gebaucht um diesen Zusammenhang herauszufinden ....
Vielen Grüße
Henri
noch ein Update, nach dem ich RC3 auf den L322 aufgespielt habe funktioniert jetzt kein Ping mehr mit einen MacBook Pro (late 2010 Intel I7). Mit einen MacBook Pro Unibody (erstes Model) funktioniert es noch. Mit einem L315 RC3 funktionieren beide Modelle.
Habe ca. 2 Stunden gebaucht um diesen Zusammenhang herauszufinden ....
Vielen Grüße
Henri
Habe jetzt noch ein älteres Modell mit dem 10.7 Developer Preview 2 versucht, funktioniert mit WPA2 Enterprise auch nicht. I.d.R. funktioniert in allen Fällen die Radius Authentifizierung über den WLC, die IP Adressen und z.T. der Default Gateway kommt an und dann geht es nicht weiter. Trace + radius und DHCP sind aber okay.
Viele Grüße
Henri
Viele Grüße
Henri
-
marsbewohner
- Beiträge: 532
- Registriert: 27 Mär 2007, 13:17
Hallo zusammen,
ähnliches kann ich bestätigen mit L-321AGN und RC3:
Gruß,
ähnliches kann ich bestätigen mit L-321AGN und RC3:
Die interne IP ist dabei das GW, nicht der AP.>> EXTERN
[developer@macbook ~]$ ping 141.1.1.1
PING 141.1.1.1 (141.1.1.1): 56 data bytes
64 bytes from 141.1.1.1: icmp_seq=0 ttl=55 time=23.855 ms
64 bytes from 141.1.1.1: icmp_seq=1 ttl=55 time=23.719 ms
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
64 bytes from 141.1.1.1: icmp_seq=2 ttl=55 time=5274.079 ms
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
Request timeout for icmp_seq 13
Request timeout for icmp_seq 14
^C
--- 141.1.1.1 ping statistics ---
16 packets transmitted, 3 packets received, 81.2% packet loss
round-trip min/avg/max/stddev = 23.719/1773.884/5274.079/2475.011 ms
[developer@macbook ~]$
>> INTERN
PING 192.168.100.1 (192.168.100.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
64 bytes from 192.168.100.1: icmp_seq=0 ttl=64 time=13885.060 ms
64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=12885.199 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=11885.411 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=10885.542 ms
64 bytes from 192.168.100.1: icmp_seq=4 ttl=64 time=9885.667 ms
64 bytes from 192.168.100.1: icmp_seq=5 ttl=64 time=8886.953 ms
64 bytes from 192.168.100.1: icmp_seq=6 ttl=64 time=7886.799 ms
64 bytes from 192.168.100.1: icmp_seq=7 ttl=64 time=6888.160 ms
64 bytes from 192.168.100.1: icmp_seq=8 ttl=64 time=5888.204 ms
64 bytes from 192.168.100.1: icmp_seq=9 ttl=64 time=4889.199 ms
64 bytes from 192.168.100.1: icmp_seq=10 ttl=64 time=3889.344 ms
64 bytes from 192.168.100.1: icmp_seq=11 ttl=64 time=2889.438 ms
64 bytes from 192.168.100.1: icmp_seq=12 ttl=64 time=1889.455 ms
64 bytes from 192.168.100.1: icmp_seq=13 ttl=64 time=898.744 ms
64 bytes from 192.168.100.1: icmp_seq=14 ttl=64 time=2.792 ms
64 bytes from 192.168.100.1: icmp_seq=15 ttl=64 time=4.337 ms
^C
--- 192.168.100.1 ping statistics ---
16 packets transmitted, 16 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.792/6465.019/13885.060/4490.402 ms
[developer@macbook ~]$
Gruß,
Moin,
solche Effekte mit Ping-Antworten, die auf einmal auf einen Rutsch kommen, deuten
darauf hin, daß Pakete irgendwo zurückgehalten werden. Mit einem WLAN-Data-
Trace sollte man sehen können, wann und wie das LANCOM die Ping-Anfragen bekommt
und wann es die Antworten rauscchickt. Wenn man da kein derartiges zeitliches Verhalten
sieht, ist es ein Client-Problem.
Gruß Alfred
solche Effekte mit Ping-Antworten, die auf einmal auf einen Rutsch kommen, deuten
darauf hin, daß Pakete irgendwo zurückgehalten werden. Mit einem WLAN-Data-
Trace sollte man sehen können, wann und wie das LANCOM die Ping-Anfragen bekommt
und wann es die Antworten rauscchickt. Wenn man da kein derartiges zeitliches Verhalten
sieht, ist es ein Client-Problem.
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
-
marsbewohner
- Beiträge: 532
- Registriert: 27 Mär 2007, 13:17
Moin Alfred,
wir haben gestern nochmal einen Test gemacht, ich schicke dir nachher noch die Logs + Trace Daten.
Was auffällt ist das große oder kontinuierliche Datenmengen relativ gut gehen, zb Downlods, SSH Logausgaben eines Systems etc, also alles wo konstanter Traffic kommt.
Problematisch sind nicht kontinuierliche Datenströme wie zb surfen, wo immer mal eine URL oder ein Suchbefehl abgesetzt wird und dann erstmal wieder keine Daten fließen, da kommt es dann zu den Aussetzern und Verzögerungen.
Gruß,
wir haben gestern nochmal einen Test gemacht, ich schicke dir nachher noch die Logs + Trace Daten.
Was auffällt ist das große oder kontinuierliche Datenmengen relativ gut gehen, zb Downlods, SSH Logausgaben eines Systems etc, also alles wo konstanter Traffic kommt.
Problematisch sind nicht kontinuierliche Datenströme wie zb surfen, wo immer mal eine URL oder ein Suchbefehl abgesetzt wird und dann erstmal wieder keine Daten fließen, da kommt es dann zu den Aussetzern und Verzögerungen.
Gruß,
-
marsbewohner
- Beiträge: 532
- Registriert: 27 Mär 2007, 13:17
