Radius: Disconnect messages nach RFC 5176

[Bernie137]

Hallo,

wir verwenden verschiedenste APs (L54g, L310, L822acn usw.) für Gastnetzwerke in mehreren Filialen zur Authentifizierung über einen zentralen Radius Server per EAP-PEAP, TekRadius. Das funktioniert auch alles prima.
Nun soll die Lösung erweitert werden, indem die User zeitlich pro Tag limitiert werden. Dazu bietet der Radius Server die notwendigen Attribute an, aber es ergeben sich bei ersten Tests Probleme. Hat man ein Kontingent von 4 Stunden und man schaltet am Smartphone das WLAN nach einer halben Stunde ab, würden noch 3,5h verbleiben. Aber im Radius Server tickt die Uhr weiter runter. Zweites Problem, beim Verlassen der WLAN Reichweite bleiben Smartphones häufig auch eingebucht.

Jetzt kommt die konkrete Lancom Frage. Der Support des Tekradius fragt, ob die APs "disconnect messages nach RFC 5176" senden. Mich würde es wundern, wenn die Lancom APs das nicht könnten. Ich vermute eher, dass ich in der Config noch etwas einstellen muß, nur was? Hat da jemand einen heißen Tipp für mich?

Eine Besonderheit hat die Konfiguration in allen APs: Alle Radius- und Accountingmeldungen werden zunächst an den lokalen AP-eigenen LCOS Radius Server geschickt. Der AP-Radius Server schickt dann stellvertretend die Meldungen per Weiterleitung an den zentralen Radius. Vielleicht bringt das ein Problem mit sich. Gemacht wurde das deshalb so, weil bei direkter Ansprache des zentralen Radius nicht alle Accounting Infos ankamen wie z.B. "Framed_IP_Address" - dieses Feld blieb immer leer und es wurde nie die Client IP-Adresse aufgezeichnet.

Gruß Bernie

[alf29]

Nun soll die Lösung erweitert werden, indem die User zeitlich pro Tag limitiert werden. Dazu bietet der Radius Server die notwendigen Attribute an, aber es ergeben sich bei ersten Tests Probleme. Hat man ein Kontingent von 4 Stunden und man schaltet am Smartphone das WLAN nach einer halben Stunde ab, würden noch 3,5h verbleiben. Aber im Radius Server tickt die Uhr weiter runter. Zweites Problem, beim Verlassen der WLAN Reichweite bleiben Smartphones häufig auch eingebucht.

Also wenn das Smartphone ausgeschaltet wird oder der Benutzer einfach weggeht, dann ist die WLAN-Verbindung aber früher oder später beendet, entweder nach dem Idle-Timeout (der ist im WLAN einstellbar) oder wenn man die Stationsüberwachung einschaltet, nach einer Minute. Hat man RADIUS-Accounting im WLAN an, dann geht damit auch ein Accounting-Stop raus.

Jetzt kommt die konkrete Lancom Frage. Der Support des Tekradius fragt, ob die APs "disconnect messages nach RFC 5176" senden. Mich würde es wundern, wenn die Lancom APs das nicht könnten. Ich vermute eher, dass ich in der Config noch etwas einstellen muß, nur was? Hat da jemand einen heißen Tipp für mich?

Wenn ich den RFC auf die Schnelle richtig überflogen habe, geht es da um CoA, d.h. der RADIUS-Server schickt einen Disconnect Request an den AP, nicht umgekehrt. Und das würde in dem Fall doch nichts nutzen, so eine Nachricht würde der RADIUS-Server erst dann schicken, wenn die ganzen vier Stunden abgelaufen sind?

CoA im WLAN steht auf der PM-Wunschliste, ich kann Dir aber nicht sagen, wann das mal hinreichend hoch auf dem Scrum-Board wandert. Und wie gesagt, ich denke nicht, daß das die Lösung Deines Problems ist.

Eine Besonderheit hat die Konfiguration in allen APs: Alle Radius- und Accountingmeldungen werden zunächst an den lokalen AP-eigenen LCOS Radius Server geschickt. Der AP-Radius Server schickt dann stellvertretend die Meldungen per Weiterleitung an den zentralen Radius. Vielleicht bringt das ein Problem mit sich. Gemacht wurde das deshalb so, weil bei direkter Ansprache des zentralen Radius nicht alle Accounting Infos ankamen wie z.B. "Framed_IP_Address" - dieses Feld blieb immer leer und es wurde nie die Client IP-Adresse aufgezeichnet.

Der Accounting-Start aus dem WLAN kommt in dem Moment, in dem der Client in den Zustand 'Connected' wechselt, d.h. wenn 1X-Verhandlung und WPA-Handshake durch sind. Zu dem Zeitpunkt hat der Client noch keine IP-Adresse, weil er mit der DHCP-Verhandlung erst anfangen kann, wenn er Datenpakete übertragen kann. Das WLAN-RADIUS-Accounting wird aber einen Interim-Update schicken, sobald es eine Client-IP ermittelt hat. Einen Zusammenhang mit Umleiten der RADIUS-Anfragen über den internen RADIUS-Server sehe ich nicht - wo keine Framed-IP-Address da ist, da kann der RADIUS-Server auch keine aus dem Hut zaubern...

Wenn ich's richtig im Kopf habe, dann hat LCOS 9.20 im WLAN-RADIUS-Accounting eine Option, den Accounting-Start auf dem Zeitpunkt zu verzögern, wo der AP eine IP-Adresse für den Client ermittelt hat. Müßte an der gleichen Stelle in den Netzwerkeinstellungen sein, wo auch der RADIUS-Server fürs Accounting konfiguriert wird. Für den Fall, daß Dein RADIUS-Server ein Problem damit hat, daß die Adresse erst mit einem Interim-Update kommt...

Gruß Alfred

[Bernie137]

Hallo Alfred,

vielen Dank für Deine Antwort.
Zunächst zur fehlenden "Framed_IP_Address".

Einen Zusammenhang mit Umleiten der RADIUS-Anfragen über den internen RADIUS-Server sehe ich nicht - wo keine Framed-IP-Address da ist, da kann der RADIUS-Server auch keine aus dem Hut zaubern...

Das stimmt wohl. Ich konnte die Konfiguration jetzt abändern, dass der AP nun direkt mit dem Radius spricht (vorab, das ändert leider nichts am eigentlichen Problem mit dem Tageslimit). Es gibt am AP zwei Netz, einmal das verwaltungsnetz und dann das Gastnetz per VLAN getrennt. Nun kann man beim Radius/Accounting-Server eine Absende-Adresse hinterlegen. Ich habe diese entfernt und siehe da, die Framed_IP_Address kommt im Radius an. Schon mal Danke!

