HI
ich habe an meiner 1823 (8.50RU2) folgendes nervige Verhalten.
Und das obwohl ich testhalber mal einen Richtstrahler mit 8db Verstärkung rangehängt habe um zu sehen ob es nicht ein Empfangsproblem ist.
Irgendeine Idee ?
Mir kommt das vor wie ein altes Problem, das ich schon mal gesehen mit 8.00.
Ach ja der ist ein MacBook Air 2011
[code]
en0:
Kartentyp: AirPort Extreme (0x14E4, 0xE9)
Firmware-Version: Broadcom BCM43xx 1.0 (5.100.98.75.18)
MAC-Adresse: 60:c5:47:00:a8:40
Locale: ETSI
Länderkennung: DE
Unterstützte PHY-Modi: 802.11 a/b/g/n
Unterstützte Kanäle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 36, 40, 44, 48, 52, 56, 60, 64, 100, 104, 108, 112, 116, 120, 124, 128, 132, 136, 140
Ruhezustand bei drahtlosem Zugriff beenden: Unterstützt
AirDrop: Unterstützt
Status: Verbunden
Aktuelle Netzwerkinformationen:
nogo:
PHY-Modus: 802.11n
BSSID: 78:ca:39:46:6a:ab
Kanal: 3
Länderkennung: DE
Netzwerktyp: Infrastruktur
Sicherheit: Persönlicher WPA2
Signal / Störungen: -86 dBm / -91 dBm
Senderate: 1
[/code]
Mac Log:
[code]
15.10.11 08:19:53,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:20:03,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:20:13,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:20:13,863 com.apple.usbmuxd: _SendAttachNotification (thread 0x7fff7ed6f960): sending attach for device 7c:c5:37:18:b2:05@fe80::7ec5:37ff:fe18:b205._apple-mobdev._tcp.local.: _GetAddrInfoReplyReceivedCallback matched.
15.10.11 08:20:26,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:20:34,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:20:36,458 usbmuxd: _select_socket (thread 0x100797000): receive secure message timeout!
15.10.11 08:20:36,458 usbmuxd: AMDeviceStartSession (thread 0x100797000): Could not start session: kAMDInvalidResponseError
15.10.11 08:20:36,458 usbmuxd: _AMDevicePreflightWorker (thread 0x100797000): Pair worker could not pair with device 107: 0xe8000082
15.10.11 08:20:36,458 com.apple.usbmuxd: HandleDeviceAttachHelperCallback preflighting failed for WiFi device 0x6b-10.213.213.155:0: 0xe8000082. Ignoring device.
15.10.11 08:20:43,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
[/code]
Und hier noch mal ein Mac Log aus einem anderen Zeitbereich:
[code]
15.10.11 08:43:20,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:43:30,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:43:40,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:43:50,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:44:00,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:44:10,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:44:20,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:44:30,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:44:40,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:44:50,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:45:00,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:45:09,666 com.apple.mtmd: low priority thinning needed for volume chips (/) with 11.2 <= 20.0 pct free space
15.10.11 08:45:10,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:45:20,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:45:30,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:45:40,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:45:50,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:46:00,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:46:10,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:46:20,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:46:30,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:46:40,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:46:50,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:47:00,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:47:10,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:47:10,607 com.apple.mtmd: low priority thinning needed for volume chips (/) with 11.2 <= 20.0 pct free space
15.10.11 08:47:20,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:47:30,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:47:40,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:47:50,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
15.10.11 08:48:08,000 kernel: MacAuthEvent en0 Auth result for: 00:0b:6b:2a:f0:a3 MAC AUTH succeeded
[/code]
Lancom Log:
[code]
[WLAN-STATUS] 2011/10/15 08:19:51,460
[WLAN-1] Rejected Association from WLAN station 60:c5:47:00:a8:40 []: (Group Cipher is not valid)
[WLAN-STATUS] 2011/10/15 08:19:51,650
[WLAN-1] Queuing a frame for WLAN station d8:a2:5e:02:21:7c (Apple 02:21:7c) in power-save
[WLAN-STATUS] 2011/10/15 08:19:51,790
[WLAN-1] WLAN station d8:a2:5e:02:21:7c (Apple 02:21:7c) [] leaves power-save mode
[WLAN-STATUS] 2011/10/15 08:19:51,790
[WLAN-1] Emitting a power-saved frame for WLAN station d8:a2:5e:02:21:7c (Apple 02:21:7c)
[WLAN-STATUS] 2011/10/15 08:19:52,000
[WLAN-1] WLAN station d8:a2:5e:02:21:7c (Apple 02:21:7c) [] enters power-save mode
[WLAN-STATUS] 2011/10/15 08:20:01,100
[WLAN-1] Rejected Association from WLAN station 60:c5:47:00:a8:40 []: (Group Cipher is not valid)
[/code]
Ping stats:
[code]
64 bytes from 10.213.213.254: icmp_seq=1421 ttl=60 time=53.192 ms
Request timeout for icmp_seq 1422
64 bytes from 10.213.213.254: icmp_seq=1423 ttl=60 time=5.526 ms
64 bytes from 10.213.213.254: icmp_seq=1424 ttl=60 time=55.470 ms
64 bytes from 10.213.213.254: icmp_seq=1425 ttl=60 time=6.035 ms
64 bytes from 10.213.213.254: icmp_seq=1426 ttl=60 time=71.486 ms
64 bytes from 10.213.213.254: icmp_seq=1427 ttl=60 time=2.988 ms
64 bytes from 10.213.213.254: icmp_seq=1428 ttl=60 time=2.774 ms
64 bytes from 10.213.213.254: icmp_seq=1429 ttl=60 time=4.834 ms
64 bytes from 10.213.213.254: icmp_seq=1430 ttl=60 time=4.058 ms
64 bytes from 10.213.213.254: icmp_seq=1431 ttl=60 time=15.627 ms
64 bytes from 10.213.213.254: icmp_seq=1432 ttl=60 time=4.567 ms
64 bytes from 10.213.213.254: icmp_seq=1433 ttl=60 time=4.506 ms
64 bytes from 10.213.213.254: icmp_seq=1434 ttl=60 time=8.778 ms
Request timeout for icmp_seq 1435
64 bytes from 10.213.213.254: icmp_seq=1436 ttl=60 time=3.617 ms
64 bytes from 10.213.213.254: icmp_seq=1437 ttl=60 time=1.926 ms
64 bytes from 10.213.213.254: icmp_seq=1438 ttl=60 time=17.169 ms
64 bytes from 10.213.213.254: icmp_seq=1439 ttl=60 time=5.311 ms
64 bytes from 10.213.213.254: icmp_seq=1440 ttl=60 time=3.855 ms
64 bytes from 10.213.213.254: icmp_seq=1441 ttl=60 time=4.594 ms
64 bytes from 10.213.213.254: icmp_seq=1442 ttl=60 time=4.596 ms
64 bytes from 10.213.213.254: icmp_seq=1443 ttl=60 time=19.283 ms
Request timeout for icmp_seq 1444
64 bytes from 10.213.213.254: icmp_seq=1445 ttl=60 time=5.184 ms
Request timeout for icmp_seq 1446
Request timeout for icmp_seq 1447
Request timeout for icmp_seq 1448
64 bytes from 10.213.213.254: icmp_seq=1447 ttl=60 time=2733.372 ms
64 bytes from 10.213.213.254: icmp_seq=1448 ttl=60 time=1756.629 ms
64 bytes from 10.213.213.254: icmp_seq=1449 ttl=60 time=1766.646 ms
64 bytes from 10.213.213.254: icmp_seq=1450 ttl=60 time=1782.465 ms
64 bytes from 10.213.213.254: icmp_seq=1451 ttl=60 time=1436.167 ms
64 bytes from 10.213.213.254: icmp_seq=1452 ttl=60 time=1337.205 ms
64 bytes from 10.213.213.254: icmp_seq=1453 ttl=60 time=1713.881 ms
64 bytes from 10.213.213.254: icmp_seq=1454 ttl=60 time=2255.287 ms
Request timeout for icmp_seq 1457
64 bytes from 10.213.213.254: icmp_seq=1456 ttl=60 time=2919.678 ms
Request timeout for icmp_seq 1459
Request timeout for icmp_seq 1460
64 bytes from 10.213.213.254: icmp_seq=1457 ttl=60 time=4795.775 ms
Request timeout for icmp_seq 1462
Request timeout for icmp_seq 1463
[/code]
1823 <-> Mac OSX 10.7.2 : Aufwach - Schlaf orgien
Moderator: Lancom-Systems Moderatoren
1823 <-> Mac OSX 10.7.2 : Aufwach - Schlaf orgien
Lancom: LN-830acn 10.40 (out of service 1781VAW 10.40 / L-460agn 8.84.279 /L315 FW 9.0RU3 )
Internet: Vodafone Kabel 1000/50
Telefonie: VOIP only (FB6660, DSL ist bei uns eine Katastrophe, 50m weiter gibt es VDSL ... )
Voip-Provider: Sipgate,KDG
Internet: Vodafone Kabel 1000/50
Telefonie: VOIP only (FB6660, DSL ist bei uns eine Katastrophe, 50m weiter gibt es VDSL ... )
Voip-Provider: Sipgate,KDG
Moin,
WLAN-Status in der Situation ohne WLAN-Data-Trace ist in dieser Situation nicht besonders
aussagekräftig...
Außerdem: um welchen Apple-Client geht's denn überhaupt, ich sehe da zweie, und einer
von denen schafft's offensichtlich noch nicht einmal, sich korrekt anzumelden:
...und...
...ist nun schoneinmal bestimmt kein LANCOM-AP...
Ständiges Schlafenlegen und Aufwachen ist bei aktiviertem Power-Saving und wenig Traffic
erstmal völlig normal, das ist ja der Sinn der Sache, daß das WLAN-Modul die meiste Zeit
Strom spart. Der Preis dafür sind höhere Latenzen beim Ping, weil der Client erst mit dem
nächten Beacon vom AP mitbekommt, daß Daten anliegen, und das kann in der Default-
Einstellung bis zu 100ms dauern.
Wo die verlorenen Pings abbleiben, kann ich ohne den WLAN-Data-Trace nicht sagen. Es
kann ja sein, daß ob schlechter Verbindung schon der Echo-Request vom WLAN-Client beim
AP nicht angekommen ist, dann hat das gar nichts mit Power Saving zu tun - das kommt erst
bei Paketen zum Client ins Spiel.
Gruß Alfred
Gruß Alfred
WLAN-Status in der Situation ohne WLAN-Data-Trace ist in dieser Situation nicht besonders
aussagekräftig...
Außerdem: um welchen Apple-Client geht's denn überhaupt, ich sehe da zweie, und einer
von denen schafft's offensichtlich noch nicht einmal, sich korrekt anzumelden:
Code: Alles auswählen
[WLAN-STATUS] 2011/10/15 08:19:51,460
[WLAN-1] Rejected Association from WLAN station 60:c5:47:00:a8:40 []: (Group Cipher is not valid)
Code: Alles auswählen
BSSID: 78:ca:39:46:6a:ab
Ständiges Schlafenlegen und Aufwachen ist bei aktiviertem Power-Saving und wenig Traffic
erstmal völlig normal, das ist ja der Sinn der Sache, daß das WLAN-Modul die meiste Zeit
Strom spart. Der Preis dafür sind höhere Latenzen beim Ping, weil der Client erst mit dem
nächten Beacon vom AP mitbekommt, daß Daten anliegen, und das kann in der Default-
Einstellung bis zu 100ms dauern.
Wo die verlorenen Pings abbleiben, kann ich ohne den WLAN-Data-Trace nicht sagen. Es
kann ja sein, daß ob schlechter Verbindung schon der Echo-Request vom WLAN-Client beim
AP nicht angekommen ist, dann hat das gar nichts mit Power Saving zu tun - das kommt erst
bei Paketen zum Client ins Spiel.
Gruß Alfred
Gruß Alfred
Hi
das interessante ist das der der Rejected wird der Client ist der den Stress macht. Also er kommt manchmal rein und manchmal nicht.
Und wie das nun mal so ist. Es gibt hier noch weitere Accesspoints, da ich mit einem AP nicht das gesammte Gebäude ausgeleuchtet kriege habe ich halt noch einen Airport Express. Ich habe hier jetzt nicht gefiltert sondern einfach alles was ich hatte hier reingepackt.
Wenn ich statt der 1823 eine L315 oder L305 nehme geht alles ohne Probleme. Könnte also auch ein Client thema sein von N nach G zu roamen.
Ich schaue heute abend mal wie ich Zeit habe auch noch einen DatenTrace zu ziehen.
Irgendwelche Vorgaben für den Trace ?
Gruss
das interessante ist das der der Rejected wird der Client ist der den Stress macht. Also er kommt manchmal rein und manchmal nicht.
Und wie das nun mal so ist. Es gibt hier noch weitere Accesspoints, da ich mit einem AP nicht das gesammte Gebäude ausgeleuchtet kriege habe ich halt noch einen Airport Express. Ich habe hier jetzt nicht gefiltert sondern einfach alles was ich hatte hier reingepackt.
Wenn ich statt der 1823 eine L315 oder L305 nehme geht alles ohne Probleme. Könnte also auch ein Client thema sein von N nach G zu roamen.
Ich schaue heute abend mal wie ich Zeit habe auch noch einen DatenTrace zu ziehen.
Irgendwelche Vorgaben für den Trace ?
Gruss
Lancom: LN-830acn 10.40 (out of service 1781VAW 10.40 / L-460agn 8.84.279 /L315 FW 9.0RU3 )
Internet: Vodafone Kabel 1000/50
Telefonie: VOIP only (FB6660, DSL ist bei uns eine Katastrophe, 50m weiter gibt es VDSL ... )
Voip-Provider: Sipgate,KDG
Internet: Vodafone Kabel 1000/50
Telefonie: VOIP only (FB6660, DSL ist bei uns eine Katastrophe, 50m weiter gibt es VDSL ... )
Voip-Provider: Sipgate,KDG
Moin,
diesem AP nicht erlaubten Verschlüsselungseinstellungen hereinzukommen versucht. Wenn
Du mehrere APs mit unterschiedlichen Einstellungen - und vielleicht noch der gleichen SSID -
hast, dann kann das natürlich sein, daß der Client das durcheinanderwirft. Wäre nicht das
erste Mal bei Apple-Clients
Ein LANCOM bietet defaultmäßig WPA1 mit TKIP und WPA2 mit
AES an. Wenn der Airport nur letzteres anbietet, und Du für keinen anderen Client mehr
TKIP brauchst, würde ich WPA1/TKIP auf dem LANCOM abschalten.
Gruß Alfred
Das ist dann aber ein Problem des Clients und nicht des APs, daß der Client mit aufdas interessante ist das der der Rejected wird der Client ist der den Stress macht. Also er kommt manchmal rein und manchmal nicht.
diesem AP nicht erlaubten Verschlüsselungseinstellungen hereinzukommen versucht. Wenn
Du mehrere APs mit unterschiedlichen Einstellungen - und vielleicht noch der gleichen SSID -
hast, dann kann das natürlich sein, daß der Client das durcheinanderwirft. Wäre nicht das
erste Mal bei Apple-Clients

