Hi All, I know this isn't strictly a FreeRADIUS issue but many of the users of the list are involved in academia and so may have come across this with their linux users. wpa_Supplicant appears to work fine on wireless networks, but on wired networks it attempts to re-authenticate every 30 seconds.. I can't find the root cause for this; packet traces show no EAPOL activity prior to re-authentication and the supplicant itself reveals nothing in it's output or logs. The only possible explanation I can think of, is the out-of-order EAP-Notification packet the ProCurve NAS sends after the EAP-Success packet. Could this confuse the supplicant into thinking the session was ongoing, and then time out after 30 seconds and restart the authentication process ? It certainly breaks the EAP Spec.. It anyone else experiencing this with different NAS? Thanks, Arran
On Fri, Mar 21, 2008 at 1:05 PM, Arran Cudbard-Bell <A.Cudbard-Bell@sussex.ac.uk> wrote:
I know this isn't strictly a FreeRADIUS issue but many of the users of the list are involved in academia and so may have come across this with their linux users.
wpa_Supplicant appears to work fine on wireless networks, but on wired networks it attempts to re-authenticate every 30 seconds..
I don't see any connection here to FreeRADIUS (or the authentication server in general), but well anyway.. Would it be possible to get a debug log from wpa_supplicant showing this? I would like to see a log with timestamps (-ddt on command line) to be able to reproduce similar NAS behavior for my own tests. It would also be useful to get a packet capture log of the EAPOL frames (e.g., with tcpdump or wireshark from the client) showing couple rounds of authentication. Feel free to send these directly to me (j@w1.fi) since this is getting quite off topic for this mailing list.
I can't find the root cause for this; packet traces show no EAPOL activity prior to re-authentication and the supplicant itself reveals nothing in it's output or logs.
I would assume it does show something, but maybe nothing obvious. This is likely triggered by an authentication timeout in the supplicant.
The only possible explanation I can think of, is the out-of-order EAP-Notification packet the ProCurve NAS sends after the EAP-Success packet. Could this confuse the supplicant into thinking the session was ongoing, and then time out after 30 seconds and restart the authentication process ? It certainly breaks the EAP Spec..
That sounds broken.. If the authenticator (NAS) sends EAP-Request/Notification after a successful authentication (i.e., after having sent EAP-Success), this is likely assumed to be a request for re-authentication. I would expect that this starts some timers in the supplicant and if the authenticator does not do anything at this point, authentication timeout will trigger supplicant do try to complete the authentication.
It anyone else experiencing this with different NAS?
I haven't tested this with ProCurve, but at least my tests with a Cisco switch have not shown similar behavior, i.e., wpa_supplicant was authenticating just once and only if the NAS was configured to re-authenticate (e.g., after an hour), would new authentication be started (by the NAS). - Jouni
Arran Cudbard-Bell wrote:
Hi All,
I know this isn't strictly a FreeRADIUS issue but many of the users of the list are involved in academia and so may have come across this with their linux users.
wpa_Supplicant appears to work fine on wireless networks, but on wired networks it attempts to re-authenticate every 30 seconds..
It's been a while since I tested it, but I didn't see that happening.
hi, a couple of my workstations are Ubuntu Linux systems using wpa_supplicant to EAP auth on the wired and thus get a different VLAN to the other nearby 'untrusted' systems ;-) I dont see any reauth every 30 seconds. cisco switches used with FR 2.0.3 alan
participants (4)
-
A.L.M.Buxey@lboro.ac.uk -
Arran Cudbard-Bell -
Jouni Malinen -
Phil Mayers