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?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
