No EAP session matching state ...
Hello, 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 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? Thanks. Ladislav Fikais Charles University Computer Centre Petrská 3, Praha 1 110 00, Czech Republic
On Oct 25, 2017, at 10:20 AM, Fikais Ladislav <fikais@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.
Exactly.
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
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. Alan DeKok.
-----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: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@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.
Exactly.
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[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 This output was generated with "radiusd -fxxx -l stdout". Isn't it "same" (+timestamps)?
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? Lada
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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.
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
On Oct 25, 2017, at 11:07 AM, Fikais Ladislav <fikais@cuni.cz> wrote:
OK. Could you please briefly look at the config from debug if there isn't something very bad? Maybe I'm already blind...
As I said already, don't use "-xxx". And, the issue is likely not FreeRADIUS. I'm not sure how else to say that. Maybe there's something in v2 that the upstream proxies like, and they dislike v3. Even if that was true, the proxies should implement RADIUS correctly. So changing from v2 to v3 shouldn't cause this problem. Alan DeKok.
OK, sending output from -X. 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 5:23 PM To: FreeRadius users mailing list Subject: Re: No EAP session matching state ...
On Oct 25, 2017, at 11:07 AM, Fikais Ladislav <fikais@cuni.cz> wrote:
OK. Could you please briefly look at the config from debug if there isn't something very bad? Maybe I'm already blind...
As I said already, don't use "-xxx". And, the issue is likely not FreeRADIUS.
I'm not sure how else to say that.
Maybe there's something in v2 that the upstream proxies like, and they dislike v3. Even if that was true, the proxies should implement RADIUS correctly. So changing from v2 to v3 shouldn't cause this problem.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (2)
-
Alan DeKok -
Fikais Ladislav