WPA/WEP & 802.1X mit Apple Computer
Moderator: Lancom-Systems Moderatoren
WPA/WEP & 802.1X mit Apple Computer
Hi @ all, hab mir einen schönen LanCom L-54ag gekauft, und hab ein Problem mit Apple Clients.
Hintergrundinfo:
- LanCom L-54ag AccessPoint
- Microsoft IAS für Authentification
- WPA (AES/TKIP) Verschlüsselung
- Apple Computer: iBook G4 mit Airport Extreme (802.11g)
- Serverzertifikate sind auf beiden Rechner installiert
Verbindung ohne Verschlüsselung funktioniert mit Apple Computer ohne Probleme, bei Verschlüsselung (egal ob WEP oder WPA) funktioniert die Radius Anmeldung ohne Probleme und der Zugriff wird gewährt, jedoch kommt keine Verbindung zustande. Vermute mal das die Zuweisung des Schlüssels nicht klappt.
Im LanCom Monitor wird der Apple Client auch angezeigt allerdings mit einem Verbotszeichen?!?, als Verschlüsselung steht TKIP da, sollte eine 802.11g Karte nicht bereits AES beherschen, dachte TKIP ist nur für die .11b Kompatibilität.
Bei x86 mit WXP und ORiNOCO Karte klappt wie gewohnt alles auf Anhieb.
Hat jemand von euch schon Erfahrungen mit LanCom + Apple Computer gemacht?
Bevor jetzt jemand die Schuld auf Apple schiebt, mit einem (D)*würg*-Link, klappt WPA & Radius Auth. bei dem iBook ohne Probleme.
Mich wundert zusätzlich das bei z.B. NetStubmler das WLAN mit WPA als nicht verschlüsselt angezeigt wird, das D-Link WLAN mit WPA aber als verschlüsselt gekennzeichtet ist. Dennoch kommt beim Apple die WPA/802.1x Anmeldeaufforderung.
Wenn hier jemand irgendwelche Tipps hat wäre das Klasse, soweit finde ich die LanCom Geräte spitzen klasse, selbst den alten L-2 den ich letze Woche bei ebay ersteigert hab, 11MBit ORiNOCO Karte rein und LC.OS 3.5x drauf und perfekt !!!
Hintergrundinfo:
- LanCom L-54ag AccessPoint
- Microsoft IAS für Authentification
- WPA (AES/TKIP) Verschlüsselung
- Apple Computer: iBook G4 mit Airport Extreme (802.11g)
- Serverzertifikate sind auf beiden Rechner installiert
Verbindung ohne Verschlüsselung funktioniert mit Apple Computer ohne Probleme, bei Verschlüsselung (egal ob WEP oder WPA) funktioniert die Radius Anmeldung ohne Probleme und der Zugriff wird gewährt, jedoch kommt keine Verbindung zustande. Vermute mal das die Zuweisung des Schlüssels nicht klappt.
Im LanCom Monitor wird der Apple Client auch angezeigt allerdings mit einem Verbotszeichen?!?, als Verschlüsselung steht TKIP da, sollte eine 802.11g Karte nicht bereits AES beherschen, dachte TKIP ist nur für die .11b Kompatibilität.
Bei x86 mit WXP und ORiNOCO Karte klappt wie gewohnt alles auf Anhieb.
Hat jemand von euch schon Erfahrungen mit LanCom + Apple Computer gemacht?
Bevor jetzt jemand die Schuld auf Apple schiebt, mit einem (D)*würg*-Link, klappt WPA & Radius Auth. bei dem iBook ohne Probleme.
Mich wundert zusätzlich das bei z.B. NetStubmler das WLAN mit WPA als nicht verschlüsselt angezeigt wird, das D-Link WLAN mit WPA aber als verschlüsselt gekennzeichtet ist. Dennoch kommt beim Apple die WPA/802.1x Anmeldeaufforderung.
Wenn hier jemand irgendwelche Tipps hat wäre das Klasse, soweit finde ich die LanCom Geräte spitzen klasse, selbst den alten L-2 den ich letze Woche bei ebay ersteigert hab, 11MBit ORiNOCO Karte rein und LC.OS 3.5x drauf und perfekt !!!
Moin,
Ich vermute, Du benutzt als Verschlüsselungsmethode WPA/11i zusammen
mit 802.1x? Dann müßte man mit einem EAPOOL-Trace sehen können,
was genauer passiert (in der Telnet-Oberfläche 'trace + eapol' eingeben).
bis zur 4.02 sind zwei Bugs in der Firmware dirn, die bei manchen
Supplicants Probleme im Zusammenhang mit 802.1x verursachen können.
Frag' bei mSupport mal nach einer 4.04 bzw. 4.12 .
>Im LanCom Monitor wird der Apple Client auch angezeigt allerdings mit einem
>Verbotszeichen?!?,
Dann ist auch aus der Sicht des LANCOM die Anmeldung nicht vollständig
durchgelaufen, im Trace sollte man wie gesagt mehr sehen können.
>als Verschlüsselung steht TKIP da, sollte eine 802.11g Karte nicht bereits
>AES beherschen, dachte TKIP ist nur für die .11b Kompatibilität.
Broadcom hat AES erst später nachgeliefert, bei meiner Belkin-Karte
funktionierte AES auch erst nach Installation von SP2.
>Mich wundert zusätzlich das bei z.B. NetStubmler das WLAN mit WPA als nicht verschlüsselt
> angezeigt wird, das D-Link WLAN mit WPA aber als verschlüsselt gekennzeichtet ist.
Bei WPA/11i hat sich die Interpretation einiger Felder im Beacon bzw.
Probe Response geändert. Auf den Netstumbler würde ich in dieser Hinsicht nicht
viel geben.
Gruß Alfred
Ich vermute, Du benutzt als Verschlüsselungsmethode WPA/11i zusammen
mit 802.1x? Dann müßte man mit einem EAPOOL-Trace sehen können,
was genauer passiert (in der Telnet-Oberfläche 'trace + eapol' eingeben).
bis zur 4.02 sind zwei Bugs in der Firmware dirn, die bei manchen
Supplicants Probleme im Zusammenhang mit 802.1x verursachen können.
Frag' bei mSupport mal nach einer 4.04 bzw. 4.12 .
>Im LanCom Monitor wird der Apple Client auch angezeigt allerdings mit einem
>Verbotszeichen?!?,
Dann ist auch aus der Sicht des LANCOM die Anmeldung nicht vollständig
durchgelaufen, im Trace sollte man wie gesagt mehr sehen können.
>als Verschlüsselung steht TKIP da, sollte eine 802.11g Karte nicht bereits
>AES beherschen, dachte TKIP ist nur für die .11b Kompatibilität.
Broadcom hat AES erst später nachgeliefert, bei meiner Belkin-Karte
funktionierte AES auch erst nach Installation von SP2.
>Mich wundert zusätzlich das bei z.B. NetStubmler das WLAN mit WPA als nicht verschlüsselt
> angezeigt wird, das D-Link WLAN mit WPA aber als verschlüsselt gekennzeichtet ist.
Bei WPA/11i hat sich die Interpretation einiger Felder im Beacon bzw.
Probe Response geändert. Auf den Netstumbler würde ich in dieser Hinsicht nicht
viel geben.
Gruß Alfred
Hallo,
erstmal vielen Dank für die schnelle Antwort, habe das Log attached. Bei LanCom frag ich gleich mal nach der Firmware nach.
Wenn du was im Log findest sag bescheid, hab aus dem Log nichts zensiert, man sieht auch den Benutzernamen usw.
erstmal vielen Dank für die schnelle Antwort, habe das Log attached. Bei LanCom frag ich gleich mal nach der Firmware nach.
Wenn du was im Log findest sag bescheid, hab aus dem Log nichts zensiert, man sieht auch den Benutzernamen usw.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Moin,
das sieht eigentlich alles gut aus, bis zum letzten Schritt, in dem der AP
nach der Aushandlung des Session-Keys an den Client den für
Broadcasts benutzten Schlüssel übertragen will - und das klappt nicht.
Das ist das erste Paket, in dem AP und Client verschlüsselt miteinander
reden, irgendetwas scheint da nicht zu klappen - ich kann aber so
nicht sehen was...das letzte Mal, daß ich so etwas hatte, war das eine
MC-54ag unter Windows, bei der irgendwo noch ein alter Treiber auf
dem System herumgeisterte, der noch nicht 100% WPA konnte...
Gruß Alfred
das sieht eigentlich alles gut aus, bis zum letzten Schritt, in dem der AP
nach der Aushandlung des Session-Keys an den Client den für
Broadcasts benutzten Schlüssel übertragen will - und das klappt nicht.
Das ist das erste Paket, in dem AP und Client verschlüsselt miteinander
reden, irgendetwas scheint da nicht zu klappen - ich kann aber so
nicht sehen was...das letzte Mal, daß ich so etwas hatte, war das eine
MC-54ag unter Windows, bei der irgendwo noch ein alter Treiber auf
dem System herumgeisterte, der noch nicht 100% WPA konnte...
Gruß Alfred
Auch Firmware 4.12 bei 1821 ergibt gleichen Fehler
Ich habe das gleiche Problem wie oben geschildert mit firmware 4.12 auf einem 1821er. Siehe Attachment. Hier ohne RADIUS, reines PSK WPA.raz hat geschrieben:Hallo,
erstmal vielen Dank für die schnelle Antwort, habe das Log attached. Bei LanCom frag ich gleich mal nach der Firmware nach.
Wenn du was im Log findest sag bescheid, hab aus dem Log nichts zensiert, man sieht auch den Benutzernamen usw.
Hat es bei dir eine Lösung gegeben?
Ansonsten, gibt es eine LANCOM "troubleticket" auf das ich bei einem Bericht an LANCOM hinweisen könnte?
Das Problem liegt zu 99,9% bei LANCOM, denn neben den hier aufgeführten anderen Routerfabrikat DLINK weiss ich aus eigenem Test dass es mit Zyxel (Prestige 653HWI) und Linksys mit Apple MAC OS X 10.3.x und WPA geht.
Georg
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
1821 5.00
Ich habe das gleiche Problem wie oben geschildert mit firmware 4.12 auf einem 1821er. Siehe Attachment. Hier ohne RADIUS, reines PSK WPA.
Hat es bei dir eine Lösung gegeben?
Ansonsten, gibt es eine LANCOM "troubleticket" auf das ich bei einem Bericht an LANCOM hinweisen könnte?
Das Problem liegt zu 99,9% bei LANCOM, denn neben den hier aufgeführten anderen Routerfabrikat DLINK weiss ich aus eigenem Test dass es mit Zyxel (Prestige 653HWI) und Linksys mit Apple MAC OS X 10.3.x und WPA geht.
Hi
Einspruch!
Das Problem liegt zu 99,99 Prozentz nicht bei Lancom, da ich diese Posting hier über einen 1821er (4.12) und einem iBook mit WPA/PSK eines Bekannten schreibe!
"Spiel" mal mit den Einstellungen an deinem Mac.
(Ich muß leider sofort jetzt weg und kann leider keine Screenshoots posten)
Grüße
Gaaaz
Hallo,
ich habe es bisher auch noch nicht geschafft mein Powerbook mit WPA/PASK mit meinem 1821 zu verbinden.
Das Powerbook meldet dann sinngemäß so etwas: "Die angefordete Verschüsselung wird nicht unterstützt".
Ich habe schon alle Einstellungen am Mac ausprobiert (so viele sind es ja nun auch nicht...), bisher ohne Erfolg.
Ich wäre für eine Lösung des Problems auch dankbar.
Gruß
Alfred
ich habe es bisher auch noch nicht geschafft mein Powerbook mit WPA/PASK mit meinem 1821 zu verbinden.
Das Powerbook meldet dann sinngemäß so etwas: "Die angefordete Verschüsselung wird nicht unterstützt".
Ich habe schon alle Einstellungen am Mac ausprobiert (so viele sind es ja nun auch nicht...), bisher ohne Erfolg.
Ich wäre für eine Lösung des Problems auch dankbar.
Gruß
Alfred
Danke für die Info dass es doch möglich sein soll.Gaaaz hat geschrieben:Ich habe das gleiche Problem wie oben geschildert mit firmware 4.12 auf einem 1821er. Siehe Attachment. Hier ohne RADIUS, reines PSK WPA.
....
Hi
Einspruch!
Das Problem liegt zu 99,99 Prozentz nicht bei Lancom, da ich diese Posting hier über einen 1821er (4.12) und einem iBook mit WPA/PSK eines Bekannten schreibe!
"Spiel" mal mit den Einstellungen an deinem Mac.
(Ich muß leider sofort jetzt weg und kann leider keine Screenshoots posten)
Grüße
Gaaaz
Trotzdem die Nachfrage WIE?
Ich habe genau wie Alfred alle Varianten durchgespielt, ca. 4h damit verbracht und immer kam im EAP Trace der bekannte Fehler.
Bitte wenn möglich die MAC / 1821 screenshots posten.
Georg
1821 5.00
Hi,
hier schon mal ein Update:
Screenshots hab' ich erst am kommenden Di.
Hier aber ein paar Infos die schon weiter helfen könnten:
Mit LCOS 4.02/4.12 getestet.
Damit gings.
Wichtige Voraussetung beim MAC:
-OS X >=10.3
-WLAN-Kartentreiber Airport >=Version 3.3
-bei der Passphrase aufpassen: Beginnt sie mit "$" (Dollar) interpretiert der MAC die folgenden Zeichen als Hex-Code, was natürlich für Blödsinn sorgt, da der AP ASCII erwartet.
-Die Passphrase muß mindestens 8 Zeichen lang sein
Beim Access Point:
-Bei der WPA-Verschlüsselung nur TKIP wählen! Nicht AES/TKIP!!!
(Mit AES hat der MAC je nach verwendeter Hardware Probleme/kann er (noch) nicht)
Grüße
Gaaaz
hier schon mal ein Update:
Screenshots hab' ich erst am kommenden Di.
Hier aber ein paar Infos die schon weiter helfen könnten:
Mit LCOS 4.02/4.12 getestet.
Damit gings.
Wichtige Voraussetung beim MAC:
-OS X >=10.3
-WLAN-Kartentreiber Airport >=Version 3.3
-bei der Passphrase aufpassen: Beginnt sie mit "$" (Dollar) interpretiert der MAC die folgenden Zeichen als Hex-Code, was natürlich für Blödsinn sorgt, da der AP ASCII erwartet.
-Die Passphrase muß mindestens 8 Zeichen lang sein
Beim Access Point:
-Bei der WPA-Verschlüsselung nur TKIP wählen! Nicht AES/TKIP!!!
(Mit AES hat der MAC je nach verwendeter Hardware Probleme/kann er (noch) nicht)
Grüße
Gaaaz
Danke Gaaaz für deinen Support.Gaaaz hat geschrieben:Hi,
hier schon mal ein Update:
Screenshots hab' ich erst am kommenden Di.
Hier aber ein paar Infos die schon weiter helfen könnten:
Mit LCOS 4.02/4.12 getestet.
Damit gings.
Wichtige Voraussetung beim MAC:
-OS X >=10.3
-WLAN-Kartentreiber Airport >=Version 3.3
-bei der Passphrase aufpassen: Beginnt sie mit "$" (Dollar) interpretiert der MAC die folgenden Zeichen als Hex-Code, was natürlich für Blödsinn sorgt, da der AP ASCII erwartet.
-Die Passphrase muß mindestens 8 Zeichen lang sein
Beim Access Point:
-Bei der WPA-Verschlüsselung nur TKIP wählen! Nicht AES/TKIP!!!
(Mit AES hat der MAC je nach verwendeter Hardware Probleme/kann er (noch) nicht)
Grüße
Gaaaz
Leider helfen die Tipps nicht weiter, da alle Punkte genauso wie angegeben ausprobiert wurden:
a) 4.12 - logisch
b) Karten Treiber sind AirPort2 (neuere Version, b/g) mit 3.4.4 (aktiv) ansonsten für normale Airport ist 3.4.3 drauf
c) OS-X ist hier 10.3.9 (neueste Support Version, ging allerdings auch nicht mit vorigen)
d) passphrase ist ganz simpel nur ASCII genau 8 Zchn lang
e) das mit TKIP ist auch klar geworden anhand der Protokollanalyse, mit AES ist der Fehler heftiger/früher ich meine Phase 1 oder 2 statt wie hier immer in Phase 5
im LOG auf dem MAC ist zu lesen:
Code: Alles auswählen
May 8 19:54:15 localhost kernel: AirPort: Link UP: "bitter" - 020b6b347ef0 - chan 1
May 8 19:54:15 localhost kernel: AirPort: Rx'd mesg P-1
May 8 19:54:15 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 19:54:16 localhost kernel: AirPort: Rx'd mesg P-1
May 8 19:54:34 localhost last message repeated 19 times
May 8 19:54:35 localhost kernel: AirPort: Link DOWN
May 8 19:54:35 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 19:54:38 localhost kernel: AirPort: Link UP: "bitter" - 020b6b347ef0 - chan 1
May 8 19:54:38 localhost kernel: AirPort: Rx'd mesg P-1
May 8 19:54:38 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 19:54:39 localhost kernel: AirPort: Rx'd mesg P-1
May 8 19:54:57 localhost last message repeated 19 times
May 8 19:54:59 localhost kernel: AirPort: Link DOWN
May 8 19:54:59 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 19:55:01 localhost kernel: AirPort: Link UP: "bitter" - 020b6b347ef0 - chan 1
May 8 19:55:01 localhost kernel: AirPort: Rx'd mesg P-1
May 8 19:55:01 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 19:55:02 localhost kernel: AirPort: Rx'd mesg P-1
May 8 19:55:20 localhost last message repeated 19 times
May 8 19:55:22 localhost kernel: AirPort: Link DOWN
May 8 19:55:22 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 19:55:24 localhost kernel: AirPort: Link UP: "bitter" - 020b6b347ef0 - chan 1
May 8 19:55:24 localhost kernel: AirPort: Rx'd mesg P-1
May 8 19:55:24 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 19:55:25 localhost kernel: AirPort: Rx'd mesg P-1
May 8 19:55:28 localhost last message repeated 4 times
May 8 19:55:29 localhost kernel: AirPort: Link DOWN
May 8 19:55:29 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 19:55:30 localhost kernel: AirPort: Link UP: "bitter" - 020b6b347ef0 - chan 1
May 8 19:55:30 localhost kernel: AirPort: Rx'd mesg P-1
May 8 19:55:30 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 19:55:30 localhost kernel: AirPort: Rx'd mesg P-3
May 8 19:55:50 localhost kernel: AirPort: Link DOWN
May 8 19:55:50 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 19:55:52 localhost kernel: AirPort: Link UP: "bitter" - 020b6b347ef0 - chan 1
May 8 19:55:52 localhost kernel: AirPort: Rx'd mesg P-1
May 8 19:55:52 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 19:55:52 localhost kernel: AirPort: Rx'd mesg P-3
May 8 19:56:13 localhost kernel: AirPort: Link DOWN
May 8 19:56:13 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 19:56:15 localhost kernel: AirPort: Link UP: "bitter" - 020b6b347ef0 - chan 1
May 8 19:56:15 localhost kernel: AirPort: Rx'd mesg P-1
May 8 19:56:15 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 19:56:15 localhost kernel: AirPort: Rx'd mesg P-3
May 8 19:56:36 localhost kernel: AirPort: Link DOWN
May 8 19:56:36 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 19:56:38 localhost kernel: AirPort: Link UP: "bitter" - 020b6b347ef0 - chan 1
.....
May 8 20:00:51 localhost kernel: AirPort: Link UP: "bitter" - 020b6b347ef0 - chan 1
May 8 20:00:51 localhost kernel: AirPort: Rx'd mesg P-1
May 8 20:00:51 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 20:00:51 localhost kernel: AirPort: Rx'd mesg P-3
May 8 20:01:12 localhost kernel: AirPort: Link DOWN
May 8 20:01:12 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 20:01:14 localhost kernel: AirPort: Link UP: "bitter" - 020b6b347ef0 - chan 1
May 8 20:01:14 localhost kernel: AirPort: Rx'd mesg P-1
May 8 20:01:14 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 20:01:14 localhost kernel: AirPort: Rx'd mesg P-3
May 8 20:01:27 localhost kernel: AirPort: Link DOWN
May 8 20:01:27 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 20:01:27 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 20:13:08 localhost kernel: AirPort: Link UP: "bitter" - 020b6b347ef0 - chan 1
May 8 20:13:08 localhost kernel: AirPort: Rx'd mesg P-1
May 8 20:13:08 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 20:13:08 localhost kernel: AirPort: Rx'd mesg P-3
May 8 20:13:28 localhost kernel: AirPort: Link DOWN
May 8 20:13:28 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 20:13:31 localhost kernel: AirPort: Link UP: "bitter" - 020b6b347ef0 - chan 1
May 8 20:13:31 localhost kernel: AirPort: Rx'd mesg P-1
May 8 20:13:31 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 20:13:31 localhost kernel: AirPort: Rx'd mesg P-3
May 8 20:13:42 localhost kernel: AirPort: Link DOWN
May 8 20:13:42 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 20:13:43 localhost kernel: AirPort: Link UP: "bitter" - 020b6b347ef0 - chan 1
May 8 20:13:43 localhost kernel: AirPort: Rx'd mesg P-1
May 8 20:13:43 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 20:13:43 localhost kernel: AirPort: Rx'd mesg P-3
May 8 20:14:03 localhost kernel: AirPort: Link DOWN
May 8 20:14:03 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 20:14:06 localhost kernel: AirPort: Link UP: "bitter" - 020b6b347ef0 - chan 1
May 8 20:14:06 localhost kernel: AirPort: Rx'd mesg P-1
May 8 20:14:06 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 20:14:06 localhost kernel: AirPort: Rx'd mesg P-3
May 8 20:14:26 localhost kernel: AirPort: Link DOWN
May 8 20:14:26 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 20:14:29 localhost kernel: AirPort: Link UP: "bitter" - 020b6b347ef0 - chan 1
May 8 20:14:29 localhost kernel: AirPort: Rx'd mesg P-1
May 8 20:14:29 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 20:14:29 localhost kernel: AirPort: Rx'd mesg P-3
May 8 20:14:50 localhost kernel: AirPort: Link DOWN
May 8 20:14:50 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 20:14:52 localhost kernel: AirPort: Link UP: "bitter" - 020b6b347ef0 - chan 1
May 8 20:14:52 localhost kernel: AirPort: Rx'd mesg P-1
May 8 20:14:52 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 20:14:52 localhost kernel: AirPort: Rx'd mesg P-3
May 8 20:15:12 localhost kernel: AirPort: Link DOWN
May 8 20:15:12 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 20:15:15 localhost kernel: AirPort: Link UP: "bitter" - 020b6b347ef0 - chan 1
May 8 20:15:15 localhost kernel: AirPort: Rx'd mesg P-1
May 8 20:15:15 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 20:15:15 localhost kernel: AirPort: Rx'd mesg P-3
May 8 20:15:34 localhost kernel: AirPort: Link DOWN
May 8 20:15:34 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
und der EAP + trace liefert weiterhin:
[EAP] 2005/05/08 20:14:44,850
***Starting EAP key exchange with supplicant 000a95f620bc
-->Switching to key exchange phase 1, send corresponding packet
-->EAPOL Header
Protocol Version : 1
Packet Type : Key
Packet Length : 95
Key Type : 254
-->802.11i RSN Key Descriptor
Key Information : Version 1 Pairwise Key-Index 0 ACK
Key Length : 32
Replay Counter : 0000000000000001
Nonce : 75 13 9d 36 3a 89 ce 9b u..6:...
f0 fc 64 6d 95 c6 b1 16 ..dm....
4a e3 58 8b c8 c9 2f 65 J.X.../e
89 dc 14 92 44 ee 0a 49 ....D..I
Key IV : 00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
Key RSC : 00 00 00 00 00 00 00 00 ........
Key ID : 00 00 00 00 00 00 00 00 ........
Key MIC : 00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
Key Data Length : 0
[EAP] 2005/05/08 20:14:44,900
***Received EAP packet:
-->EAPOL Header
Protocol Version : 1
Packet Type : Key
Packet Length : 119
Key Type : 254
-->802.11i RSN Key Descriptor
Key Information : Version 1 Pairwise Key-Index 0 MIC
Key Length : 0
Replay Counter : 0000000000000001
Nonce : 29 b7 59 97 06 d5 c7 47 ).Y....G
19 2e 02 f6 8e 45 d5 c5 .....E..
b2 b9 44 73 2a 89 f3 bf ..Ds*...
c7 d1 ee 8f be 61 e6 29 .....a.)
Key IV : 00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
Key RSC : 00 00 00 00 00 00 00 00 ........
Key ID : 00 00 00 00 00 00 00 00 ........
Key MIC : 60 a7 aa c6 13 f0 04 1e `.......
85 9d d3 73 ac dc 3c 3b ...s..<;
Key Data Length : 24
Key Data : dd 16 00 50 f2 01 01 00 ...P....
00 50 f2 02 01 00 00 50 .P.....P
f2 02 01 00 00 50 f2 02 .....P..
-->Received properly sequenced packet from supplicant for phase 2
-->Computing PTK
-->Switching to key exchange phase 3, send corresponding packet
-->EAPOL Header
Protocol Version : 1
Packet Type : Key
Packet Length : 119
Key Type : 254
-->802.11i RSN Key Descriptor
Key Information : Version 1 Pairwise Key-Index 0 Install ACK MIC
Key Length : 32
Replay Counter : 0000000000000002
Nonce : 75 13 9d 36 3a 89 ce 9b u..6:...
f0 fc 64 6d 95 c6 b1 16 ..dm....
4a e3 58 8b c8 c9 2f 65 J.X.../e
89 dc 14 92 44 ee 0a 49 ....D..I
Key IV : 00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
Key RSC : 01 00 00 00 00 00 00 00 ........
Key ID : 00 00 00 00 00 00 00 00 ........
Key MIC : a3 3c ba c6 b7 19 61 50 .<....aP
25 c4 b9 53 20 7d 46 7b %..S }F{
Key Data Length : 24
Key Data : dd 16 00 50 f2 01 01 00 ...P....
00 50 f2 02 01 00 00 50 .P.....P
f2 02 01 00 00 50 f2 02 .....P..
[EAP] 2005/05/08 20:14:44,910
***Received EAP packet:
-->EAPOL Header
Protocol Version : 1
Packet Type : Key
Packet Length : 95
Key Type : 254
-->802.11i RSN Key Descriptor
Key Information : Version 1 Pairwise Key-Index 0 MIC
Key Length : 0
Replay Counter : 0000000000000002
Nonce : 00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
Key IV : 00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
Key RSC : 00 00 00 00 00 00 00 00 ........
Key ID : 00 00 00 00 00 00 00 00 ........
Key MIC : b9 99 db 09 9a 9b d4 1c ........
32 be da 52 1f d1 ca 1e 2..R....
Key Data Length : 0
-->Received properly sequenced packet from supplicant for phase 4
-->PTK handshake successfully performed, configuring pairwise key into hardware
-->Switching to GTK negotiation
-->EAPOL Header
Protocol Version : 1
Packet Type : Key
Packet Length : 127
Key Type : 254
-->802.11i RSN Key Descriptor
Key Information : Version 1 Group Key-Index 1 ACK MIC Secure Encrypted-Key-Data
Key Length : 32
Replay Counter : 0000000000000003
Nonce : 00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
Key IV : cf cf 86 04 67 e7 c3 02 ....g...
33 f3 e1 81 f4 41 73 e0 3....As.
Key RSC : 01 00 00 00 00 00 00 00 ........
Key ID : 00 00 00 00 00 00 00 00 ........
Key MIC : c3 cb 7c 1c 7f a2 b9 96 ..|.....
d3 6e 46 fb 14 84 dd 09 .nF.....
Key Data Length : 32
Key Data : fc 60 c9 71 75 be ca e9 .`.qu...
88 21 0c 4b 9c 88 f1 d1 .!.K....
b9 7c 82 57 9f be 69 bf .|.W..i.
8c 82 ae ad 10 46 b6 a0 .....F..
[EAP] 2005/05/08 20:14:45,220
***Timeout occured for negotiation with 000a95f620bc in phase 5
-->Retrying, this time with 510 ms timeout...
-->EAPOL Header
Protocol Version : 1
Packet Type : Key
Packet Length : 127
Key Type : 254
-->802.11i RSN Key Descriptor
Key Information : Version 1 Group Key-Index 1 ACK MIC Secure Encrypted-Key-Data
Key Length : 32
Replay Counter : 0000000000000004
Nonce : 00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
Key IV : 7a 20 b9 f0 3d 10 5c f8 z ..=.\.
1e 88 2e 7c 0f 44 17 3e ...|.D.>
Key RSC : 01 00 00 00 00 00 00 00 ........
Key ID : 00 00 00 00 00 00 00 00 ........
Key MIC : 35 ed 3e b0 24 eb 33 63 5.>.$.3c
57 8b fd f6 c1 d4 9d 6f W......o
Key Data Length : 32
Key Data : 80 18 d1 51 30 84 c8 c6 ...Q0...
e2 2a 17 4a f2 35 58 e0 .*.J.5X.
a8 d5 31 ae 93 c1 91 26 ..1....&
41 04 0a 37 56 c1 18 bf A..7V...
[EAP] 2005/05/08 20:14:45,730
***Timeout occured for negotiation with 000a95f620bc in phase 5
-->Retrying, this time with 1020 ms timeout...
-->EAPOL Header
Protocol Version : 1
Packet Type : Key
Packet Length : 127
Key Type : 254
-->802.11i RSN Key Descriptor
Key Information : Version 1 Group Key-Index 1 ACK MIC Secure Encrypted-Key-Data
Key Length : 32
Replay Counter : 0000000000000005
Nonce : 00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
Key IV : 07 a2 0b 9f ee 69 86 ef .....i..
9a 8c 40 57 a0 fe a3 0b ..@W....
Key RSC : 01 00 00 00 00 00 00 00 ........
Key ID : 00 00 00 00 00 00 00 00 ........
Key MIC : 0d c9 5d 29 f1 06 2f 24 ..])../$
d9 20 95 c9 79 b6 06 86 . ..y...
Key Data Length : 32
Key Data : d0 dd 46 70 ae d6 d9 42 ..Fp...B
ef 0e 50 ac 91 c9 61 6b ..P...ak
24 80 d4 04 14 ea c2 83 $.......
d6 8a 31 78 d4 4f 6e 0a ..1x.On.
[EAP] 2005/05/08 20:14:46,750
***Timeout occured for negotiation with 000a95f620bc in phase 5
-->Retrying, this time with 1020 ms timeout...
-->EAPOL Header
Protocol Version : 1
Packet Type : Key
Packet Length : 127
Key Type : 254
-->802.11i RSN Key Descriptor
Key Information : Version 1 Group Key-Index 1 ACK MIC Secure Encrypted-Key-Data
Key Length : 32
Replay Counter : 0000000000000006
Nonce : 00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
Key IV : bd c7 d2 a5 b3 5b 6a 72 .....[jr
59 ad b5 39 c1 6e 59 bc Y..9.nY.
Key RSC : 01 00 00 00 00 00 00 00 ........
Key ID : 00 00 00 00 00 00 00 00 ........
Key MIC : 7c c4 11 96 fb 1d a6 4c |......L
43 80 a8 b7 b8 63 0f a6 C....c..
Key Data Length : 32
Key Data : 61 ab 03 ca 53 5a e8 74 a...SZ.t
16 ed 2c fb b5 86 e9 57 ..,....W
22 f5 e9 d7 3c 15 4e b5 "...<.N.
97 67 a1 b2 ec d7 38 02 .g....8.
[EAP] 2005/05/08 20:14:47,770
***Timeout occured for negotiation with 000a95f620bc in phase 5
-->Retrying, this time with 1020 ms timeout...
-->EAPOL Header
Protocol Version : 1
Packet Type : Key
Packet Length : 127
Key Type : 254
-->802.11i RSN Key Descriptor
Key Information : Version 1 Group Key-Index 1 ACK MIC Secure Encrypted-Key-Data
Key Length : 32
Replay Counter : 0000000000000007
Nonce : 00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
Key IV : 60 b7 2c de 30 5b 96 6f `.,.0[.o
f5 95 48 17 97 72 27 2b ..H..r'+
Key RSC : 01 00 00 00 00 00 00 00 ........
Key ID : 00 00 00 00 00 00 00 00 ........
Key MIC : 7f af 56 a0 e8 a3 8c e8 ..V.....
d4 2b dd ab be 5d 9f c5 .+...]..
Key Data Length : 32
Key Data : 93 14 f6 a8 be e1 90 37 .......7
bc 55 cd 53 61 0d ec 74 .U.Sa..t
e9 bb 25 7c 3e 3b b7 9a ..%|>;..
18 da f6 f7 c8 0b 0c 85 ........
.......
[EAP] 2005/05/08 20:15:05,110
***Timeout occured for negotiation with 000a95f620bc in phase 5
-->Maximum number of retries reached
-->Terminatimg session and deauthenticating client, better luck next time
[/size]
Was Tun?
Georg
1821 5.00
Hi Georg,
wir kommen nicht weiter.
Ich habe gestern mit einem PowerBook mit OS X 10.3 und einem iBook mit OS X 10.4 getestet. Die Geräte waren über das Apple-Online-Update auf dem aktuellsten Patchstand.
Als Gegenstellen fungierten ein 1821er und ein 1811er mit LCOS 4.02 bzw 4.12.
Als Resultat konnte ich nur feststellen, dass alles wie gewünscht geht.
Solange wir den Fehler nicht reproduzieren können, ist es sehr schwer hier von der LCOS-Seite her einen evtl. nötigen Fix vorzunehmen
Evtl. ist doch dein Apple schuld? Irgendetwas "zerschossen"
Da kann ich dir allerdings nicht mit eine Analyse dienen. So tief stecke ich in den "Raubtieren" nicht drin!
Ich habe auch mal in diversen Foren der Apple-User geschnüffelt und habe nur Aussagen mit dem Tenor gefunden: "Es geht" - Außer einer. die dürfte aber von dir stammen?!
Grüße
Gaaaz
wir kommen nicht weiter.
Ich habe gestern mit einem PowerBook mit OS X 10.3 und einem iBook mit OS X 10.4 getestet. Die Geräte waren über das Apple-Online-Update auf dem aktuellsten Patchstand.
Als Gegenstellen fungierten ein 1821er und ein 1811er mit LCOS 4.02 bzw 4.12.
Als Resultat konnte ich nur feststellen, dass alles wie gewünscht geht.
Solange wir den Fehler nicht reproduzieren können, ist es sehr schwer hier von der LCOS-Seite her einen evtl. nötigen Fix vorzunehmen

Evtl. ist doch dein Apple schuld? Irgendetwas "zerschossen"

Da kann ich dir allerdings nicht mit eine Analyse dienen. So tief stecke ich in den "Raubtieren" nicht drin!
Ich habe auch mal in diversen Foren der Apple-User geschnüffelt und habe nur Aussagen mit dem Tenor gefunden: "Es geht" - Außer einer. die dürfte aber von dir stammen?!

Grüße
Gaaaz
Hallo,
ich habe ebenfalls dieses Problem!
Lancom 1821 FW 4.02, jetzt 4.12, Apple Powerbook mit Airport Extreme erst unter OS X 10.3 jetzt unter 10.4.
Probleme mit dem Apple Rechner würde ich ausschließen, da es selbst nach Neuinstallation von 10.4 am letzten Wochenende nicht ging.
Ich habe auch schon einige Stunden mit ausprobieren verbracht und bin nie weiter gekommen. Fehlermeldung immer wieder: "Die angeforderte Verschlüsselungsmethode wird nicht unterstützt"
Wenn irgend welche Traces benötigt werden bin ich gerne bereit diese zu erstellen.
Gruß
Alfred
ich habe ebenfalls dieses Problem!
Lancom 1821 FW 4.02, jetzt 4.12, Apple Powerbook mit Airport Extreme erst unter OS X 10.3 jetzt unter 10.4.
Probleme mit dem Apple Rechner würde ich ausschließen, da es selbst nach Neuinstallation von 10.4 am letzten Wochenende nicht ging.
Ich habe auch schon einige Stunden mit ausprobieren verbracht und bin nie weiter gekommen. Fehlermeldung immer wieder: "Die angeforderte Verschlüsselungsmethode wird nicht unterstützt"
Wenn irgend welche Traces benötigt werden bin ich gerne bereit diese zu erstellen.
Gruß
Alfred
Zwei hab' ich noch:May 8 20:14:52 localhost kernel: AirPort: Link UP: "bitter" - 020b6b347ef0 - chan 1
May 8 20:14:52 localhost kernel: AirPort: Rx'd mesg P-1
May 8 20:14:52 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
May 8 20:14:52 localhost kernel: AirPort: Rx'd mesg P-3
May 8 20:15:12 localhost kernel: AirPort: Link DOWN
May 8 20:15:12 localhost kernel: handleAirPortChangesChannelWL fails because POWER IS OFF (the mask is correcty set however)
Schon mal versucht die Passphrase beim MAC in " (= Anführungszeichen) zu setzen?
@Georg:
Die oben zitierten Meldungen deines Kernels deuten darauf hin, das dein iBook die Airport-Karte nicht "richtig" (wieder) initialisieren konnte.
Nur so eine Idee: Versucht es doch bitte mal mit komplett abgeschaltetem Power-Management bei euren Äpfeln (danach bitte "richtig" (Cold Boot) neu Booten...)
Darüber hinaus gibt's div. Threads in Mac-Foren! Lösung war oft ein manuelles Resetten des PMUs:

Ohne Garantie!!! (d.h. du weißt was du tust!!!)

This happened on my laptop as well a year after i purchased it. Had to eventually reset the PMU, as well as Pram, Nvram, and also a Terminal command which involved:
"reset_all"
Worked fine thereafter....
Wie gesagt: "Fummeln" an PMU, Pram, Nvram etc. macht jeder in eigener Verantwortung!
Grüße
Gaaaz