Also wenn das Smartphone ausgeschaltet wird oder der Benutzer einfach weggeht, dann ist die WLAN-Verbindung aber früher oder später beendet, entweder nach dem Idle-Timeout (der ist im WLAN einstellbar) oder wenn man die Stationsüberwachung einschaltet, nach einer Minute.

Idle-Timeout stand auf 3600 (ich nehme an Sekunden = 1h). Habe es auf 120 Sekunden runter gesetzt, Stationsüberwachung ist an.

Hat man RADIUS-Accounting im WLAN an, dann geht damit auch ein Accounting-Stop raus.

Nach weiteren Test, ja das kann ich bestätigen. Und anders als ich erst oben schrieb, begreift das der Radius Server auch richtig. Sorry, dass ich hier eine falsche Fährte gelegt habe.

Aber, was jedenfalls nicht funktioniert: Bleibt der Client eingebucht und in Reichweite tickt die Uhr runter auf 0 und dann in den negativen Bereich. Und mein Gefühl sagt, dass muss an dem Radius Server liegen. Im Log des Radius sind wünderschön die "Acct-Status-Type = Checkpoint" Meldungen zu sehen, die brav der AP schickt. Mehr muss doch der AP nicht tun, oder?

geht es da um CoA

Wenn ich es richtig verstanden habe, wurde genau danach gefragt.

Und das würde in dem Fall doch nichts nutzen, so eine Nachricht würde der RADIUS-Server erst dann schicken, wenn die ganzen vier Stunden abgelaufen sind?

Klingt nach meinem zuvor geschilderten Fall. Also müsste ich untersuchen, ob der Radius beim Erreichen der Zeit eine Meldung an den AP rausschickt?

CoA im WLAN steht auf der PM-Wunschliste

OK. Aber vielleicht hat es damit gar nichts zu tun. Denn benutzt man den internen Lancom Radius, würde es ja auch funktionieren mit einem zeitlichen Kontingent. Irgendwie stehe ich gerade auf dem Schlauch bei der Ergründung der Sache.

Gruß Bernie

[alf29]

Moin,

Das stimmt wohl. Ich konnte die Konfiguration jetzt abändern, dass der AP nun direkt mit dem Radius spricht (vorab, das ändert leider nichts am eigentlichen Problem mit dem Tageslimit). Es gibt am AP zwei Netz, einmal das verwaltungsnetz und dann das Gastnetz per VLAN getrennt. Nun kann man beim Radius/Accounting-Server eine Absende-Adresse hinterlegen. Ich habe diese entfernt und siehe da, die Framed_IP_Address kommt im Radius an. Schon mal Danke!

Da sehe ich ehrlich gesagt immer noch keinen ursächlichen Zusammenhang. Die Absende-IP-Adresse bestimmt bei mehreren möglichen Routen zum RADIUS-Server nur, über welche Route (und damit, mit welcher Quell-IP-Adresse im IP-Header) der AP seine Requests verschickt. Das hat nur einen Einfluß auf das Attribut 'NAS-IP-Address', also die IP-Adresse des APs selber, aber nicht auf die des Clients, also das Attribut 'Framed-IP-Address'. Als Framed-IP-Address setzt der WLAN-Stack einfach die IP-Adresse ein, die Du auch für den Client in der WLAN-Stationstabelle siehst. Eventuell stand die beim zweiten Versuch einfach da noch von der ersten Anmeldung des Clients drin, bei einer (Wieder-)Anmeldung werden nicht alle Daten eines Clients in der Stationstabelle gelöscht.

Aber, was jedenfalls nicht funktioniert: Bleibt der Client eingebucht und in Reichweite tickt die Uhr runter auf 0 und dann in den negativen Bereich. Und mein Gefühl sagt, dass muss an dem Radius Server liegen. Im Log des Radius sind wünderschön die "Acct-Status-Type = Checkpoint" Meldungen zu sehen, die brav der AP schickt. Mehr muss doch der AP nicht tun, oder?

Also RADIUS (also *ohne* CoA) ist erstmal ein Protokoll, wo alle Anfragen nur in eine Richtung laufen. Der NAS (also hier der AP) fragt 'Darf dieser Client rein' und der RADIUS-Server sagt 'ja' oder 'nein' (ist bei 1X etwas komplizierter, ist für dieses Thema aber erstmal egal). Beim RADIUS-Accounting meldet der NAS die verbrauchten Resourcen und der RADIUS-Server sagt entweder 'OK, ich hab's vermerkt' oder 'nein, ich kriege es nicht gespeichert'. Der RADIUS-Server kann auf einen Accounting-Request nicht mit einem "Jetzt ist's aber genug" antworten - das ist im Protokoll schlicht nicht vorgesehen. Der RADIUS-Server kann nur folgendes tun:

(1) In dem RADIUS-Accept ein Session-Timeout-Attribut mitschicken, d.h. eine Zeit, nach der die Session des Clients spätestens enden soll. Dieses Zeitlimit überwacht dann der NAS eigenständig. Das Public-Spot-Modul macht das zum Beispiel, da schickt der RADIUS-Server im LCOS das konfigurierte Zeitkontingent, abzüglich bereits accounteter Zeit aus früheren Sessions, als Session-Timeout an die Public-Spot-Option. Beim Betrieb ohne Public Spot (das machtst Du doch, oder?) mit 1X-Authentisierung gibt es prinzipiell auch einen Session-Timeout im RADIUS-Accept, und der bedeutet, je nachdem wie das Termination-Action-Attribut gesetzt ist entweder, daß eine 802.1X-Reauthentisierung angestoßen werden soll oder daß der Client rausgeworfen werden soll. Und bevor Du's probierst: Nein, Termination-Action=Default (also Client rauswerfen) ist im WLAN-Stack im LCOS aktuell nicht implementiert...

(2) RADIUS-Server und NAS unterstützen beide CoA, d.h. der RADIUS-Server kann umgekehrt an den AP Requests schicken, z.B. einen Disconnect Request. Fällt mangels CoA im WLAN-Stack aktuell auch flach...

Die einzige Möglichkeit, die ich sehe, ist im RADIUS-Accept einen Session-Timeout und eine Termination-Action=RADIUS-Request zu schicken. Der AP wird nach dieser Zeit dann eine 1X-Reauthentisierung anstoßen, und Deinem RADIUS-Server mußt Du beibiegen, daß er den Benutzer ablehnt, wenn sein Zeitkontingent erschöpft ist.

Klingt nach meinem zuvor geschilderten Fall. Also müsste ich untersuchen, ob der Radius beim Erreichen der Zeit eine Meldung an den AP rausschickt?

Selbst wenn er das tut, es gibt im WLAN-Stack vom LCOS aktuell niemanden, der auf so eine Meldung hören würde - mangels CoA-Support...

