Re: ppp RADIUS accounting bug
Hello! So sending interim update packets won't help. Like I said :) looking for someone who supervises my patch and commit it if no problems will be founded. this can be a problem :-) This is the problem now :) I'm wondering if I only one useing ppp with RADIUS accounting with FreeBSD. Regards, Boris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ppp RADIUS accounting bug
Hi, On Wed, 19 Nov 2003, Boris Kovalenko wrote: > > >The RFC says: > > > >5.4. Acct-Output-Octets > > > >blabla > > > >can only be > > present in Accounting-Request records where the Acct-Status-Type > > is set to Stop. > > > >It looks like, that these counters must not present in accounting updates. > > > You are right, but your words - "but a patch could be written :-)". > Again, I'm talking not about UPDATE packets and presence of any > attributes in RADIUS requests. I'm talking about wrong handling of > Acct-Input-Octets & Acct-Output-Octets with current PPP RADIUS > implementation. How this will be done, by implementing RFC2869 support IMHO this would be the right way, because RFC 2869 definitely says: "Note that all information in an interim message is cumulative (i.e. number of packets sent is the total since the beginning of the session, not since the last interim message)." So sending interim update packets won't help. > looking for someone who supervises my patch and commit it if no problems > will be founded. this can be a problem :-) bye, -- --- -- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 --- -- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ppp RADIUS accounting bug
The RFC says: 5.4. Acct-Output-Octets blabla can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop. It looks like, that these counters must not present in accounting updates. You are right, but your words - "but a patch could be written :-)". Again, I'm talking not about UPDATE packets and presence of any attributes in RADIUS requests. I'm talking about wrong handling of Acct-Input-Octets & Acct-Output-Octets with current PPP RADIUS implementation. How this will be done, by implementing RFC2869 support or just by resending STOP request N times is not so important, but somehow this should be done. I may try to write patch myself, but I'm looking for someone who supervises my patch and commit it if no problems will be founded. Regards, Boris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ppp RADIUS accounting bug
Hi Boris, On Wed, 19 Nov 2003, Boris Kovalenko wrote: > Hello! > > Standard PPP does not support UPDATE packets, and of course (as my but a patch could be written :-) > RADIUS knowledge) the counters should not be resetted, because RADIUS > updates the same record. The RFC says: 5.4. Acct-Output-Octets blabla can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop. It looks like, that these counters must not present in accounting updates. bye, -- --- -- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 --- -- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ppp RADIUS accounting bug
Hello! Standard PPP does not support UPDATE packets, and of course (as my RADIUS knowledge) the counters should not be resetted, because RADIUS updates the same record. Regards, Boris Michael Bretterklieber wrote: Hi, On Wed, 19 Nov 2003, Boris Kovalenko wrote: Hello! 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? How about sending periodic RADIUS accounting updates? After each accounting update the counters could be reset, but I'm not sure whether this is RFC compliant, i.e. whether allways the complete value has to be send or whether the counters could be reset, after each update. For Mpd we implemented it without resetting the counters, but maybe that's not 100% right. bye, -- --- -- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 --- -- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ppp RADIUS accounting bug
Hi, On Wed, 19 Nov 2003, Boris Kovalenko wrote: > Hello! > > 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? > How about sending periodic RADIUS accounting updates? After each accounting update the counters could be reset, but I'm not sure whether this is RFC compliant, i.e. whether allways the complete value has to be send or whether the counters could be reset, after each update. For Mpd we implemented it without resetting the counters, but maybe that's not 100% right. bye, -- --- -- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 --- -- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ppp RADIUS accounting bug
Hello! 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]"
Re: ppp RADIUS accounting bug
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. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ppp RADIUS accounting bug
Hello! 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. Regards, Boris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