AES an. Wenn der Airport nur letzteres anbietet, und Du für keinen anderen Client mehr
TKIP brauchst, würde ich WPA1/TKIP auf dem LANCOM abschalten.
sinnvollerweise schrämkt man ihn auf einen Client ein (Setup->WLAN->Trace-MAC).Irgendwelche Vorgaben für den Trace ?
Gruß Alfred
Hi
ich habe bei allen AP die gleichen Einstellungen. So das der Fehler eigentlich nicht auftreten sollte.
Ich habe mal den Airport Express N-AP abgeschaltet und siehe da, die Kiste kommt ohne Probleme bei der 1823 rein.
Und ich habe mit einem mal sinnvolle Ping Zeiten:
PING 10.213.213.254 (10.213.213.254): 56 data bytes
64 bytes from 10.213.213.254: icmp_seq=0 ttl=60 time=1.005 ms
64 bytes from 10.213.213.254: icmp_seq=1 ttl=60 time=1.011 ms
64 bytes from 10.213.213.254: icmp_seq=2 ttl=60 time=1.413 ms
64 bytes from 10.213.213.254: icmp_seq=3 ttl=60 time=1.007 ms
64 bytes from 10.213.213.254: icmp_seq=4 ttl=60 time=0.996 ms
64 bytes from 10.213.213.254: icmp_seq=5 ttl=60 time=1.048 ms
64 bytes from 10.213.213.254: icmp_seq=6 ttl=60 time=4.538 ms
64 bytes from 10.213.213.254: icmp_seq=7 ttl=60 time=1.020 ms
64 bytes from 10.213.213.254: icmp_seq=8 ttl=60 time=1.018 ms
64 bytes from 10.213.213.254: icmp_seq=9 ttl=60 time=1.021 ms
64 bytes from 10.213.213.254: icmp_seq=10 ttl=60 time=1.077 ms
64 bytes from 10.213.213.254: icmp_seq=11 ttl=60 time=1.033 ms
64 bytes from 10.213.213.254: icmp_seq=12 ttl=60 time=1.025 ms
64 bytes from 10.213.213.254: icmp_seq=13 ttl=60 time=1.039 ms
64 bytes from 10.213.213.254: icmp_seq=14 ttl=60 time=1.023 ms
64 bytes from 10.213.213.254: icmp_seq=15 ttl=60 time=1.083 ms
64 bytes from 10.213.213.254: icmp_seq=16 ttl=60 time=1.115 ms
64 bytes from 10.213.213.254: icmp_seq=17 ttl=60 time=1.065 ms
64 bytes from 10.213.213.254: icmp_seq=18 ttl=60 time=1.011 ms
64 bytes from 10.213.213.254: icmp_seq=19 ttl=60 time=1.218 ms
64 bytes from 10.213.213.254: icmp_seq=20 ttl=60 time=1.091 ms
Die .254 ist die 1823.
Auf der Lancom läuft es nun auch besser:
[WLAN-STATUS] 2011/10/16 21:55:30,040
[WLAN-1] Emitting a power-saved frame for WLAN station 60:c5:47:00:a8:40
[WLAN-STATUS] 2011/10/16 21:55:30,260
[WLAN-1] WLAN station 60:c5:47:00:a8:40 [] enters power-save mode
[WLAN-STATUS] 2011/10/16 21:55:30,270
[WLAN-1] Queuing a frame for WLAN station 60:c5:47:00:a8:40 in power-save
[WLAN-STATUS] 2011/10/16 21:55:30,290
[WLAN-1] WLAN station 60:c5:47:00:a8:40 [] leaves power-save mode
[WLAN-STATUS] 2011/10/16 21:55:30,290
[WLAN-1] Emitting a power-saved frame for WLAN station 60:c5:47:00:a8:40
[WLAN-STATUS] 2011/10/16 21:55:30,510
[WLAN-1] WLAN station 60:c5:47:00:a8:40 [] enters power-save mode
ich würde sagen hier hat Apple mit dem Treiber scheisse gebaut.
Unter Windows macht das gleiche Notebook keinen Stress.
Kann natürlich immer noch sein dass ich auf dem AP was nicht ganz sauber habe. Das schaue ich dann mal noch nach .
Gruss
ich habe bei allen AP die gleichen Einstellungen. So das der Fehler eigentlich nicht auftreten sollte.
Ich habe mal den Airport Express N-AP abgeschaltet und siehe da, die Kiste kommt ohne Probleme bei der 1823 rein.
Und ich habe mit einem mal sinnvolle Ping Zeiten:
PING 10.213.213.254 (10.213.213.254): 56 data bytes
64 bytes from 10.213.213.254: icmp_seq=0 ttl=60 time=1.005 ms
64 bytes from 10.213.213.254: icmp_seq=1 ttl=60 time=1.011 ms
64 bytes from 10.213.213.254: icmp_seq=2 ttl=60 time=1.413 ms
64 bytes from 10.213.213.254: icmp_seq=3 ttl=60 time=1.007 ms
64 bytes from 10.213.213.254: icmp_seq=4 ttl=60 time=0.996 ms
64 bytes from 10.213.213.254: icmp_seq=5 ttl=60 time=1.048 ms
64 bytes from 10.213.213.254: icmp_seq=6 ttl=60 time=4.538 ms
64 bytes from 10.213.213.254: icmp_seq=7 ttl=60 time=1.020 ms
64 bytes from 10.213.213.254: icmp_seq=8 ttl=60 time=1.018 ms
64 bytes from 10.213.213.254: icmp_seq=9 ttl=60 time=1.021 ms
64 bytes from 10.213.213.254: icmp_seq=10 ttl=60 time=1.077 ms
64 bytes from 10.213.213.254: icmp_seq=11 ttl=60 time=1.033 ms
64 bytes from 10.213.213.254: icmp_seq=12 ttl=60 time=1.025 ms
64 bytes from 10.213.213.254: icmp_seq=13 ttl=60 time=1.039 ms
64 bytes from 10.213.213.254: icmp_seq=14 ttl=60 time=1.023 ms
64 bytes from 10.213.213.254: icmp_seq=15 ttl=60 time=1.083 ms
64 bytes from 10.213.213.254: icmp_seq=16 ttl=60 time=1.115 ms
64 bytes from 10.213.213.254: icmp_seq=17 ttl=60 time=1.065 ms
64 bytes from 10.213.213.254: icmp_seq=18 ttl=60 time=1.011 ms
64 bytes from 10.213.213.254: icmp_seq=19 ttl=60 time=1.218 ms
64 bytes from 10.213.213.254: icmp_seq=20 ttl=60 time=1.091 ms
Die .254 ist die 1823.
Auf der Lancom läuft es nun auch besser:
[WLAN-STATUS] 2011/10/16 21:55:30,040
[WLAN-1] Emitting a power-saved frame for WLAN station 60:c5:47:00:a8:40
[WLAN-STATUS] 2011/10/16 21:55:30,260
[WLAN-1] WLAN station 60:c5:47:00:a8:40 [] enters power-save mode
[WLAN-STATUS] 2011/10/16 21:55:30,270
[WLAN-1] Queuing a frame for WLAN station 60:c5:47:00:a8:40 in power-save
[WLAN-STATUS] 2011/10/16 21:55:30,290
[WLAN-1] WLAN station 60:c5:47:00:a8:40 [] leaves power-save mode
[WLAN-STATUS] 2011/10/16 21:55:30,290
[WLAN-1] Emitting a power-saved frame for WLAN station 60:c5:47:00:a8:40
[WLAN-STATUS] 2011/10/16 21:55:30,510
[WLAN-1] WLAN station 60:c5:47:00:a8:40 [] enters power-save mode
ich würde sagen hier hat Apple mit dem Treiber scheisse gebaut.
Unter Windows macht das gleiche Notebook keinen Stress.
Kann natürlich immer noch sein dass ich auf dem AP was nicht ganz sauber habe. Das schaue ich dann mal noch nach .
Gruss
Lancom: LN-830acn 10.40 (out of service 1781VAW 10.40 / L-460agn 8.84.279 /L315 FW 9.0RU3 )
Internet: Vodafone Kabel 1000/50
Telefonie: VOIP only (FB6660, DSL ist bei uns eine Katastrophe, 50m weiter gibt es VDSL ... )
Voip-Provider: Sipgate,KDG
Internet: Vodafone Kabel 1000/50
Telefonie: VOIP only (FB6660, DSL ist bei uns eine Katastrophe, 50m weiter gibt es VDSL ... )
Voip-Provider: Sipgate,KDG
Hi
sieht nach einem MacOS Problem aus. Der Mac versucht mit aller Gewalt im N Accesspoint zu bleiben . Man muss Ihn aktiv in den G Access Point zwingen. Also ein Problem im Roaming N <-> G.
Gruss
sieht nach einem MacOS Problem aus. Der Mac versucht mit aller Gewalt im N Accesspoint zu bleiben . Man muss Ihn aktiv in den G Access Point zwingen. Also ein Problem im Roaming N <-> G.
Gruss
Lancom: LN-830acn 10.40 (out of service 1781VAW 10.40 / L-460agn 8.84.279 /L315 FW 9.0RU3 )
Internet: Vodafone Kabel 1000/50
Telefonie: VOIP only (FB6660, DSL ist bei uns eine Katastrophe, 50m weiter gibt es VDSL ... )
Voip-Provider: Sipgate,KDG
Internet: Vodafone Kabel 1000/50
Telefonie: VOIP only (FB6660, DSL ist bei uns eine Katastrophe, 50m weiter gibt es VDSL ... )
Voip-Provider: Sipgate,KDG