OK. Aber vielleicht hat es damit gar nichts zu tun. Denn benutzt man den internen Lancom Radius, würde es ja auch funktionieren mit einem zeitlichen Kontingent.

Mit reinem 1X zur Authentisierung und reinem WLAN-RADIUS-Accounting würde das auch mit dem RADIUS-Server im LCOS nicht funktionieren. Vielleicht würde der RADIUS-Server im LCOS im Accept noch einen Session-Timeout mit der Restzeit zurückschicken (da wäre ich mir aber nicht sicher, das kollidiert mit einer konfigurierten Reauth-Periode). aber der WLAN-Stack würde damit genauso wenig etwas anfangen. Es gibt an der WLAN-Stationtabelle einfach schlicht kein Attribut, daß ein Client nach einer bestimmten Zeit rausgeworfen werden soll.

Gruß Alfred

[Bernie137]

Hallo Alfred,

vielen Dank für Deine Erklärungen.

Da sehe ich ehrlich gesagt immer noch keinen ursächlichen Zusammenhang. Die Absende-IP-Adresse bestimmt bei mehreren möglichen Routen zum RADIUS-Server nur, über welche Route (und damit, mit welcher Quell-IP-Adresse im IP-Header) der AP seine Requests verschickt.

Was Du nicht wissen kannst, der Radius ist nur übers Verwaltungsnetz erreichbar. Wenn beispielsweise als Absende-Netz das Gastnetz drin ist funktioniert es nicht wie gewünscht. Außerdem teste ich gerade mit einem L-54g und der hat ja kein aktuelles LCOS, vielleicht war da das Verhalten auch noch anders. Ich würde es an der Stelle aber auch nicht vertiefen wollen.

Beim Betrieb ohne Public Spot (das machtst Du doch, oder?)

Ja korrekt, ohne Public Spot. Es sind Active Directory Benutzerkonten.

Die einzige Möglichkeit, die ich sehe, ist im RADIUS-Accept einen Session-Timeout und eine Termination-Action=RADIUS-Request zu schicken. Der AP wird nach dieser Zeit dann eine 1X-Reauthentisierung anstoßen

Ich nehme an, dass ist kein RFC Standard? Ich werde mal anfragen, habe aber wenig Hoffnung da auf CoA verwiesen wird.

und Deinem RADIUS-Server mußt Du beibiegen, daß er den Benutzer ablehnt, wenn sein Zeitkontingent erschöpft ist.

Für den Fall eines vorherigen Accounting-Stop funktioniert das auch.

Mit reinem 1X zur Authentisierung und reinem WLAN-RADIUS-Accounting würde das auch mit dem RADIUS-Server im LCOS nicht funktionieren.

Stimmt, ich habe es gerade probiert. Ist das gleiche Verhalten wie mit dem tekRadius. Da bin ich platt, das hätte ich jetzt nicht erwartet. Schließlich suggeriert die Radius-Benutzertabelle da einen anderen Eindruck mit Zeit-Budget und Relativer Ablauf.

Gruß Bernie

[alf29]

Moin,

Ich nehme an, dass ist kein RFC Standard? Ich werde mal anfragen, habe aber wenig Hoffnung da auf CoA verwiesen wird.

Doch, dieser Mechanismus ist in RFC 3580 beschrieben, der sich um die Verwendung von RADIUS-Attributen für 802.1X dreht.

Stimmt, ich habe es gerade probiert. Ist das gleiche Verhalten wie mit dem tekRadius. Da bin ich platt, das hätte ich jetzt nicht erwartet. Schließlich suggeriert die Radius-Benutzertabelle da einen anderen Eindruck mit Zeit-Budget und Relativer Ablauf.

Diese Felder sind alle sehr stark auf die Benutzung zusammen mit der Public-Spot-Option ausgerichtet. Wenn nächste Woche mein Urlaub vorbei ist (und ich mich durch zweieinhalb Wochen Mails gewühlt habe) werde ich mal ein oder zwei Features formulieren. Ich glaube aber nicht, daß sie besonders hohe Prio bekommen werden.

Gruß Alfred

[Bernie137]

Hallo Alfred,

vielen Dank für Deine Tipps. Ich habe ein Update für den Radius bekommen, welches nun offenbar Session-Timeout's und Termination-Action=RADIUS-Request's schickt. Nun funktioniert es mit dem L54g und einem iPhone prima, jedoch bockt es weitherhin genauso mit dem Androiden, obwohl gleicher AP und gleiche Einstellungen. Was sollte ich da noch untersuchen?
Morgen bringt mir der Kollege noch ein neueres Androidenteil mit, aber ich habe da nicht viel Hoffnung.

Wenn nächste Woche mein Urlaub vorbei ist (und ich mich durch zweieinhalb Wochen Mails gewühlt habe) werde ich mal ein oder zwei Features formulieren.

Einen Versuch als Feature ist es wert und der Urlaub war/sei Dir gegönnt. Danke, dass Du in der Zeit trotzdem geantwortet hast.

Gruß Bernie

Code: Alles auswählen

[EAP] 2016/09/05 16:13:10,894  Devicetime: 2016/09/05 16:13:19,440
EAP: RX <- 10.10.10.38:1812 - received EAP frame from RADIUS server
EAP:   (80) Message-Authenticator = ...
EAP:   (27) Session-Timeout       = 30
EAP:   (24) State                 = 37 64 63 33 35 35 37 61 61 65 35 63 38 61 36 66 63 64 65 38 32 32 64 37 66 38 62 32 31 62 62 66
EAP:   (79) EAP-Message[Len=107]  = 01 08 00 6b 19
EAP:   Packet Type = Access-Challenge

Code: Alles auswählen

[EAP] 2016/09/05 16:13:10,974  Devicetime: 2016/09/05 16:13:19,500
EAP: RX <- 10.10.10.38:1812 - received EAP frame from RADIUS server
EAP:   (27) Session-Timeout       = 16
EAP:   (29) Termination-Action    = 1
EAP:   (28) [Len=4]               = 00 00 02 58
EAP:   (01) User-Name             = "test.user"
EAP:   (26) MS-MPPE-RECV-KEY      = d4 b3 ad 77 f8 71 47 e5
EAP:                              = aa 25 14 dc 26 d0 54 e0
EAP:                              = d8 75 d0 89 9b 4b 00 a9
EAP:                              = 6b c8 be d5 ed 13 f6 e2
EAP:   (26) MS-MPPE-SEND-KEY      = 2c 1b ce 00 d1 be 45 25
EAP:                              = 98 63 f5 d3 75 e1 5a e5
EAP:                              = e1 06 81 07 66 ed 1d aa
EAP:                              = 27 3f eb 7f c6 04 59 af
EAP:   (80) Message-Authenticator = ...
EAP:   (79) EAP-Message[Len=4]    = 03 09 00 04
EAP:   Packet Type = Access-Accept

