Multiple Password Prompts
aland at ox.org
Fri Aug 5 23:30:44 CEST 2005
ragan_davis at 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
> 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?
> 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
> 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.
More information about the Freeradius-Users