Unfortunately, the code in gen_valpairs that parses the packet ignores
the attribute length for all IP addresses and integers except to
advance to the next attribute, so the debugging output generated
will not tell us if it is an attribute length that got messed up or not.
Assuming this version of ComOS was tested with Livingston's version of
Radius, it stands to reason that Livingston's code is somehow not
affected by this. So, looking at Livingston's code, they ARE doing
two things differently when parsing the buffer:
1) Livingston breaks out of the loop silently (ie. assumes the
packet has no more attribute/value pairs) when receiving an
attribute with length less than 2; Merit breaks out if they
receive one with length less than 0.
2) Livingston has an extra check to ensure that the attribute length
is less than AUTH_STRING_LEN (which is 128 I believe). Any attribute
with a larger length is ignored (with a message) and the next attribute
parsed.
It would be interesting to get a dump of the entire received UDP
packet to see where things are going wrong ....
Brad Debroni
BC Systems Corporation
bdebroni@net.gov.bc.ca
> It core dumps with this:
>
> get_radrequest: Request from cc784e09 (ts21.ais.net[1026]) code = 4, id =
> 52, len = 94
> Acct-Session-Id = "00000006"
> User-Name = "whitting"
> NAS-IP-Address = "204.120.78.9"
> NAS-Port = 7
> Received unknown attribute 61
> of length 4: 0x00000000
> Acct-Status-Type = Start
> Acct-Authentic = RADIUS
> Service-Type = Framed
> Framed-Protocol = PPP
> Framed-IP-Address = "206.225.198.6"
> Received unknown attribute 128
> of length 242:
> 0x0800C0F40706000000010806CEE1C00F0000000000000000000000000000000
> 00000000000000000000000000000000000000000000000000000000000000000000000000000000
> 00000000000000000000000000000000000000000000000000000000000000000000000000000000
> 0000000000000000000000000000000000000
> ^C
> [1] + Segmentation fault ./radiusd -p 1645 -q 1646 -x -z (core
> dumped)
Brad Debroni
BC Systems Corporation
bdebroni@net.gov.bc.ca