[alf29]

Moin,

OK, da ist eine Termination-Action und ein Session-Timeout drin, das LANCOM sollte nach den 16 Sekunden also eigentlich eine neue 1X-Verhandlung anstoßen, das sollte man im EAP-Trace sehen.

Was mit dem Androiden sein könnte? Es gibt Clients, die nicht auf 1X-Reauthentisierungen reagieren, und ich erinnere mich dunkel, daß ältere LCOS-Versionen (so wie in einem L-54) dann schlicht 'dann eben nicht' gesagt haben und die Session mit den alten Schlüsseln weiterlief. Daß so eine Verweigerung seitens des Clients wie ein Fail gewertet wird, ist - meine ich - erst später reingekommen. Muß ich in den nächsten Tagen mal nachprüfen.

Gruß Alfred

[Bernie137]

Hallo Alfred,

ich habe Neugikeiten in der Sache.

Was mit dem Androiden sein könnte? Es gibt Clients, die nicht auf 1X-Reauthentisierungen reagieren, und ich erinnere mich dunkel, daß ältere LCOS-Versionen (so wie in einem L-54) dann schlicht 'dann eben nicht' gesagt haben und die Session mit den alten Schlüsseln weiterlief. Daß so eine Verweigerung seitens des Clients wie ein Fail gewertet wird, ist - meine ich - erst später reingekommen. Muß ich in den nächsten Tagen mal nachprüfen.

Ich teste nun mit einem L-822acn, LCOS 9.20.0683RU2 und einem anderen Android Smartphone Samsung Galaxy S5 - es bleibt aber bei dem Problem. Der AP kickt das Smartphone nicht raus, leider

Kannst Du mir die Frage aller Fragen beantworten: Liegt es nun an dem Radius Server oder am AP oder an beiden? Ich möchte gerne mit den Erkenntnisse von hier noch einmal an den Radius Hersteller heran treten.

Nun ein paar Details in Form von Traces (Auszug/ EAP, Radius-Server und Radius-Client) im Vergleich zum iPhone:

1. iPhone

Code: Alles auswählen

[RADIUS-Server] 2016/09/14 10:27:06,402  Devicetime: 2016/09/14 10:27:05,072
Checking for dead accounting sessions:
[EAP] 2016/09/14 10:27:25,200  Devicetime: 2016/09/14 10:27:24,080
***Rekeying operation started for negotiation with f0:cb:a1:7e:bc:eb (Apple 7e:bc:eb)
-->Restarting key handshake and send first packet
-->EAPOL Header
Protocol Version    : 2
Packet Type         : Key
Packet Length       : 117
Key Type            : 2
-->802.11i RSN Key Descriptor
Key Information     : Version 2 Pairwise Key-Index 0 ACK
Key Length          : 16
Replay Counter      : 0000000000000003
Nonce               : f4 4e ec c4 0c b9 2b 30 .N....+0
                      aa 0b 5a 0d 4f 2d 4d 76 ..Z.O-Mv
                      c2 46 da f9 20 51 a7 cb .F.. Q..
                      b2 36 c0 f9 7b 93 a4 b3 .6..{...
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     : 22
Key Data            :
<<<
PMKID               : 1e c7 1c 79 c2 63 73 4a ...y.csJ
                      2c 9e 36 29 9e e3 44 29 ,.6)..D)
>>>
[EAP] 2016/09/14 10:27:25,200  Devicetime: 2016/09/14 10:27:24,082
***Received EAP packet on WLAN-1-2:
-->EAPOL Header
Protocol Version    : 2
Packet Type         : Key
Packet Length       : 117
Key Type            : 2
-->802.11i RSN Key Descriptor
Key Information     : Version 2 Pairwise Key-Index 0 MIC
Key Length          : 16
Replay Counter      : 0000000000000003
Nonce               : c7 33 c6 67 66 7b 98 48 .3.gf{.H
                      c2 41 12 08 df 76 08 97 .A...v..
                      bb 44 b4 4a bb 5d b5 df .D.J.]..
                      51 04 10 4e 04 e8 b1 7d Q..N...}
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             : 29 83 9a 4d 6c ff 06 f4 )..Ml...
                      78 39 20 ab 5c d4 21 ef x9 .\.!.
Key Data Length     : 22
Key Data            :
<<<
RSN Cipher Info     : Version 1
                      Group Cipher TGI-CSE-CCM
                      Pairwise Ciphers TGI-CSE-CCM
                      Authentication Selectors TGI-802.1x-UNSPEC
                      Capabilities: 16 PTKSA replay counters 1 GTKSA replay counters
>>>
-->Received properly sequenced packet from supplicant for phase 2
-->Computing PTK
  -->PRF-X Data:
00: 02 a0 57 25 08 41 f0 cb - a1 7e bc eb c7 33 c6 67
10: 66 7b 98 48 c2 41 12 08 - df 76 08 97 bb 44 b4 4a
20: bb 5d b5 df 51 04 10 4e - 04 e8 b1 7d f4 4e ec c4
30: 0c b9 2b 30 aa 0b 5a 0d - 4f 2d 4d 76 c2 46 da f9
40: 20 51 a7 cb b2 36 c0 f9 - 7b 93 a4 b3
  -->Resulting PTK:
00: 24 01 3e 73 ff 46 4d cb - a9 88 ce 1e 74 70 10 0d
10: ca a3 6a fa 45 03 54 43 - bf 7a f8 6e 2e 4d ad e6
20: 63 70 f0 cc 72 24 2c d0 - fe 5f 12 91 13 3f d9 ed
  -->KCK:
00: 24 01 3e 73 ff 46 4d cb - a9 88 ce 1e 74 70 10 0d
  -->KEK:
00: ca a3 6a fa 45 03 54 43 - bf 7a f8 6e 2e 4d ad e6
  -->TK:
00: 63 70 f0 cc 72 24 2c d0 - fe 5f 12 91 13 3f d9 ed
-->Switching to pairwise key handshake phase 3, send corresponding packet
-->EAPOL Header
Protocol Version    : 2
Packet Type         : Key
Packet Length       : 151
Key Type            : 2
-->802.11i RSN Key Descriptor
Key Information     : Version 2 Pairwise Key-Index 0 Install ACK MIC Secure Encrypted-Key-Data
Key Length          : 16
Replay Counter      : 0000000000000004
Nonce               : f4 4e ec c4 0c b9 2b 30 .N....+0
                      aa 0b 5a 0d 4f 2d 4d 76 ..Z.O-Mv
                      c2 46 da f9 20 51 a7 cb .F.. Q..
                      b2 36 c0 f9 7b 93 a4 b3 .6..{...
Key IV              : 00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
Key RSC             : 04 00 00 00 00 00 00 00 ........
Key ID              : 00 00 00 00 00 00 00 00 ........
Key MIC             : fb 2d fc 67 f1 9e 84 e3 .-.g....
                      3f 58 67 35 6d 69 26 b0 ?Xg5mi&.
Key Data Length     : 56
Key Data            : fe 52 57 89 b3 dc fd 27 .RW....'
                      97 a3 49 05 4a 06 94 6a ..I.J..j
                      7d 27 f6 97 0b 2f 87 6f }'.../.o
                      b5 c5 dd bc fb 86 84 6d .......m
                      70 cb 2c 7f 16 df da dc p.,.....
                      a9 0c 2d 9a 1d ba 08 c4 ..-.....
                      a0 a5 79 55 3b 99 52 f8 ..yU;.R.
