On Thu, Jan 6, 2011 at 4:18 AM, Alan DeKok <aland@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