WPA/WEP & 802.1X mit Apple Computer

[gschu]

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)

Zwei hab' ich noch:

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

Hallo Gaaaz,

Nochmals Danke.
Habe ach PMU NVRAM PRAM ... resetet, im MAX-Powermode mit Netzteil probiert - es nützt nix.

Fehler bleibt immer exakt derselbe, bis Phase 4 läuft, danach sendet 1821 das Phase 5 Paket (in 1000 Wiederholungen) an Apple, aber der fängt damit nix an sondern meldet Login-Fehler.

So wie ich es in den Foren/Beschreibungen lese ist diese PMU-Kiste eher dafür gedacht, wenn die Airport Karte garnix mehr sagt, oder?

Läge es am Passwort/Key träte der Fehler schon in Phase 2 auf, wie ich mal ausprobiert habe.

Status:
wie gehabt 1821-Powerbook mit WEP 128 geht, WPA-PSK nicht.
Aber Powerbook mit Zyxel 653HWI und Zynos 2 mit WPA-PSK geht, genau wie vorher WEP 128.

Da ich hier im Forum einer von 3en (siehe Alfred und raz) bin, bei denen LANCOM WLAN mit WPA nicht geht aber jeder es mit einem anderen Fabrikat an WLAN Routern geschafft hat, denke ich weiterhin es handelt sich um ein LANCOM Problem. Wie auch immer du es schaffst mit Power und iBook es hinzukriegen bleibt mir ein Rätsel.

Ich habe zusätzlich noch versucht den LANCOM auf USA zu stellen um zu sehen ob es an den Kanälen liegt - auch nix.

Ist es richtig, beim Apple wähle ich WLAN-Typ Persönlicher-WPA?

Könnte es sein das der Mac mit dem Key wie er in Phase 5 vom LANCOM kommt unzufrieden ist?


Georg

[alf29]

Könnte es sein das der Mac mit dem Key wie er in Phase 5 vom LANCOM kommt unzufrieden ist?

Das ist jetzt reines Rätselraten, dafür habe ich nicht die
Informationen, um da eine qualifizierte Aussage zu machen.

Um an dieser Stelle weiterzukommen, bräuchte ich
entweder so ein Gerät hier auf dem Entwicklertisch (wir
haben hier in der Firma so gut wie keine Macs...), oder
zumindest WLAN-Sniffer-Traces von einer
WPA-Verhandlung mit dem LANCOM, und dazu im
Vergleich die erfolgreiche Verhandlung mit dem von
Dir genannten ZyXEL. Dann könnte man eventuell
raten, was Deinem Mac nicht schmeckt...

Gruß Alfred

[Gaaaz]

Ich habe zusätzlich noch versucht den LANCOM auf USA zu stellen um zu sehen ob es an den Kanälen liegt - auch nix.

Ist es richtig, beim Apple wähle ich WLAN-Typ Persönlicher-WPA?

Könnte es sein das der Mac mit dem Key wie er in Phase 5 vom LANCOM kommt unzufrieden ist?

An den Kanälen liegt es sicher nicht. Ich hab' immer D eingestellt.
Persönlicher-WPA ist richtig.

Ich verstehe nicht, wieso das bei euch nicht geht.
Sichere dir doch mal deine Konfiguration vom LANCOM, resette ihn mal und probier dann noch mal von vorn ohne vorher was am Lancom zu konfigurieren. Also nur IP, Land und Kanal einstellen, dann WPA beim AP und Apfel konfigurieren. (Wen er resettet ist, stellt sich der Lancom automatisch auf WEP128; Schlüssel ist "L" + die LAN-Mac-Adresse)

Meine Test liefen immer bei recht "einfachen" Konfigurationen: Nur Internet-Provider und WLAN konfiguriert. Also keine "Spielereien" wie Cron-Jobs, VPN o.ä.

Wieso bei euren Äpfeln Phase5 nicht durchläuft ist ein Mysterium...
Ich hab es gestern bei Bekannten (die mit den MACs - Ich selbst habe keinen hier) in allen möglichen Kombinationen zwei Stunden probiert. Es lief einfach...

Viel Glück!

Gaaaz

[Alfred]

Hallo nochmal...

Ich habe mir heute einen L-54ag von der Arbeit mit nach Hause genommen und wieder etwas "rumprobiert".
FW 4.12, Gerät resettet und nur das notwendigste eingestellt.
Egal was ich versuche, wieder keine WPA-Verbindung!
Nur die Fehlermeldung am MAC ist jetzt nicht mehr "Das drahtlose Netzwerk unterstützt die gewünschte Verschlüsselungsmethode nicht", wie an meinem 1821 sondern "Beim Anmelden beim Airportnetzwerk XXXX ist ein Fehler aufgetreten".
Ich werde immer ratloser.