[EAP] 2016/09/14 10:27:25,496  Devicetime: 2016/09/14 10:27:24,386
***Authenticator timeout occured for negotiation with f0:cb:a1:7e:bc:eb (Apple 7e:bc:eb) in phase 3
-->Retrying, this time with 1024 ms timeout...
-->EAPOL Header
Protocol Version    : 2
Packet Type         : Key
Packet Length       : 151
Key Type            : 2
-->802.11i RSN Key Descriptor
Key Information     : Version 2 Pairwise Key-Index 0 Install ACK MIC Secure Encrypted-Key-Data
Key Length          : 16
Replay Counter      : 0000000000000005
Nonce               : f4 4e ec c4 0c b9 2b 30 .N....+0
                      aa 0b 5a 0d 4f 2d 4d 76 ..Z.O-Mv
                      c2 46 da f9 20 51 a7 cb .F.. Q..
                      b2 36 c0 f9 7b 93 a4 b3 .6..{...
Key IV              : 00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
Key RSC             : 04 00 00 00 00 00 00 00 ........
Key ID              : 00 00 00 00 00 00 00 00 ........
Key MIC             : 2e 33 e2 6c 47 6d e8 e2 .3.lGm..
                      08 bd 64 8f 6a c0 76 a6 ..d.j.v.
Key Data Length     : 56
Key Data            : 30 dc 09 e9 5c ab 55 d1 0...\.U.
                      e7 c5 c5 16 c3 40 b1 77 .....@.w
                      39 95 da b1 19 5e b6 a6 9....^..
                      3e fa d6 e5 ae fc f7 3d >......=
                      5c 56 0c c9 f0 63 07 4c \V...c.L
                      aa cc b0 09 92 d0 5d 22 ......]"
                      5c 58 15 29 e5 3f 79 53 \X.).?yS
.
. viele "***Authenticator timeout" Meldungen dazwischen
.
[RADIUS-Server] 2016/09/14 10:28:06,399  Devicetime: 2016/09/14 10:28:05,072
Checking for dead accounting sessions:

[EAP] 2016/09/14 10:28:07,460  Devicetime: 2016/09/14 10:28:06,084
***Authenticator timeout occured for negotiation with f0:cb:a1:7e:bc:eb (Apple 7e:bc:eb) in phase 3
-->Maximum number of retries reached
-->Terminating handshake and deauthenticating client, better luck next time

[EAP] 2016/09/14 10:28:07,460  Devicetime: 2016/09/14 10:28:06,085
EAP: Delete station f0:cb:a1:7e:bc:eb

2. Android, wo erwartungsgemäß ein Rauswurf kommen sollte

Code: Alles auswählen

[RADIUS-Server] 2016/09/14 10:34:36,389  Devicetime: 2016/09/14 10:34:35,072
Checking for dead accounting sessions:
[EAP] 2016/09/14 10:34:51,880  Devicetime: 2016/09/14 10:34:50,610
***Rekeying operation started for negotiation with 18:89:5b:a6:07:1c (Samsung a6:07:1c)
-->Restarting key handshake and send first packet
-->EAPOL Header
Protocol Version    : 2
Packet Type         : Key
Packet Length       : 117
Key Type            : 2
-->802.11i RSN Key Descriptor
Key Information     : Version 2 Pairwise Key-Index 0 ACK
Key Length          : 16
Replay Counter      : 0000000000000003
Nonce               : 5f 6b 65 5d f0 7d 4a 0e _ke].}J.
                      7e a1 01 0e 15 c9 44 ff ~.....D.
                      f3 fa 7c 8d 11 4b 86 09 ..|..K..
                      88 88 38 ff 15 35 f2 d9 ..8..5..
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     : 22
Key Data            :
<<<
PMKID               : e4 bf 92 7d 79 95 9a a6 ...}y...
                      1e 70 79 3a e6 0c c7 63 .py:...c
>>>

[EAP] 2016/09/14 10:34:52,098  Devicetime: 2016/09/14 10:34:50,774
***Received EAP packet on WLAN-1-2:
-->EAPOL Header
Protocol Version    : 1
Packet Type         : Key
Packet Length       : 117
Key Type            : 2
-->802.11i RSN Key Descriptor
Key Information     : Version 2 Pairwise Key-Index 0 MIC
Key Length          : 0
Replay Counter      : 0000000000000003
Nonce               : ea b9 bc 74 cb c5 86 63 ...t...c
                      e1 c5 88 ef 1d e5 cf fd ........
                      52 d4 aa d4 6f 0c 00 cd R...o...
                      95 fb 82 d0 a3 15 9e 6b .......k
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             : 3f 3a 6c 0d d6 ee 7c d1 ?:l...|.
                      d5 33 fa a7 47 7a 84 c9 .3..Gz..
Key Data Length     : 22
Key Data            :
<<<
RSN Cipher Info     : Version 1
                      Group Cipher TGI-CSE-CCM
                      Pairwise Ciphers TGI-CSE-CCM
                      Authentication Selectors TGI-802.1x-UNSPEC
                      Capabilities: 1 PTKSA replay counters 1 GTKSA replay counters
>>>
-->Received properly sequenced packet from supplicant for phase 2
-->Computing PTK
  -->PRF-X Data:
00: 02 a0 57 25 08 41 18 89 - 5b a6 07 1c 5f 6b 65 5d
10: f0 7d 4a 0e 7e a1 01 0e - 15 c9 44 ff f3 fa 7c 8d
20: 11 4b 86 09 88 88 38 ff - 15 35 f2 d9 ea b9 bc 74
30: cb c5 86 63 e1 c5 88 ef - 1d e5 cf fd 52 d4 aa d4
40: 6f 0c 00 cd 95 fb 82 d0 - a3 15 9e 6b
  -->Resulting PTK:
