Should MAX_STRING_LEN be 253?

Makarand Pradhan makarandpradhan at ruggedcom.com
Fri Aug 19 00:04:16 CEST 2011


Greetings everyone.

This email concerns the constant "MAX_STRING_LEN".

Problem description:
libradius.h
#define MAX_STRING_LEN          254     /* RFC2138: string 0-253 octets */

I have been working on a EAP radius authentication issue where the 
Radius server is a Windows 2008 NPS. Authentication fails due to 
malformed packets.

The freeradius package is being used to encode the message to be sent to 
the server.

RFC2138 says:

    A summary of the Attribute format is shown below.  The fields are
    transmitted from left to right.

     0                   1                   2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
    |     Type      |    Length     |  Value ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

       The format of the value field is one of four data types.

       string    0-253 octets

Based on the RFC the constant is correctly defined to be 254 bytes.

All the same, if 2 bytes of the 255 bytes are reserved for type and 
length, I am left with 253 bytes to store my data.

As the constant MAX_STRING_LEN is being used in our code to split a big 
EAP message into multiple segments, we tend to loose one byte in every 
segment causing authentication failure (malformed packet received).

Question:
Based on the above analysis it was felt that the constant should be 253. 
Should the constant be changed to 253 or is there any other reason for 
keeping it at 254?

Have a nice day everyone.

Cheers,
Makarand.


-- 
___________________________________________________________________________
NOTICE OF CONFIDENTIALITY:
This e-mail and any attachments may contain confidential and privileged information.  If you are
not the intended recipient, please notify the sender immediately by return e-mail and delete this
e-mail and any copies.  Any dissemination or use of this information by a person other than the
intended recipient is unauthorized and may be illegal.
_____________________________________________________________________

  




More information about the Freeradius-Devel mailing list