> > 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