00: cf e8 72 65 9d 08 9a 14 - a3 35 e2 91 8c ee 30 bd
10: 43 50 aa 7a 28 66 39 b4 - 0b 76 9b 3d 2f 29 e6 c3
20: 85 f2 9b 89 81 ff 31 e1 - 83 8c 01 69 4a 49 91 58
  -->KCK:
00: cf e8 72 65 9d 08 9a 14 - a3 35 e2 91 8c ee 30 bd
  -->KEK:
00: 43 50 aa 7a 28 66 39 b4 - 0b 76 9b 3d 2f 29 e6 c3
  -->TK:
00: 85 f2 9b 89 81 ff 31 e1 - 83 8c 01 69 4a 49 91 58
-->Switching to pairwise key handshake phase 3, send corresponding packet
-->EAPOL Header
Protocol Version    : 2
Packet Type         : Key
Packet Length       : 151
Key Type            : 2
-->802.11i RSN Key Descriptor
Key Information     : Version 2 Pairwise Key-Index 0 Install ACK MIC Secure Encrypted-Key-Data
Key Length          : 16
Replay Counter      : 0000000000000004
Nonce               : 5f 6b 65 5d f0 7d 4a 0e _ke].}J.
                      7e a1 01 0e 15 c9 44 ff ~.....D.
                      f3 fa 7c 8d 11 4b 86 09 ..|..K..
                      88 88 38 ff 15 35 f2 d9 ..8..5..
Key IV              : 00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
Key RSC             : 07 00 00 00 00 00 00 00 ........
Key ID              : 00 00 00 00 00 00 00 00 ........
Key MIC             : dd fa d3 78 3c 76 f8 e5 ...x<v..
                      bb 0d 15 1f 1d 46 af 23 .....F.#
