Yes, unsigned, so we have 4G limit, which may simple be overflowed by (for example) PPPoE connection. Yes, RADIUS standard defines new attributes for big words, but current PPP does not supports it (it, so our knowledge about RFC is useless :) Again, rad_put_int defined u_int32_t parameter, so if a have dowloaded 4.5G (for example) what number will send to radius?
Regards, Boris
Barney Wolff wrote:
On Wed, Nov 19, 2003 at 09:00:01AM +0500, Boris Kovalenko wrote:
I found a serious bug in RADIUS accounting code. The problem is that
OctetsIn and OctetsOut are defined as unsingned long long, but the RADIUS supports only INT32 values, so, when
we're doing rad_put_int(r->cx.rad, RAD_ACCT_OUTPUT_OCTETS, stats->OctetsOut) in radius.c for OctetsOut (and OctetsIn also) we loosing information if OctetsOut is greater then INT32_MAX. This should be fixed.
Note that RADIUS integers are unsigned, so the limit is 2^32-1. Also, RFC2869 defines attributes to hold the high-order parts.
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
