No EAP session matching state ...
fikais at cuni.cz
Wed Oct 25 16:48:20 CEST 2017
> -----Original Message-----
> From: Freeradius-Users [mailto:freeradius-users-
> bounces+fikais=cuni.cz at lists.freeradius.org] On Behalf Of Alan DeKok
> Sent: Wednesday, October 25, 2017 4:29 PM
> To: FreeRadius users mailing list
> Subject: Re: No EAP session matching state ...
> On Oct 25, 2017, at 10:20 AM, Fikais Ladislav <fikais at cuni.cz> wrote:
> > I've migrated from FRv2 to 3.0.15 and there is a lot of "No EAP session
> > matching state..." messages and auth rejects. The strange thing is the
> > first
> > request for some user is received with State attribute (which is wrong,
> > right?) so the FR doesn't know this session and sends reject.
> > Full debug from about one minute is here:
> > https://dec59.ruk.cuni.cz/~fikais/fr/r1c3x.log
> Use "radiusd -X". All of the documentation says to do that
If I do that it says:
raddb/sites-enabled/tls: Threading must be enabled for TLS sockets to
raddb/sites-enabled/tls: You probably need to do 'radiusd -fxx -l stdout'
This output was generated with "radiusd -fxxx -l stdout". Isn't it "same"
> > I know that after daemon reload the EAP sessions are lost but it works
> > this way even if it runs for hours... Am I doing something wrong?
> No. The server should work.
> 99.999% of the time, the error shows up because the client and/or NAS / AP
> is broken.
> There is nothing you can do to FreeRADIUS to fix the problem.
I've FRv2 (+RadSecProxy) which works and if I replace it with the this new
3.0.15 (w/o RadSecproxy, config from source), then local auth (WiFi
controlers, subordinate FRs) works fine. Yes, there are a few "No EAP sess..."
messages maybe like you are saying because something in WiFi network is
broken/bad signal/etc. But the main problem is that it behaves like this (even
worst - most requests are rejected) if the requests comes over radsec from
Czech national eduroam server at CESNET (they are using Radiator). They're
saying the problem is on my side...
Isn't it possible there is something wrong in FRv3 radsec? Maybe some
packets are lost? Is there a way to debug it? It's TCP so if there is some
kind of network packet lost (which I think isn't) it shoud "survive", right?
> Alan DeKok.
> List info/subscribe/unsubscribe? See
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4739 bytes
Desc: not available
More information about the Freeradius-Users