Schönen Abend noch

Alfred

[gschu]

Könnte es sein das der Mac mit dem Key wie er in Phase 5 vom LANCOM kommt unzufrieden ist?

Das ist jetzt reines Rätselraten, dafür habe ich nicht die
Informationen, um da eine qualifizierte Aussage zu machen.

Um an dieser Stelle weiterzukommen, bräuchte ich
entweder so ein Gerät hier auf dem Entwicklertisch (wir
haben hier in der Firma so gut wie keine Macs...), oder
zumindest WLAN-Sniffer-Traces von einer
WPA-Verhandlung mit dem LANCOM, und dazu im
Vergleich die erfolgreiche Verhandlung mit dem von
Dir genannten ZyXEL. Dann könnte man eventuell
raten, was Deinem Mac nicht schmeckt...

Gruß Alfred

Alfred,

danke fürs Hilfsangebot.

Also ich habe wie von Gaaaz empfohlen 1821 in Urzustand versetzt, eben kurz LAN konfiguriert. WEP128 geht wie immer.
Auf WPA umgestellt - wie gehabt nix.

Also mit KisMAC auf Netgear MA111 mitgehört was im WLAN rumfunkt.
Den DUMP im Ethereal angeguckt - ist lesbar.

Also hier ein Attachment was enthält:
a) simpel-konfig wie versucht
b) trace + eap + wlan von einem WPA Versuch
c) parallel pcap dump vom KisMAC während des Versuches

b) und c) von hinten lesen, Apple versucht, solange wie ich brauche um nach Aktivierung der WLAN Karte den PSK einzutippen, es mit Authentifizierung schon mal ....

Frage: Ist der pcap dump so okay? Ist er komplett?
Die MA111 kann nur 11b nicht 11g - spielt aber vermutlich bis dahin wo des Problem auftritt keine Rolle, oder?


Wenn diese Logs so brauchbar werde ich Zyxel wieder entsprechend konfigurieren und auch davon den LOG senden.

Danke an ALLE!

Georg

[gschu]

Hallo nochmal...

Ich habe mir heute einen L-54ag von der Arbeit mit nach Hause genommen und wieder etwas "rumprobiert".
FW 4.12, Gerät resettet und nur das notwendigste eingestellt.
Egal was ich versuche, wieder keine WPA-Verbindung!
Nur die Fehlermeldung am MAC ist jetzt nicht mehr "Das drahtlose Netzwerk unterstützt die gewünschte Verschlüsselungsmethode nicht", wie an meinem 1821 sondern "Beim Anmelden beim Airportnetzwerk XXXX ist ein Fehler aufgetreten".
Ich werde immer ratloser.

Schönen Abend noch

Alfred

Hallo Alfred,

erste Fehlermeldung ist typisch für AES aktiv - das kann Airport wohl nicht.
zweite Fehlermeldung ist das was ich immer sehe wenn es in Phase 5 scheitert. Da sind wir jetzt auf gleichem Stand ....


Georg

[alf29]

Moin,

danke für die Traces.

-->Received properly sequenced packet from supplicant for phase 2
-->Computing PTK
-->MIC failure, discarding

Ein MIC Failure bedeutet, daß auf beiden Seiten nicht das
gleiche PMK benutzt wurde, üblicherweise weil nicht die
gleiche Passphrase benutzt wurde. Wenn Du im gegenüber
dem zweiten Einbuchversuch in dem Trace nichts an der
Konfig Deines Macs geändert hast, dann läßt das schon
ziemliche Zweifel an der Qualität des Clients aufkommen...

Und dann am Ende:

-->802.11 Management Frame:
Reason : Disassociated because sending station is leaving (has left) BSS

Hm, das ist aber etwas anders. Hier hat sich Dein Client
in der Schlüsselverhandlung selber wieder abgemeldet,
das LANCOM hat von sich aus die Verhandlung (noch)
nicht abgebrochen...

In dem Capture-File fehlen leider die EAP-Pakete, die
zwischen AP und Client laufen - das wäre der interessante
Teil gewesen...

Gruß Alfred

[gschu]

Moin,

danke für die Traces.

-->Received properly sequenced packet from supplicant for phase 2
-->Computing PTK
-->MIC failure, discarding