Key Data Length     : 56
Key Data            : 57 f7 5f 40 a2 1b a4 65 W._@...e
                      0e cc 4c 4e 6f e3 cd f2 ..LNo...
                      86 ce 17 88 e7 85 fd 48 .......H
                      b1 65 54 f7 5e fb 72 fa .eT.^.r.
                      7c 01 60 4c 21 58 28 6a |.`L!X(j
                      5c de 62 fa 55 0f c8 f7 \.b.U...
                      c6 c4 0b 1a 79 71 c4 c4 ....yq..

[EAP] 2016/09/14 10:34:52,098  Devicetime: 2016/09/14 10:34:50,784
***Received EAP packet on WLAN-1-2:
-->EAPOL Header
Protocol Version    : 1
Packet Type         : Key
Packet Length       : 95
Key Type            : 2
-->802.11i RSN Key Descriptor
Key Information     : Version 2 Pairwise Key-Index 0 MIC Secure
Key Length          : 0
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              : 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             : 66 e7 39 43 7c 67 5a 77 f.9C|gZw
                      d5 36 3b e9 36 a9 20 a8 .6;.6. .
Key Data Length     : 0
-->Received properly sequenced packet from supplicant for phase 4
-->PTK handshake successfully performed, configuring pairwise key into hardware
-->PTK handshake successfully performed, enabling peer for normal data transfer
-->setting rekeying timer to 120 seconds

[RADIUS-Server] 2016/09/14 10:35:06,373  Devicetime: 2016/09/14 10:35:05,072
Checking for dead accounting sessions:

[RADIUS-Client] 2016/09/14 10:35:36,293  Devicetime: 2016/09/14 10:35:35,062
RADIUS-Client: register UDP listener(s) for responses
-> port is 9660

[RADIUS-Client] 2016/09/14 10:35:36,293  Devicetime: 2016/09/14 10:35:35,062
Send RADIUS Accounting Request Id 197 to 10.10.10.38:1813 Backup-Step 1 Retry 0
  Acct-Status-Type    : Interim-Update
  User-Name           : test.user
  NAS-Identifier      : AP2
  Called-Station-Id   : 02-A0-57-25-08-41:GAST
  NAS-Port-Type       : Wireless - IEEE 802.11
  WLAN-RF-Band        : 2.4 GHz
  Service-Type        : Framed
  NAS-Port            : 1
  NAS-Port-Id         : 1
  Calling-Station-Id  : 18-89-5B-A6-07-1C
  Connect-Info        : CONNECT 72 Mbps 802.11g/n
  WLAN-Pairwise-Cipher: TGI-CSE-CCMP
  WLAN-Group-Cipher   : TGI-CSE-CCMP
  WLAN-AKM-Suite      : TGI-AUTHSE-8021X
  Framed-IP-Address   : 192.168.181.139
  Acct-Session-Id     : 18895ba6071c-2487000909
  Acct-Session-Time   : 165
  Acct-Input-Octets   : 61599
  Acct-Output-Octets  : 296678
  Acct-Input-Packets  : 317
  Acct-Output-Packets : 327
  NAS-IP-Address      : 10.10.10.52
  Authenticator:
  0000: 22 e9 65 83 0a f3 77 aa 83 2f 2a 83 f1 6f 3f 74  ".e...w../*..o?t

[RADIUS-Server] 2016/09/14 10:35:36,293  Devicetime: 2016/09/14 10:35:35,072
Checking for dead accounting sessions:

[RADIUS-Client] 2016/09/14 10:35:36,293  Devicetime: 2016/09/14 10:35:35,205
Received RADIUS Accounting Response Id 197 from 10.10.10.38 on Port 9660
-->found corr. request 197 to 10.10.10.38:1813, 
-->trigger requester

[RADIUS-Client] 2016/09/14 10:35:36,293  Devicetime: 2016/09/14 10:35:35,205
RADIUS-Client:
  deregister UDP listener for responses on port 9660

[RADIUS-Server] 2016/09/14 10:36:06,385  Devicetime: 2016/09/14 10:36:05,072
Checking for dead accounting sessions:

Ich habe die kompletten Traces und auch die zugehörigen Logdateien des Radius Servers hier. Möchte es nur nicht hier posten, da der Beitrag dann sehr unleserlich wird, ich maile es aber gerne zu.

Gruß Bernie

[alf29]

Moin,

ich sehe in den Traces keine 802.1X-Reauthentisierung, nur ein WPA-Rehandshaking. Und das Apple-Handy fliegt dabei nur deswegen heraus, weil es irgendwie nicht mehr auf die Handshake-Pakete vom AP reagiert und nicht weil ein Reject vom RADIUS-Server gekommen wäre. Das Android-Handy macht den Rehandshake brav mit und deswegen geht die Session auch weiter. Das ist nicht das, worauf ich hinaus wollte, denn während des WPA-(Re-)Handshakes wird der RADIUS-Server authentisierungsmäßig gar nicht gefragt.

Während einer Anmeldung mit WPA/802.1X laufen zwei Phasen ab: In der ersten (der 802.1X-Verhandlung) reden Client und RADIUS-Server über den AP quasi als Relais-Station miteinander, bis von RADIUS-Server ein Accept oder Reject kommt. In der zweiten Phase machen AP und Client den WPA-Handshake, das ist der gleiche Handshake wie auch bei WPA/PSK, nur daß dessen Master Secret eben nicht aus der Passphrase, sondern aus dem Schlüsselmaterial von der 1X-Verhandlung abgeleitet wird.

Was wir hier brauchen, ist eine Wiederholung der ersten Phase (und damit auch implizit der zweiten), denn nur in der wird der RADIUS-Server befragt und könnte dann 'nein' sagen. Nur die zweite Phase, den Key-Handshake zu wiederholen, nutzt nichts.

Wenn am Ende der 1X-Verhandlung das Accept vom RADIUS-Server kommt, dann muß ein Session-Timeout drinstehen und als Termination-Action ein 'RADIUS-Request'. Nach der eingestellten Zeit sollte der AP im EAP-Trace eine neue 1X-Authentisierung beginnen, erkennbar an einem 'Identity Request'. Wenn die Attribute im Accept drinstehen, aber das nicht passiert, dann wird die Reauthentisierung irgendwo auf dem LANCOM verbummelt. Es kann sein, daß Du Reauthentisierungen auf der fraglichen SSID explizit in der Tabelle Setup/IEEE802.1x/Ports einschalten mußt, damit das klappt.

Gruß Alfred

[Bernie137]

Hallo Alfred,

auch wenn es schon ein paar Tage her ist, vielen Dank für Deine ausführliche Antwort. Ich teste nun schon ein paar Tage und konnte neue Erkenntnisse gewinne, aber auch auf neue Probleme stoßen.

Es kann sein, daß Du Reauthentisierungen auf der fraglichen SSID explizit in der Tabelle Setup/IEEE802.1x/Ports einschalten mußt, damit das klappt.

Korrekt, dass kann man Einschalten und dann funktioniert das auch prima. Das gibt es sogar schon im L-54.

Nun soll es aber mit dem Radius Attribut "Simultaneous-use=1" kombiniert werden bzw. erst einmal nur "Simultaneous-use=1" also ohne irgendwelche Credits/Budgets. Dabei stoße ich immer wieder auf das Problem von doppelten Sessions. Die aktivierte Reauthentisierung verschärft die Problematik, daher habe ich es im Moment wieder ausgeschaltet. Aber es scheint nicht die alleinige Ursache zu sein. Im Moment untersuche ich nur mit einem iPhone und dabei stoße ich im Trace immer wieder auf die folgenden Meldungen gefolgt von ganz vielen "***Authenticator timeout occured" was zur Folge hat, dass der Client vom AP herausgeschmissen wird, aber die Session im Radius Server noch ein Weilchen besteht, bis auch dort ein Timeout greift. In der Zwischenzeit (ca. 2 Minuten) kann der Client sich nicht erneut einbuchen.

Also diese Trace-Meldungen tauchen ziemlich exakt nach 120 Sekunden nach dem Einbuchen des Clients auf. Vom Einbuchen bis zum Trace unten passiert nichts außer zyklisch "Radius Server Checking for dead accounting sessions". Was bedeutet "***Authenticator timeout occured"? Authenticator ist doch der AP selbst. Ich verstehe diese Meldung nicht und vor allem welcher Konfigurationsschalter im AP dafür verantworlich ist bzw. was diese Meldungen auslöst?

Code: Alles auswählen

[EAP] 2016/10/07 13:26:14,399  Devicetime: 2016/10/07 13:27:03,520
***Rekeying operation started for negotiation with f0cba17ebceb
-->Restarting key handshake and send first packet
-->EAPOL Header
Protocol Version    : 2
Packet Type         : Key
Packet Length       : 117
Key Type            : 2
-->802.11i RSN Key Descriptor
Key Information     : Version 2 Pairwise Key-Index 0 ACK
Key Length          : 16
Replay Counter      : 0000000000000003
Nonce               : cb 05 21 fb 42 89 da 77 ..!.B..w
                      2d 12 c2 ff 60 0f 99 60 -...`..`
                      d1 d3 31 75 88 12 66 00 ..1u..f.
                      41 1c f5 45 be 78 80 24 A..E.x.$
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     : 22
Key Data            : dd 14 00 0f ac 04 e7 df ........
                      87 5e 12 92 7e da e7 7e .^..~..~
                      87 bc f4 3a ec 47       ...:.G

[EAP] 2016/10/07 13:26:14,726  Devicetime: 2016/10/07 13:27:03,626
***Received EAP packet on WLAN-1-2:
-->EAPOL Header
Protocol Version    : 2
Packet Type         : Key
Packet Length       : 117
Key Type            : 2
-->802.11i RSN Key Descriptor
Key Information     : Version 2 Pairwise Key-Index 0 MIC
Key Length          : 16
Replay Counter      : 0000000000000003
Nonce               : 39 a7 65 8b 58 b6 3a 48 9.e.X.:H
                      a4 88 b7 78 77 89 bc 49 ...xw..I
                      c4 9b 49 b3 4d 9d 6c eb ..I.M.l.
                      ce be 14 11 a0 8f fb 87 ........
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             : f7 23 9b 46 73 1b fc bb .#.Fs...
                      04 65 10 d7 e7 42 ce c2 .e...B..
Key Data Length     : 22
Key Data            : 30 14 01 00 00 0f ac 04 0.......
                      01 00 00 0f ac 04 01 00 ........
                      00 0f ac 01 0c 00       ......
-->Received properly sequenced packet from supplicant for phase 2
-->Computing PTK
  -->PRF-X Data:
00: 02 0b 6b 30 ea 49 f0 cb - a1 7e bc eb 39 a7 65 8b
10: 58 b6 3a 48 a4 88 b7 78 - 77 89 bc 49 c4 9b 49 b3
20: 4d 9d 6c eb ce be 14 11 - a0 8f fb 87 cb 05 21 fb
30: 42 89 da 77 2d 12 c2 ff - 60 0f 99 60 d1 d3 31 75
40: 88 12 66 00 41 1c f5 45 - be 78 80 24
  -->Resulting PTK:
00: f0 7a e7 be c7 95 9a b3 - 51 49 0a a3 f6 29 7a 4b
10: d6 1c 1d 84 c8 1b b0 f0 - 1a 61 81 ce b7 ff 64 6a
20: e5 a3 4d 67 44 52 e7 14 - 7f 5e 04 bd 95 92 8f 80
  -->KCK:
00: f0 7a e7 be c7 95 9a b3 - 51 49 0a a3 f6 29 7a 4b
  -->KEK:
00: d6 1c 1d 84 c8 1b b0 f0 - 1a 61 81 ce b7 ff 64 6a
  -->TK:
00: e5 a3 4d 67 44 52 e7 14 - 7f 5e 04 bd 95 92 8f 80
-->Switching to pairwise key handshake phase 3, send corresponding packet
-->EAPOL Header
Protocol Version    : 2
Packet Type         : Key
Packet Length       : 151
Key Type            : 2
-->802.11i RSN Key Descriptor
Key Information     : Version 2 Pairwise Key-Index 0 Install ACK MIC Secure Encrypted-Key-Data
Key Length          : 16
Replay Counter      : 0000000000000004
Nonce               : cb 05 21 fb 42 89 da 77 ..!.B..w
                      2d 12 c2 ff 60 0f 99 60 -...`..`
                      d1 d3 31 75 88 12 66 00 ..1u..f.
                      41 1c f5 45 be 78 80 24 A..E.x.$
Key IV              : 00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
Key RSC             : 02 00 00 00 00 00 00 00 ........
Key ID              : 00 00 00 00 00 00 00 00 ........
Key MIC             : 52 66 be f6 fc 7d ef 0c Rf...}..
                      e3 10 34 17 08 64 63 ac ..4..dc.
Key Data Length     : 56
Key Data            : 9d fe 7f ea d8 06 46 74 ......Ft
                      da d4 2c 58 7f bf cd 49 ..,X...I
                      b9 a0 35 9d 0c 2b 22 9e ..5..+".
                      ba 98 a6 f6 9c 98 0f 00 ........
                      30 98 55 db 21 d5 47 57 0.U.!.GW
                      ef 32 08 0f d0 f4 f8 79 .2.....y
                      1e 56 e7 04 94 bf b2 0e .V......

[EAP] 2016/10/07 13:26:14,804  Devicetime: 2016/10/07 13:27:03,920
***Authenticator timeout occured for negotiation with f0cba17ebceb in phase 3
-->Retrying, this time with 1024 ms timeout...
-->EAPOL Header
Protocol Version    : 2
Packet Type         : Key
Packet Length       : 151
Key Type            : 2
-->802.11i RSN Key Descriptor
Key Information     : Version 2 Pairwise Key-Index 0 Install ACK MIC Secure Encrypted-Key-Data
Key Length          : 16
Replay Counter      : 0000000000000005
Nonce               : cb 05 21 fb 42 89 da 77 ..!.B..w
                      2d 12 c2 ff 60 0f 99 60 -...`..`
                      d1 d3 31 75 88 12 66 00 ..1u..f.
                      41 1c f5 45 be 78 80 24 A..E.x.$
Key IV              : 00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
Key RSC             : 02 00 00 00 00 00 00 00 ........
Key ID              : 00 00 00 00 00 00 00 00 ........
Key MIC             : a8 a2 f5 7a f8 81 7c 31 ...z..|1
                      33 f6 2f 1b 0e 02 11 8d 3./.....
Key Data Length     : 56
Key Data            : b2 d8 e0 f5 ba ee 3d 9b ......=.
                      51 c9 0c 8c 5a b7 ef 9a Q...Z...
                      ce df 68 58 b9 d5 e0 36 ..hX...6
                      df 96 2c a8 b5 7c f0 a3 ..,..|..
                      0c 91 60 13 0e 2f 26 52 ..`../&R
                      c9 6f ae ca 1e 0f ef 89 .o......
                      54 59 d2 26 b7 c9 5c 2b TY.&..\+
