On Tue, May 25, 2021 at 2:17 PM Alan DeKok <aland@deployingradius.com> wrote:
On May 25, 2021, at 8:01 AM, Vieri Di Paola <vieridipaola@gmail.com> wrote:
It puzzles me as to why it does not when connecting with a wire and does when connecting wirelessly.
Wired / wireless have different configuration systems / locations on Windows. So you need to add certificates to both places in order to do both wired and wireless.
I'm using computer certificates, and I import them with the mmc snap-in. I'll double-check that. Thanks.
If you let the server sit for a while, when it gets the next packet, it will print out a huge set of debug messages which tell you what's wrong, and pointing you to the Wiki.
With just radiusd -X and FR v.3.0.20 ?
Yes.
The only thing I see even if I wait for a long while is something like this:
(625) Sent Access-Challenge Id 21 from 10.215.144.91:1812 to 10.215.110.190:49154 length 0 (625) EAP-Message = 0x010300060d20 (625) Message-Authenticator = 0x00000000000000000000000000000000 (625) State = 0x6680142d668319b34dda38122881c11c (625) Finished request Waking up in 4.9 seconds. ((625) Cleaning up request packet ID 21 with timestamp +8779
I may need to run radiusd with another set of parameters?
No, the server needs to get *another packet*, as I said above.
OK, but I guess it's not getting it. Here's the full radiusd -X log: https://drive.google.com/file/d/1yyh7-e68iC6zfMzZGTnF72SFO8s3lT4P/view?usp=s... On the Windows client side, I noticed that there's a Wired-Autoconfig event log telling me that there was no reply to EAP. Of course, FR *is* replying so maybe it's not getting to the client for some other reason. Will have to dig into this some more. Thanks, Vieri