[EMAIL PROTECTED] 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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html