.
.
.
[EAP] 2016/10/07 13:26:54,772  Devicetime: 2016/10/07 13:27:43,900
***Authenticator timeout occured for negotiation with f0cba17ebceb in phase 3
-->Maximum number of retries reached
-->Terminating handshake and deauthenticating client, better luck next time

[EAP] 2016/10/07 13:26:54,772  Devicetime: 2016/10/07 13:27:43,905
EAP: Delete station f0:cb:a1:7e:bc:eb

Gruß Bernie

[alf29]

Moin,

Nun soll es aber mit dem Radius Attribut "Simultaneous-use=1" kombiniert werden bzw. erst einmal nur "Simultaneous-use=1" also ohne irgendwelche Credits/Budgets.

Meinst Du damit wirklich ein RADIUS-Attribut oder einen Schalter an Deinem RADIUS-Server? Denn in der IANA-Liste finde ich kein RADIUS-Attribut dieses Namens.

m Moment untersuche ich nur mit einem iPhone und dabei stoße ich im Trace immer wieder auf die folgenden Meldungen gefolgt von ganz vielen "***Authenticator timeout occured" was zur Folge hat, dass der Client vom AP herausgeschmissen wird, aber die Session im Radius Server noch ein Weilchen besteht, bis auch dort ein Timeout greift. In der Zwischenzeit (ca. 2 Minuten) kann der Client sich nicht erneut einbuchen.

Also diese Trace-Meldungen tauchen ziemlich exakt nach 120 Sekunden nach dem Einbuchen des Clients auf. Vom Einbuchen bis zum Trace unten passiert nichts außer zyklisch "Radius Server Checking for dead accounting sessions". Was bedeutet "***Authenticator timeout occured"? Authenticator ist doch der AP selbst. Ich verstehe diese Meldung nicht und vor allem welcher Konfigurationsschalter im AP dafür verantworlich ist bzw. was diese Meldungen auslöst?

Das ist - ich glaube, das hatte ich schon einmal erwähnt - das WPA-Rehandshaking im WLAN, das völlig unabhängig von 802.1X ist und das man auch bei WPA-PSK machen könnte. Von sich aus wird ein LANCOM kein solches Rehandshaking machen, der dafür zuständige Parameter in den WLAN Verschlüsselungseinstellungen ('WPA-Rekeying-Cycle') steht auf Null. Wenn das LANCOM zwei Minuten nach Einbuchen des Clients so ein Rehandshaking anstößt, dann hast Du irgendwann für diese SSID den Wert von Null auf 120 gestellt...

Was bedeutet "***Authenticator timeout occured"? Authenticator ist doch der AP selbst.

Korrekt, und auf dessen Seite ist ein Timeout aufgetreten - ist eine Frage der Sichtweise. Es bedeutet schlicht, daß der AP auf sein Pakete während des Key-Handshakes kein Antwort vom Client bekommen hat. Warum, weiß ich nicht, kann sein, daß das WPA-Rehandshaking in der doch schon recht alten Firmware fürs L-54 noch eine Macke hat. Diese Funktion wird eher selten verwendet...

Ich verstehe diese Meldung nicht und vor allem welcher Konfigurationsschalter im AP dafür verantworlich ist bzw. was diese Meldungen auslöst?

Siehe oben - WPA-Rekeying-Cycle in den WLAN-Verschlüsselungseinstellungen. Stelle ihn wieder auf Null zurück, Du drehst da an der falschen Stelle...

Gruß Alfred


Gruß Alfred