No EAP session matching state ...

[Fikais Ladislav]

OK. Could you please briefly look at the config from debug if there isn't 
something very bad? Maybe I'm already blind...

https://dec59.ruk.cuni.cz/~fikais/fr/r1c3x.log

Thx.

Lada

> -----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[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.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4739 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20171025/fd7b5ab8/attachment-0001.bin>