No EAP session matching state ...

[Alan DeKok]

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[7]: Threading must be enabled for TLS sockets to 
> function properly
> raddb/sites-enabled/tls[7]: 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 (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...

  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.