On Thu, Jan 6, 2011 at 4:18 AM, Alan DeKok <al...@deployingradius.com> wrote: > Ben Wiechman wrote: >> I've been testing EAP-TTLS/MSCHAPv2 authentication with a network >> device. FreeRADIUS keeps complaining about EAP sessions not finishing >> with the link to the certificate compatibility wiki link, however the >> authentication process completes successfully. Looking at the packet >> exchanges more carefully it appears that the supplicant is not >> incrementing the Packet Identifier. Every EAP packet sent by the >> device uses an packet identifier of 0. > > Ahh... a *RADIUS* packet identifier of 0. That's... rude.
Am I to understand as well that it may not be a requirement for the Packet Identifier to be incremented or semi-unique, but it is probably a good best practice to recommend to the hardware vendor? > >> Digging through the RFCs I didn't find a requirement that the Packet >> Identifier be incremented, only the note that it is used to correlate >> requests and responses. This is obviously probably more difficult if >> it never changes. > > It can be re-used when the client receives a reply. > >> Is it a requirement that the NAS increment or change this value? It >> would definitely seem to be the preferred choice. Or is the server a >> bit too aggressive in detecting incomplete EAP sessions in this case? > > It's a bit aggressive. The check for incomplete sessions is done when > the RADIUS packet is deleted. In the *normal* case, the old packet is > cleaned up after ~3-4 seconds. In this case, it's deleted *immediately* > when the server receives a new request. > > The solution is simple, and can go into 2.1.11. > Might cut down on questions from people who actually read the debug output! :) Ben - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