Ein MIC Failure bedeutet, daß auf beiden Seiten nicht das
gleiche PMK benutzt wurde, üblicherweise weil nicht die
gleiche Passphrase benutzt wurde. Wenn Du im gegenüber
dem zweiten Einbuchversuch in dem Trace nichts an der
Konfig Deines Macs geändert hast, dann läßt das schon
ziemliche Zweifel an der Qualität des Clients aufkommen...

das ist der Teil von dem ich schrieb wo der Apple zunächst versucht reinzukommen ohne dass ich die Passphrase beim Prompt schon vollständig eingetippt habe -> kann man getrost ignorieren - ausser dies brächte den 1821 ausser Takt. Damit das geprüft werden kann habe ich es drin gelassen.

Es gibt später noch einen Einstieg in die richtige Key-Verhandlung, da geht es dann wie immer sauber durch die Phasen 1 bis 4.

Und dann am Ende:

-->802.11 Management Frame:
Reason : Disassociated because sending station is leaving (has left) BSS

Hm, das ist aber etwas anders. Hier hat sich Dein Client
in der Schlüsselverhandlung selber wieder abgemeldet,
das LANCOM hat von sich aus die Verhandlung (noch)
nicht abgebrochen...

Da kommen sonst endlos Phase 5 Pakete vom LANCOM auf die der Apple nicht reagiert, bzw. wo der LANCOM keine Antwort sieht und mit TimeOut wiederholt.
Sehen alle mehr oder weniger gleich aus, Timeout 1020ms ...
Habe ich durch abschalten der Airport Karte beendet, damit das Trace nicht endlos wird.

In dem Capture-File fehlen leider die EAP-Pakete, die
zwischen AP und Client laufen - das wäre der interessante
Teil gewesen...

Gruß Alfred

Fehlende EAP-Pakete ist ja doof, könnte es an 11g(54Mbit) liegen?
Werde versuchen die EAPs zu capturen. Kann ich den 1821 dafür besser einstellen?

Danke
Georg

[alf29]

Fehlende EAP-Pakete ist ja doof, könnte es an 11g(54Mbit) liegen?
Werde versuchen die EAPs zu capturen. Kann ich den 1821 dafür besser einstellen?

Allerdings...Stelle das 1821 für den Test einfach auf b-only.

Gruß Alfred

[gschu]

Fehlende EAP-Pakete ist ja doof, könnte es an 11g(54Mbit) liegen?
Werde versuchen die EAPs zu capturen. Kann ich den 1821 dafür besser einstellen?

Allerdings...Stelle das 1821 für den Test einfach auf b-only.

Gruß Alfred

gemacht,
und hier ist jetzt das gleiche Spiel mit EAP!

Leider - ich habe vergessen auf dem 1821 mit WLAN-Trace Maske zu 000000000000 den Trace für WLAN zu ermöglichen (ist wohl ein Fehler in der 1821 4.12er).
Und da ich erst die simpel-config in den 1821 lade ist das jedes mal wieder nötig ....
(Kann ich das zu Fuss in der lcf ändern indem ich
1.2.12.102 = 000000000010 auf = 0000000000000 ändere?)

Wenn auf jeden Fall benötigt, muss ich ein weiteres mal die Runde laufen lassen um den WLAN log auf 1821 auch zu haben.


Wie gehabt von hinten lesen.
Datum/Zeit: mit simpelkonfig kann ich keinen ntp/isdn update, die Zeiten sind daher nicht im sync.
Gestartet:
1) WLAN sniff
2) 1821 trace
3) WLAN Verbindung auf Apple.

Vom Apple sind diesmal auch Ausschnitte aus conole.log und system.log dabei.


Der Apple versucht immer einen automatischen unverschlüsselten login in vorhandene WLANs, sobald eine WLAN Karte aktiv wird. Apple versteht das als Komfort-Funktion für öffentliche APs - uns müllt das leider wieder die Sniffer Logs zu.

Auch hier wieder von hinten nach vorne - es endet mit dem Timeout von WPA. Der andere Kram am Anfang des Sniffs ist oben beschriebener Müll.

Ich habe es diesmal solange laufen lassen bis der 1821 Trace selbst das Ende mit "... better luck next time ... " meldet.


Hoffe so ist sinnvoll, wenn ja kommt Zyxel sniff asap.


Georg

[alf29]

Moin,

