#1 corrupted output with large packets

[Roy Fellows]

I have been using Radstock to trace some radius traffic, I am specifically interested in the
Vendor-Specific permit attributes. But radstock seems to have display problems if there are too
many attributes in the frame I'm looking for or a nearby frame.

Below is some sample output from radstock called with radstock -T -K port 1645

Accept (99) - 111.222.33.8:1645 <- 33.2.11.106:1645 (L38)
[09:28:54]
Service-Type Len 6 Framed-User
Framed-Protocol Len 6 PPP
Framed-IP-Address Len 6 255.255.255.254
254.40 0.0.0.0"
Proxy-State Len 15 "xxxxxxxxxxxxx"
Service-Type Len 6 Framed-User
Framed-Protocol Len 6 PPP
Framed-IP-Address Len 6 255.255.255.254
Framed-IP-Netmask Len 6 255.255.255.255
Vendor-Specific Len 52 "*****.ip:inacl#1=permit ip any 994.12.9.34 0.0.0.0"
Vendor-Specific Len 52 "*****.ip:inacl#1=permit ip any 994.12.9.38 0.0.0.0"
Vendor-Specific Len 54 "*****0ip:inacl#1=permit ip any 994.13.82.242 0.0.0.0"
Vendor-Specific Len 52 "*****.ip:inacl#1=permit ip any 994.12.6.57 0.0.0.0"
Vendor-Specific Len 53 "*****/ip:inacl#1=permit ip any 994.14.65.68 0.0.0.0"
Vendor-Specific Len 55 "*****1ip:inacl#1=permit ip any 994.101.52.141 0.0.0.0"
Vendor-Specific Len 54 "*****0ip:inacl#1=permit ip any 995.14.254.17 0.0.0.0"
Vendor-Specific Len 54 "*****0ip:inacl#1=permit ip any 995.14.254.31 0.0.0.0"
Vendor-Specific Len 54 "*****0ip:inacl#1=permit ip any 995.14.254.39 0.0.0.0"
Vendor-Specific Len 54 "*****0ip:inacl#1=permit ip any 995.14.254.40 0.0.0.0"
Proxy-State Len 15 "xxxxxxxxxxxx"

This appears to be two different radius packets, the first 3 lines are from one request, from the
2nd Service-Type to 2nd Proxy-State this is another packet.

The 2nd example is aparently a request with a filter, which does not make sense.

Request (b8) - 33.2.111.141:1645 -> 11.2.33.106:1645 (L126) [09:34:05]
NAS-IP-Address Len 6 33.2.111.141
NAS-Port-Id Len 6 147
NAS-Port-Type Len 6 ISDN
User-Name Len 33 "testtest02@asampleispuser.co.uk"
Called-Station-Id Len 12 "8459999999"
Calling-Station-Id Len 12 "2081112222"
CHAP-Password Len 19 "**E*T****X***l*R*"
Service-Type Len 6 Framed-User
Framed-Protocol Len 6 PPP
254.40 0.0.0.0"
Proxy-State Len 15 "XX00000000067"
Service-Type Len 6 Framed-User
Framed-Protocol Len 6 PPP
Framed-IP-Address Len 6 255.255.255.254
Framed-IP-Netmask Len 6 255.255.255.255
Vendor-Specific Len 52 "*****.ip:inacl#1=permit ip any 994.12.9.34 0.0.0.0"
Vendor-Specific Len 52 "*****.ip:inacl#1=permit ip any 994.12.9.38 0.0.0.0"
Vendor-Specific Len 54 "*****0ip:inacl#1=permit ip any 994.13.82.242 0.0.0.0"
Vendor-Specific Len 52 "*****.ip:inacl#1=permit ip any 994.12.6.57 0.0.0.0"
Vendor-Specific Len 53 "*****/ip:inacl#1=permit ip any 994.14.65.68 0.0.0.0"
Vendor-Specific Len 55 "*****1ip:inacl#1=permit ip any 994.101.52.141 0.0.0.0"
Vendor-Specific Len 54 "*****0ip:inacl#1=permit ip any 995.14.254.17 0.0.0.0"
Vendor-Specific Len 54 "*****0ip:inacl#1=permit ip any 995.14.254.31 0.0.0.0"
Vendor-Specific Len 54 "*****0ip:inacl#1=permit ip any 995.14.254.39 0.0.0.0"
Vendor-Specific Len 54 "*****0ip:inacl#1=permit ip any 995.14.254.40 0.0.0.0"
Proxy-State Len 15 "XX00000000067"

I am getting valid Accepts with a smaller number of access list entries, so I am assuming the
problem could be related to the radius frame size.

I have run some simultaneous snoops and radstock runs. The data in the snoop trace looks valid,
and I found an unrelated snoop packet from which the 2nd half of radstock output comes from.

I have changed the ip addresses in the samples, but I have not changed the layout. All the
"broken" frames have the last 14 bytes of the last permit line printed from the first column with no
leading ".

[Steve Campbell]

Logged In: YES
user_id=345205

I suspect this could be due to the way radstock handles
fragments in the process routine in process.c. It treats
each fragment as if it were a complete segment which is
wrong.

The quick fix would be to just process the first fragment of
a segment and drop successive fragments.

The complete fix would be to implement fragment buffering
and re-assembly and only process a segment once it's
complete.

Paul, want me to have a crack at this ?

Steve

[Nobody/Anonymous]

Logged In: NO

Looks like this project is orphaned :(

Anyway, it appears the the problem is due to buffer overflow
in the output routines. A quick hack to fix this is to make
the output buffer larger (A better fix would be to implement
proper buffer management). In my case I changed line 278 in
process.c from:

static char tmpbuf[LBUFSIZE], longbuf[LBUFSIZE], hdrbuf[132];
to
static char tmpbuf[LBUFSIZE], longbuf[LBUFSIZE*10], hdrbuf[132];

Ed.
eddie@saix.net
This allocates a 10k buffer for the output text which seems
to work for me (so far). I can now see those big accounting
packets without corruption.