Its a packet that doesn't follow the RFC specifications. RADIUS packets
include what are known as Attribute-Value pairs (AV pairs). Each
AV Pair has an identifier (the attribute), a length, and then the data.
The type of the data is determined by the type of the attribute (which
is specified in the dictionary for each attribute).
A typical malformed packet that has recently becoming common is where the
data portion will not be included, and the length specified is 2 (it
includes the attribute and length bytes in the length field). All
RADIUS attributes (according to the RFC) require >= 3 for the length.
This is the kind of malformed packet RadiusNT can work around and not
by default accepts (although I don'y really like it).
Livingston had a bug that was putting a length specified in that was
lower than the actual length of the avpair itself, which was causing
problems when a RADIUS server tried to parse the request. That is the
most common type of "true" malformed request.
If you run RadiusNT in -x15 -X debug, you'll see the av pairs debugged.
Its the second set of numerical numbers (in hex). If you capture that
from the request RadiusNT says is malformed, I can interpret it and
tell you whats malformed about it.
-- Dale E. Reed Jr. (daler@iea-software.com)_________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com