On 21/11/12 12:00, PENZ Robert wrote:
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.
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.
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?
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?
Is this a client problem or a misconfiguration on my part?
It's probably a client or NAS problem, unless you've set timer_expire
too low.
However: I guess this could also happen right after the server is
restarted. Could that be it - is a cron job restarting it maybe?
no the server is running for > 10 days
but if I would restart the server I would reject all clients to the guest vlan
on reauthentication after that ... that can't be the designed way.
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