so wie das aussieht, antwortet der Apple gar nicht auf das
Paket 5. Da WLAN-ACKs kommen, hat er sie
(wahrscheinlich) auch entschlüsseln können, und danach
irgendwo im Supplicant verworfen. Das Problem ist jetzt, daß
dieser Teil schon verschlüsselt läuft und wir nicht mehr
reinschauen können, wie das Paket 5 beim ZyXEL
aufgebaut ist. Die einzige Idee, die ich da habe, wäre das
LANCOM als Client(!) zu konfigurieren und sich gegen
den ZyXEL einbuchen zu lassen. Dann könnte man im
WLAN/EAP-Trace des LANCOM im Klartext sehen, was
für ein Paket der ZyXEL schickt.

Das mit der Trace-MAC ist eine doppelt vergebene SNMP-
Id in der 4.12. Für Kunden, die damit ein echtes Problem
haben, gibt's eine Firmware 4.14 auf Anfrage.

Gruß Alfred

[gschu]

Moin,

so wie das aussieht, antwortet der Apple gar nicht auf das
Paket 5. Da WLAN-ACKs kommen, hat er sie
(wahrscheinlich) auch entschlüsseln können, und danach
irgendwo im Supplicant verworfen. Das Problem ist jetzt, daß
dieser Teil schon verschlüsselt läuft und wir nicht mehr
reinschauen können, wie das Paket 5 beim ZyXEL
aufgebaut ist. Die einzige Idee, die ich da habe, wäre das
LANCOM als Client(!) zu konfigurieren und sich gegen
den ZyXEL einbuchen zu lassen. Dann könnte man im
WLAN/EAP-Trace des LANCOM im Klartext sehen, was
für ein Paket der ZyXEL schickt.

Das mit der Trace-MAC ist eine doppelt vergebene SNMP-
Id in der 4.12. Für Kunden, die damit ein echtes Problem
haben, gibt's eine Firmware 4.14 auf Anfrage.

Gruß Alfred

Schöne Pfingsten ...

Hier der WLAN Trace wenn LANCOM sich als Client an den Zyxel per WPA-PSK anmeldet ...
läuft einfach!


TRACE + EAP wird im Client Modus nicht angezeigt. Benötigt? Bug/Feature?


Wenn wir noch weiter an den Geräten basteln und weiter WLAN Tracen wollen wäre schon schön nicht jedes mal zu Fuss den Setup ändern zu müssen. Ansonsten ich warte gerne - am liebsten auf ne Firmware die dann auch Appelt.

Schöne Feiertage

Danke für die Unterstützung

Georg

[alf29]

Moin,

TRACE + EAP wird im Client Modus nicht angezeigt. Benötigt? Bug/Feature?

Hm, ist doch drin (die mit [EAP] gekennzeichneten Meldungen)?

Das einzige, was mir so auf die Schnell auffällt, ist
daß der ZyXEL das Encrypted-Key-Data-Feld in Paket
5 nicht setzt. Das Bit zeigt nochmal explizit an, daß
an dem Paket ein verschlüsselter Schlüssel (jawoll...)
anhängt, ist nur relativ spät im 11i-Standard eingebaut
worden.

Man könnte mal probeweise dieses Bit nicht setzen...

Gruß Alfred

[gschu]

Moin,

Hm, ist doch drin (die mit [EAP] gekennzeichneten Meldungen)?

stimmt, da war ich wohl ziemlich blind, vor lauter WLAN Meldungen die EAPs übersehen.

Das einzige, was mir so auf die Schnell auffällt, ist
daß der ZyXEL das Encrypted-Key-Data-Feld in Paket
5 nicht setzt. Das Bit zeigt nochmal explizit an, daß
an dem Paket ein verschlüsselter Schlüssel (jawoll...)
anhängt, ist nur relativ spät im 11i-Standard eingebaut
worden.

Man könnte mal probeweise dieses Bit nicht setzen...

Gruß Alfred

Wir schliessen hier ja indirekt - Apple kann mit Zyxel aber nicht mit LANCOM.
Also gucken was Zyxel anders als LANCOM macht. Dann LANCOM testweise umstricken zu gleich/ähnlich wie Zyxel und gucken ob es das war was Apple hindert mit LANCOM zu spielen. Echtes Trial und Error/Success.
Der Versuch ist es auf jeden Fall wert - und wenn nur um zu sehen ob es klappt. Wenn Apple neben der Norm liegt ist Apple dran da was zu fixen.


Feierabend


Georg

[Casey]

Das mit der Trace-MAC ist eine doppelt vergebene SNMP-
Id in der 4.12. Für Kunden, die damit ein echtes Problem
haben, gibt's eine Firmware 4.14 auf Anfrage.

Ist in der Firmware auch der Bugfix für Putty 0.58 integriert oder nur das SNMP Problem behoben worden?