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@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@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