Vieri Di Paola
vieridipaola at gmail.com
Tue May 25 15:10:16 CEST 2021
On Tue, May 25, 2021 at 2:17 PM Alan DeKok <aland at deployingradius.com> wrote:
> On May 25, 2021, at 8:01 AM, Vieri Di Paola <vieridipaola at 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 ?
> > 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:
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.
More information about the Freeradius-Users