I’m regulary 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]
(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 filesystem 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
If you like this article, like, share or comment.