Re: draft-ietf-radius-accounting-05.txt
Richard Huveneers (richard@hekkihek.hacom.nl)
17 Nov 1996 12:21:04 GMT
In article <199611170812.AAA16921@server.livingston.com>, cdr@livingston.COM (Carl Rigney) writes:
>richard@hekkihek.hacom.nl asks:
>> What I'm worried about is the "Octets outside the range of the Length field
>> should be treated as padding and should be ignored on reception" remark.
>> Looking at the current (2.0) radiusd implementation, I think the entire
>> UDP packet is scanned for attributes, disregarding the Length field.
>
>What makes you say that? rad_accounting() is called by radrespond()
>which is called by rad_request() after it calls radrecv() to construct
>the authreq structure, and radrecv doesn't go past the end of the
>packet as far as I can tell. So padding is ignored, as it has to be since
>attempting to interpret random bytes is unlikely to be useful.
My remark concerned the difference between the 'length' and 'totallen' variable
in the radrecv() source code. The 'length' variable is used to detect the end
of the packet. Unless I misinterpreted the ietf draft, the 'totallen' variable
should be used.
Could you point me to the section of the ietf draft where is stated that 'length'
and 'totallen' should be equal? What if not?
For packets generated by PM's this seems to be true, but the radiusd should not
assume it's talking to a PM.
Regards, Richard.