Strange packet causing radius to crash.
List, 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: http://bugs.freeradius.org/show_bug.cgi?id=381 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. Thanks, schu
Matthew Schumacher wrote:
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":
Can you post the *hex* version of the packet? The "VSA too short" error means that it isn't printing out what's actually in the packet. So... it doesn't say *why* the VSA is too short. And does this crash when the server *doesn't* have that patch?
AVP: l=14 t=Vendor-Specific(26) v=UTStarcom Incorporated(429) [VSA too short]
USR VSA's are: 26 (Vendor-Specific) xx (vendor-length) 0000xxxx (USR vendor-ID) 0000tttt (USR vendor-type) ... (data) i.e. at least 12 bytes long. If the Vendor-Specific attribute is 14 bytes, then it means that the Vendor-Type is likely a 'string' type, and it contains 2 characters of string data. But Wireshark also includes the FreeRADIUS dictionaries. So it may think that the attribute is of type "integer", and should therefore be 4 bytes. Without the *contents* of the attribute, it's impossible to know more. Alan DeKok.
Alan DeKok wrote:
USR VSA's are:
26 (Vendor-Specific) xx (vendor-length) 0000xxxx (USR vendor-ID) 0000tttt (USR vendor-type) ... (data)
That's at least *10* bytes, not 12. (oops) So if the USR VSA is 14 bytes long, that means that there's room for an "integer" or "ipaddr" field. So I don't know why Wireshark would think it was "too short", unless it doesn't support USR VSA's at all.. Alan DeKok.
Alan DeKok wrote:
Can you post the *hex* version of the packet? The "VSA too short" error means that it isn't printing out what's actually in the packet. So... it doesn't say *why* the VSA is too short.
I'm not sure either, I attached the whole packet in hex for your review.
And does this crash when the server *doesn't* have that patch?
It doesn't crash when I omit the patch. My C is very weak so I suspect I did something wrong, but I really need this feature, so muddled though it anyway. While trying to troubleshoot I was able to capture the packet that crashes it. There are more packets like it from the same host that show the same VSA too short that also crash it.
Without the *contents* of the attribute, it's impossible to know more.
Alan DeKok.
Thanks for looking Alan. schu Frame 7285 (197 bytes on wire, 197 bytes captured) Ethernet II, Src: 00:00:0c:1b:51:60 (00:00:0c:1b:51:60), Dst: 00:0f:1f:04:72:fb (00:0f:1f:04:72:fb) Internet Protocol, Src: x.x.x.x (x.x.x.x), Dst: y.y.y.y (y.y.y.y) User Datagram Protocol, Src Port: 1645 (1645), Dst Port: 1645 (1645) 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 AVP: l=18 t=User-Password(2): Encrypted AVP: l=6 t=NAS-IP-Address(4): x.x.x.x AVP: l=6 t=NAS-Port(5): 257 AVP: l=10 t=Acct-Session-Id(44): 16779082 AVP: l=14 t=Vendor-Specific(26) v=UTStarcom Incorporated(429) [VSA too short] 0000 00 0f 1f 04 72 fb 00 00 0c 1b 51 60 08 00 45 00 ....r.....Q`..E. 0010 00 b7 35 4b 00 00 fe 11 43 6c xx xx xx xx yy yy ..5K....Cl@.b.@. 0020 yy yy 06 6d 06 6d 00 a3 96 d2 01 a0 00 9b 1c c1 `..m.m.......... 0030 e8 4a a4 0f 3b 21 68 fd 1a 0c f4 d6 0d fb 01 0b .J..;!h......... 0040 6d 69 63 68 61 65 6c 2e 73 02 12 91 2d 00 79 c7 michael.s...-.y. 0050 6b 8a 98 f7 57 00 ff 9c 01 9c 6f 04 06 40 ba 62 k...W.....o..@.b 0060 04 05 06 00 00 01 01 2c 0a 31 36 37 37 39 30 38 .......,.1677908 0070 32 1a 0e 00 00 01 ad 00 00 98 43 00 00 05 e9 06 2.........C..... 0080 06 00 00 00 02 07 06 00 00 00 01 1a 0e 00 00 01 ................ 0090 ad 00 00 90 19 00 00 00 02 1a 0e 00 00 01 ad 00 ................ 00a0 00 90 1a 00 00 00 10 1a 0e 00 00 01 ad 00 00 90 ................ 00b0 1b 00 00 00 01 1f 02 1e 02 3d 06 00 00 00 00 08 .........=...... 00c0 06 40 ba 62 18 .@.b.
Matthew Schumacher wrote:
It doesn't crash when I omit the patch. My C is very weak so I suspect I did something wrong,
Yup. I don't see why you have to modify anything in src/lib/radius.c, though. It's completely unnecessary. but I really need this feature, so muddled though
it anyway. While trying to troubleshoot I was able to capture the packet that crashes it. There are more packets like it from the same host that show the same VSA too short that also crash it.
If wireshark says that the VSA is too short, then it isn't parsing the USR VSA's properly. The VSA is fine. Alan DeKok.
participants (2)
-
Alan DeKok -
Matthew Schumacher