From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 23:17:16 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68BB616A4CE; Tue, 18 Nov 2003 23:17:16 -0800 (PST) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D1F143FE0; Tue, 18 Nov 2003 23:17:14 -0800 (PST) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9p2/8.12.9) with ESMTP id hAJ7H4Tb039365; Wed, 19 Nov 2003 02:17:04 -0500 (EST) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9p2/8.12.9/Submit) id hAJ7H3sq039364; Wed, 19 Nov 2003 02:17:03 -0500 (EST) (envelope-from barney) Date: Wed, 19 Nov 2003 02:17:03 -0500 From: Barney Wolff To: Boris Kovalenko Message-ID: <20031119071703.GA38863@pit.databus.com> References: <3FBAEAC1.7090709@tagnet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FBAEAC1.7090709@tagnet.ru> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.38 cc: brian@Awfulhak.org cc: freebsd-current cc: freebsd-stable Subject: Re: ppp RADIUS accounting bug X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2003 07:17:16 -0000 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.