No EAP session matching state ...
fikais at cuni.cz
Wed Oct 25 17:07:12 CEST 2017
OK. Could you please briefly look at the config from debug if there isn't
something very bad? Maybe I'm already blind...
> -----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:57 PM
> To: FreeRadius users mailing list
> Subject: Re: No EAP session matching state ...
> On Oct 25, 2017, at 10:48 AM, Fikais Ladislav <fikais at cuni.cz> wrote:
> > If I do that it says:
> > raddb/sites-enabled/tls: Threading must be enabled for TLS sockets to
> > function properly
> > raddb/sites-enabled/tls: You probably need to do 'radiusd -fxx -l
> > stdout'
> > for debugging
> That's fine.
> > This output was generated with "radiusd -fxxx -l stdout". Isn't it "same"
> > (+timestamps)?
> Yes... and the timestamps aren't useful in 99% of the situations.
> It's good to follow instructions.
> > 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.
> Then something else is going wrong. A normal FreeRADIUS configuration
> doesn't do that.
> The main reason for these messages is that FR sends a response, times it
> out after 5 seconds, and then after *that*, the client / AP sends the next
> packet of an EAP session.
> This just isn't the fault of FreeRADIUS.
> > 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
> > 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...
> Are they getting the replies? If so, then the problem isn't on your end.
> > 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?
> Packets aren't lost over TCP.
> 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