Strange packet causing radius to crash.

Matthew Schumacher matt.s at
Thu Feb 21 02:02:17 CET 2008


A long while ago I posted some requests to have the NAS_Idenitfier
passed to the session_zap function so that stop messages created to zap
sessions would have the correct NAS_Identifier.  I need this because I
made some accounting decisions based on this attribute.  I posted in
bugzilla and even wrote a patch for it:

The patch proved to be unreliable, and now I'm trying to figure out why.
    Most of the time it works fine, but every now and then it crashes
the radius server.  In digging around trying to figure out why it
doesn't work I was able to capture the Access-Request packet that
crashes the server.

In wireshark it shows the error, "VSA too short":

User Datagram Protocol, Src Port: 1645 (1645), Dst Port: 1645 (1645)
    Source port: 1645 (1645)
    Destination port: 1645 (1645)
    Length: 163
    Checksum: 0x96d2 [correct]
Radius Protocol
    Code: Access-Request (1)
    Packet identifier: 0xa0 (160)
    Length: 155
    Authenticator: 1CC1E84AA40F3B2168FD1A0CF4D60DFB
    Attribute Value Pairs
        AVP: l=11  t=User-Name(1): michael.s
            User-Name: michael.s
        AVP: l=18  t=User-Password(2): Encrypted
            User-Password: \221-
        AVP: l=6  t=NAS-IP-Address(4): x.x.x.x
            NAS-IP-Address: x.x.x.x (x.x.x.x)
        AVP: l=6  t=NAS-Port(5): 257
            NAS-Port: 257
        AVP: l=10  t=Acct-Session-Id(44): 16779082
            Acct-Session-Id: 16779082
        AVP: l=14  t=Vendor-Specific(26) v=UTStarcom Incorporated(429)
        [VSA too short]

Does anyone know what the deal is with this?  Reading the RFC it looks
like I should get the 1 byte for the type, 1 byte for length, 4 bytes
for id, then string.  In the capture I have this, but there are ~ 48
bytes after this.

Any help would be greatly appreciated.

Oh, before I forget, platform is linux, radius is 1.1.7.


More information about the Freeradius-Devel mailing list