ragan_davis@colstate.edu wrote:
If the server get's an incomplete reply to it's challenge, or no reply, will it resend it's challenge?
No. RADIUS is entirely driven by the clients.
Or, will the client sense that the server didn't respond to it's challenge response and start a new session.
The client *does* see the Access-Challenge, but it decides for some reason to stop talking to the server.
Of course, because each vendor has their own radius server and 802.1x client solution, they want to blame freeradius so that I'll buy their product.
FreeRADIUs is interoperable with pretty much everything out there. Novell is dumping their proprietary server for FreeRADIUS. Zyxel is selling a $500 FreeRADIUS box (with some question of possible GPL violations), and I know of 2 other companies using FreeRADIUs as part of their RADIUS server solutions.
I'm trying my hardest to fight this, because I'm a big freeradius fan.
Thanks.
The debug on the Odyssey Client shows that it believes it sent the response to the challenge. The debug on the WLAN switch shows that it forwards both the challenge from freeradius and the challenge response from the client. Freeradius debug appears to get the response from the client, sees the outer credentials (anonymous, etc.), but doesn't process the tunneled information for some reason.
Hmm... I do know that the odyssey client does some very weird things. In some cases, it's interoperable *only* with Funk's server, which is a nice way for them to say "other servers are broken", rather than "our client is broken".
So, does this mean that I should interpret the above enum to have elements 0-13, or 1-14, and match the numbers 7 and 13 with it's position in the enum?
0-13
I'm curious why we can see the TLS stuff during the first try (13), but not the second try (7). What is the difference?
The client is behaving differently the second time around. FreeRADIUS treats the two TLS sessions as being 100% unique. It responds in the same way to the same input every time. So if one session fails and the other succeeds, it's because the client is doing something different.
I performed a packet capture using ethereal, listening on the interface that freeradius is running on. Did this on the box, not inline. I would rather not post it to the list, but I'd be glad to send it to you if you'd be willing to look at it. Let me know.
Put it on a web page and mail me the link. On a plus, the latest version of Ethereal appears to have stolen the FreeRADIUS dictionary files, so the radius packets it decodes should make a lot more sense. Alan DeKok.