Note: This is a repost from The Packetmangler – All Things Network Analysis.

I’m regularly dealing with RADIUS Accounting pcaps from mobile networks. Often colleagues come along and tell me “he, I can’t decode this RADIUS accounting messages from a Starent PGW”.

If you run tshark on such a packet, you see this error message:

$ tshark -n -VVV -r radius-acct.pcap -Y 'frame.number == 4'
...
Radius Protocol
    Code: Access-Accept (2)
    Packet identifier: 0x4 (4)
    Length: 219
    Authenticator: abc
    [This is a response to a request in frame 3]
    [Time from request: 0.001690000 seconds]
    Attribute Value Pairs
        AVP: l=14 t=Calling-Station-Id(31): 49xxxxxxxxxx
            Calling-Station-Id: 49xxxxxxxxxx
        AVP: l=26 t=User-Name(1): user@domain
            User-Name: user@domain
        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=9 t=NAS-Identifier(32): starent
            NAS-Identifier: starent
        AVP: l=6 t=Service-Type(6): Framed(2)
            Service-Type: Framed (2)
        AVP: l=6 t=Framed-Protocol(7): GPRS-PDP-Context(7)
            Framed-Protocol: GPRS-PDP-Context (7)
        AVP: l=6 t=NAS-Port-Type(61): Wireless-Other(18)
            NAS-Port-Type: Wireless-Other (18)
        AVP: l=12 t=Vendor-Specific(26) v=Starent Networks(8164)
        [VSA too short]
        [AVP too short: length 1 < 2]

Capture 1: Dissected packet showing the infamous error (some information retracted)

So, what’s the problem here? VSAs, or Vendor Specific Attributes, are vendor defined RADIUS attributes which have their type, length and value encoded in the packet itself. Nothing new here, but what you need to know is that they come in two different flavours:

  • 1 Byte VSAs
  • 2 Byte VSAs

Starent Packet Gateways (now Cisco) can in fact send RADIUS Accounting packets in both flavours. You can pick one, but you need to make sure that your AAA and all downstream accounting receivers use the same dictionary. Most customers I know still use the 1-Byte VSA dictionary, but Wireshark’s current stable releases are only shipped with 2-byte VSA dictionaries! Here on my Linux machine with Wireshark 1.12.5 it’s the same. Let’s have a look at the Starent.dictionary:

$ head -18 /usr/share/wireshark/radius/dictionary.starent
# -*- text -*-
##############################################################################
#
# Starent dictionary
# http://www.starentnetworks.com/
#
# Starent dictionary with 2 bytes tag and 2 byte length.
#
# The source of this document is a Cisco Manual:
# "Cisco ASR 5000 Series AAA and GTP Interface Administration and
# Reference Release 12.x (Last Updated May 31, 2011)"
#
# This document is available at:
# http://www.cisco.com/en/US/products/ps11072/products_implementation_design_guides_list.html
#
##############################################################################
 
VENDOR Starent 8164 format=2,2

So, all we need is a VSA1 dictionary for Starent and include it. That dictionary is already up at Github and needs to be copied onto your file system were all the other dictionaries are stored. The last thing you need to do is tell Wireshark only to use the VSA1 version – you can’t use both simultaneously. This works by editing the include file dictionary, commenting out the old dictionary and including the vsa1-version.

#$INCLUDE dictionary.starent
$INCLUDE dictionary.starent.vsa1

Now let’s see how this worked out:

$ tshark -n -VVV -r radius-acct.pcap -Y 'frame.number == 4'
...
Radius Protocol
    Code: Access-Accept (2)
    Packet identifier: 0x4 (4)
    Length: 219
    Authenticator: abc
    [This is a response to a request in frame 3]
    [Time from request: 0.001690000 seconds]
    Attribute Value Pairs
        AVP: l=14 t=Calling-Station-Id(31): 49xxxxxxxxx
            Calling-Station-Id: 49xxxxxxxxx
        AVP: l=26 t=User-Name(1): user@domain
            User-Name: user@domain
        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=9 t=NAS-Identifier(32): starent
            NAS-Identifier: starent
        AVP: l=6 t=Service-Type(6): Framed(2)
            Service-Type: Framed (2)
        AVP: l=6 t=Framed-Protocol(7): GPRS-PDP-Context(7)
            Framed-Protocol: GPRS-PDP-Context (7)
        AVP: l=6 t=NAS-Port-Type(61): Wireless-Other(18)
            NAS-Port-Type: Wireless-Other (18)
        AVP: l=12 t=Vendor-Specific(26) v=Starent Networks(8164)
            VSA: l=6 t=SN1-GTP-Version(62): GTP_VERSION_1(1)
                SN1-GTP-Version: GTP_VERSION_1 (1)
        AVP: l=12 t=Vendor-Specific(26) v=Starent Networks(8164)
            VSA: l=6 t=SN1-Service-Type(24): GGSN(4)
                SN1-Service-Type: GGSN (4)
        AVP: l=11 t=Called-Station-Id(30): domain
            Called-Station-Id: domain
        AVP: l=6 t=NAS-Port(5): 77xxxx
            NAS-Port: 77xxxx
        AVP: l=34 t=User-Password(2): Encrypted
            User-Password (encrypted): abcd...
        AVP: l=6 t=Framed-IP-Address(8): 192.x.x.x
            Framed-IP-Address: 192.x.x.x (192.x.x.x)
        AVP: l=22 t=Vendor-Specific(26) v=Merit(61)
            VSA: l=16 t=Merit-User-Id(222): user
                Merit-User-Id: user
        AVP: l=17 t=Vendor-Specific(26) v=Merit(61)
            VSA: l=11 t=Merit-User-Realm(223): domain
                Merit-User-Realm: domain
        AVP: l=6 t=Service-Type(6): Framed(2)
            Service-Type: Framed (2)

As you can see, all Starent VSAs were decoded and you even see the other VSAs which couldn’t be decoded because Wireshark’s RADIUS dissector died.

This is not a bug; it’s a discussion going on for years, for instance, here: Bug 6243 – Wireshark RADIUS Starent dictionaries need an update