On 11/19/2012 08:23 AM, PENZ Robert wrote:
My first question is, how can I decode a EAP-Message from the debug
Wireshark, or read the EAP RFC and decode it manually (see below)
log to check if the request is itself ok. Here is first packet from
No, this is *not* the first packet, because it has a "State" attribute, which is only present in 2nd and subsequent packets of the EAP exchange. The reason you're getting the error message is that the "State" attribute is unknown, so FR can't proceed with the EAP session and has no choice but to drop it. Check you haven't reduced the "timer_expire" value in eap.conf to a too-low value. How many FR servers do you have serving this NAS? Is it possible the NAS is sending packets in a round-robin fashion (which is bad) which is why you're seeing a packet for which you don't have State? I guess it's possible something is mangling the State attribute from the previous packet (which is *actually* the first packet). Otherwise, the client or NAS is doing something odd.
this client in some time, and it already generates the error. But the same client worked before and after it for days without a problem:
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.
rad_recv: Access-Request packet from host 10.xxx.xxx.4 port 44519, id=151, length=244 User-Name = "host/xxxxxxxxxxxxx.tirol.local" EAP-Message = 0x02ff00690d800000005f160301005a01
Ok so this says: 02 - eap response ff - eap ID 255 - bit odd.. 0069 - length in hex 0d - eap type 13 (EAP-TLS) 80 - eap TLS flags = length included 0000005f - tls length 160301 - TLS packet 0x16==22==handshake record, version 3,1 (TLS 1.0) 005a - record length 01 - handshake=client hello etc. etc. So, it's the start of an EAP-TLS exchange, but as above, it's *not* the first packet. If you start a tcpdump on the server, you'll see how this works: C: Access-Request, no state, EAP-Identity=abc S: Access-Challenge, state=xxxx, EAP-TLS blah C: Access-Request, state=xxxx, EAP-TLS blah i.e. the NAS has to reflect the "State" back to FreeRADIUS on each packet. Something is interfering with that, or erasing the "State" at your end (a timer or restart).
rlm_eap: No EAP session matching the State variable
See?
Invalid means I return a reject ... should I return something else?
No.
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?