Hi!
I was still not able to get a trace on the client site, but I believe these debug log entries should help. This time I got the start packet and it is within some seconds that I get the 2 packet to the radius server and the State variable seems to be the same. Ready to process requests. rad_recv: Access-Request packet from host 10.xx.xx.5 port 54217, id=11, length=152 User-Name = "host/xxxxxxxxxxxxx.local" EAP-Message = 0x02ff002101686f73742f4456542d303039363832322e7469726f6c2e6c6f63616c NAS-IP-Address = 10.xx.xx.5 Service-Type = Login-User Calling-Station-Id = "xx-xx-xx-xx-xx-xx" NAS-Port-Id = "1:29" NAS-Port = 1029 NAS-Port-Type = Ethernet Message-Authenticator = 0xd080844ef3e47a9bc21e8c848b5a8548 ...... [eap] EAP packet type response id 255 length 33 [eap] No EAP Start, assuming it's an on-going EAP conversation +++[eap] returns updated ++- else else returns updated Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group EAP {...} [eap] EAP Identity [eap] processing type tls [tls] Requiring client certificate [tls] Initiate [tls] Start returned 1 ...... Sending Access-Challenge of id 11 to 10.xx.xx.5 port 54217 EAP-Message = 0x010000060d20 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x642534cc642539e20b4be1e3ae0328c0 Finished request 62603. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 10. xx.xx.5 port 54217, id=12, length=242 User-Name = "host/xxxxxxxxxxxxx.tirol.local" EAP-Message = 0x02ff00690d800000005f160301005a01000056030150bd9377fb696c9f5eaedc568220f9aa35ab65930cf2232f4131c054b0562954000018002f00350005000ac013c014c009c00a003200380013000401000015ff01000100000a0006000400170018000b00020100 NAS-IP-Address = 10.xx.xx.5 Service-Type = Login-User Calling-Station-Id = "xx-xx-xx-xx-xx-xx" NAS-Port-Id = "1:29" NAS-Port = 1029 NAS-Port-Type = Ethernet State = 0x642534cc642539e20b4be1e3ae0328c0 Message-Authenticator = 0xeada93f9da1ca47a6f0325e8ad0414a9 ....... [eap] EAP packet type response id 255 length 105 [eap] No EAP Start, assuming it's an on-going EAP conversation +++[eap] returns updated ++- else else returns updated Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group EAP {...} rlm_eap: No EAP session matching the State variable. [eap] Either EAP-request timed out OR EAP-response to an unknown EAP-request [eap] Failed in handler ++[eap] returns invalid There is no other packet between this two and only 5 seconds, server has not been restarted. Robert -----Ursprüngliche Nachricht----- Von: freeradius-users-bounces+robert.penz=tirol.gv...@lists.freeradius.org [mailto:freeradius-users-bounces+robert.penz=tirol.gv...@lists.freeradius.org] Im Auftrag von PENZ Robert Gesendet: Dienstag, 27. November 2012 17:38 An: FreeRadius users mailing list Betreff: AW: AW: EAP-TLS Failed in handler question > > With first packet I meant first packet the radius server saw in some time > > ... the switch forces a reauthentification every 2h > A re-auth is a fresh EAP session. So even on a re-auth, the first packet > would not have a "State" attribute, absent software bugs. ok > >> It *could* be that the client just got stuck and is responding (very) > >> late. But I'm quite surprised the NAS didn't timeout the EAP auth before > >> that. > > > > We're running Extreme Networks Switches with following timers set: > > > > configure netlogin dot1x timers quiet-period 30 > > configure netlogin dot1x timers reauth-period 7200 > We run SummitX edge, and when I've tested dot1x netlogin in the past, I > haven't seen this issue. We've never widely deployed it, however, so > it's possible there's an XOS bug where a small percentage of re-auths > erroneously re-use the "State". You'd need to get a packet capture to be > sure. ok ... will try to get one .. is not easy ... > > but reject means the switch sets the port to the guest vlan, and therefor > > the PC loses the connections ... is there a way to request a new full > > eap/tls handshake from the client? > > You're not understanding, or I'm not making myself clear. > > Suggestion: fire up wireshark, and take a careful look at a normal EAP > authentication. You'll see that the first packet is an EAP-Identity > without a "State" attribute, which the server responds to with an > Access-Challenge containing the default eap type "start" payload, and a > "State" attribute. > > Are you *absolutely sure* that these packets are really the first RADIUS > packet in the auth/re-auth? will check again and get back to you > If you're sure, your problem seems to be that the correct first packet > isn't being sent; the switch is just jumping straight in with the EAP > payload *and* a "State" attribute. I am curious to know where it's > getting that "State" attribute. > > The server source code assumes that a "State" attribute will be valid. > There's no setting to "just accept it". > > Interestingly, I see the RADIUS RFC does actually allow clients to send > a previous "State" if you send an Access-Accept with: > > Termination-Action = RADIUS-request > You're not doing that, are you? no, I'm not > No. As above, re-auths start new EAP sessions. You would only reject any > EAP sessions that were in the *middle* of performing an auth, as the > "state" would be lost across restarts. But this is a very narrow window. so I would be best to set iptables to drop requests for 1min than restart the radius und remove the iptables rules? or can I set freeradius in a mode where is does not accept new sessions? and after 2 minutes I restart it? So that the switch is forced onto the other switch. or what is the best practice to never have falls rejects? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html