Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (ASCEND) Ascend Patch 5.0ap23?



When did this Radius accounting bug become active?  
...which patch release?

We're running 5.0ap16... and we've had 2 people complain that 
their time was incorrectly billed... does the 5.0ap16 release 
have the Radius accounting bug?  Or is it that these customers 
just don't realize how much time you can burn while surfing 
the 'net...??

In addition, our K56Flex users experience frequent disconnects
with this particular patch release.



At 08:52 AM 9/9/97 -0400, Jason Nealis wrote:
>
>Agreed, But isn't harder to try and explain to your users why there
>modems are dropping carrier from 5-10 minutes, Why do they get massive
>CRC errors when dialing into your service? Why your SLIP accounts
>don't work anymore? 
>
>
>
>> Let me tell you - I have a real hard time explaining all this to our
>> corporate auditors. They want to know how I can prove all the usage data
>> is getting into RADIUS from the Max.
>> 
>> As you can see - I can't prove it - but I *can* prove that a few things
>> just aren't right. :(
>>
>
>True, But I'd rather try to explain that to the suits rather answer
>thousands of tech-support phone calls. Not to come down on your view, Your 
>points are very valid, But also can be held to just about every OS release
>from Ascend.
>
>Jason Nealis
>Director Internet Operations
>Network Access
>Erols Internet
>
>
>On Tue, 9 Sep 1997, Josh Bailey wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> 
>> On Tue, 9 Sep 1997, Jason Nealis wrote:
>> 
>> > The accounting data records 0.0.0.0 as the I.P. address assigned to that
>> > users, (So this pretty much won't allow you track down abusive users) You
>> > will not be able to match user to ip.
>> 
>> Hmmm. :)
>> 
>> Well - I took this debug from 50ap13.
>> 
>> Seems now in p23, the accounting structure now gets initialised with all
>> zeros - but still doesn't get updated properly with the correct value.
>> 
>> So - IPCP may happen, but addRadAcctFrameProtoInfo() doesn't get called -
>> or worse, it does get called and gets passed a list. Someone doesn't keep
>> track of their pointers and the fields point to free()'d garbage.
>> 
>> Point being - if I can't trust the IP address, what about the session
>> times?
>> 
>> Let me tell you - I have a real hard time explaining all this to our
>> corporate auditors. They want to know how I can prove all the usage data
>> is getting into RADIUS from the Max.
>> 
>> As you can see - I can't prove it - but I *can* prove that a few things
>> just aren't right. :(
>> 
>> Ascend?
>> 
>> RADIF: _radProcAcctRsp: user:<23:DELETED-FOR-SECURITY>, ID=22
>> RADACCT:addRadAcctFrameProtoInfo: updating framed proto=1 and address
-63.-88.20.43
>> RADACCT-183:stopRadAcct
>> RADACCT-183:_endRadAcct: STOP was delayed
>> 
>> - --
>> Josh Bailey (mailto:joshb@xtra.co.nz)
>> 
>> Internet Network Specialist                     Voice (DDI): +64-9-355-5923
>> Telecom Internet Services                       Voice (Mob): +64-25-514-899
>> Extension: 93423 (Lvl. 4, 120 Mayoral Dve)      Fax:         +64-9-355-5260
>> Private Bag 92028, Auckland, NZ                 Pager:       +64-26-114-448
>> 
>> PGP public key available at http://www.pgp.net/pgpnet/pks-commands.html
>> 
>> DISCLAIMER: The contents of this message are entirely my own opinion, not
>> necessarily that of my employer.
>> 
>> 
>> -----BEGIN PGP SIGNATURE-----
>> Version: 2.6.3ia
>> Charset: noconv
>> 
>> iQB1AwUBNBUo1fle+GEe9W4hAQGEPgL+I34mh2VroE4gGedTdxcSE9OUQxjUseX1
>> Y5sio9irh1qxCD0bUa4mnS29Eix4o8kL4cr3vffnL8AiaB3W5XOGi0TEAItvVorV
>> kpgy9r19VAggOyGE9RDzXq2E7Fiyb+wL
>> =Xe3p
>> -----END PGP SIGNATURE-----
>> 
>
>++ Ascend Users Mailing List ++
>To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
>To get FAQ'd:	<http://www.nealis.net/ascend/faq>
>
++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>
References: