2012-03-29 - [GRASE-Hotspot] Bug in Archiving code, MAJOR issue, Fix attached (Was Re: Disconnect Active User)

Header Data

From: Timothy White <ti***8@gmail.com>
Message Hash: b64b2142db79aa82a3bc6314c1ace86a570125148c18c6500036f18beb58a757
Message ID: <CAESLx0JtbTJRt-ZMuxxgbjwJDrwo94wP7evtfSn2SW6qoGwHPQ@mail.gmail.com>
Reply To: N/A
UTC Datetime: 2012-03-29 03:57:36 UTC
Raw Date: Thu, 29 Mar 2012 20:57:36 +1000

Raw message 

The problem has been found!
Seems a fix from earlier actually broke it! (Fix was last year, so not
sure how it wasn't noticed until now!)

As I can't access my dev environment, for now here is a patch you can
apply. I also strongly recommend everyone runs the following SQL after
applying the patch to fix any users who are "broken"

UPDATE radcheck SET radcheck.value = 0 WHERE radcheck.Attribute =
'Max-Octets' AND CAST(radcheck.value AS SIGNED INTEGER) < 0

If you don't want to apply the patch, just run this sql nightly and
it'll ensure things are fixed until I can get a new release out.

It's important that everyone realise that if you dont' apply this fix
or run this sql nightly (until I get a release out), any user who has
used up all their quota, will be able to use basically unlimited quota
when they are archived in 2 months time.
Thanks iii for providing data to help find the problem

Tim

On Wed, Mar 28, 2012 at 9:05 PM, iii iii <ii***t@gmail.com> wrote:
> Thanks for your reply Tim.
> I was talking about quota allowance, not bandwidth limit, sorry for the
> terms mix-up :)
>
> After doing a little poking about the radius tables I see that previously
> expired tickets have been somehow allocated a Max-Octets value of large
> numbers such as 18446744073709520803 and 9223372036854775808 in the radcheck
> table, regardless of the group they were in. The numbers vary quite a bit.
> I will manually correct these, but I think I will automatically archive
> expired accounts on expiry to prevent further issues (this has cost me quite
> a bit in "free" quota, as you may imagine).
>
> I have added coaport to the chilli config files, but "netstat..." doesn't
> reveal the port in use by udp and "ps aux | grep chilli" doesn't reveal any
> coaport command-line option in use. I think I may have to do a dist-upgrade
> to get chilli updated properly.
>
> Sorry to hear about your dev machine - may she RIP :'-(
>
>
> On Tue, Mar 27, 2012 at 11:55 PM, Timothy White <ti***8@gmail.com>
> wrote:
>>
>> On Wed, Mar 28, 2012 at 1:44 AM, iii iii <ii***t@gmail.com> wrote:
>> > I have been having a lot of trouble lately with users greatly exceeding
>> > their bandwidth allowance.
>> > My desired solution would be to log out such accounts on a per-minute
>> > basis.
>>
>> Before even going down this path, a user can't exceed their
>> "allowance". If you have set bandwidth limits in the groups (i.e.
>> 256kbps for downlink, and 128kbps for uplink), then the fast the user
>> can download, is 256kbps. If they are downloading at faster than that
>> speed, you have a problem with the setup (maybe you created the groups
>> before Jan and as such the bug fix regarding speed limits wasn't
>> applied at the time, so recreate the groups).
>> If you are talking about quota allowance (so not speed, but actual
>> amount downloaded and uploaded), check that the users are actually in
>> a group with limits. This was something else that changed around Jan,
>> where groups no longer have "limits" applied to the group, but have
>> limits applied to the user at creation time, as defined by the group.
>> So again, if you created these users and/or groups before the change,
>> then you'll need to manually apply data limits (quota) to the users.
>> If you view the user in the "users" display tab, you'll be able to see
>> data limits in the 2nd column (soon to change to "remaining data" same
>> as the time limits changed recently). If that column is blank, the
>> user has no quota for data and can download as much as they want.
>> Bandwidth limits (speed limits) aren't shown there as they apply to
>> the whole group and so can be seen in the group area (I'll eventually
>> make it visible in that area as well).
>>
>> >
>> > I have followed the steps listed on Ticket 28: Ability to disconnect
>> > active
>> > users (http://trac.grasehotspot.org/ticket/28), but the command fails.
>> > >From the command-line I get the following:
>> >
>> > $ sudo /bin/echo "User-Name=blah123" | /usr/bin/radclient -x
>> > 127.0.0.1:3779
>> > disconnect radsecret
>> > Sending Disconnect-Request of id 212 to 127.0.0.1 port 3779
>> > User-Name = "blah123"
>> > Sending Disconnect-Request of id 212 to 127.0.0.1 port 3779
>> > User-Name = "blah123"
>> > Sending Disconnect-Request of id 212 to 127.0.0.1 port 3779
>> > User-Name = "blah123"
>> > radclient: no response from server for ID 212 socket 3
>> >
>> > Googling the issue suggested I add udp port 3779 to my iptables, but
>> > that
>> > still didn't work.
>> >
>>
>> If you read the top of that ticket, you'll see you shouldn't need sudo
>> at all. And as long as you are issuing that command on the machine
>> that the hotspot is running on (which I assume you are as 127.0.0.1
>> refers to the localhost), then it should be working.  The only thing I
>> can think is that the modifications to chilli haven't been made for
>> coaport. I can't currently even test the commands as my development
>> machine is currently dead. Check in /etc/chilli/ for coaport being in
>> the *.conf files. If it isn't, check that the running chilli process
>> has --coaport as a command argument (do something like "ps aux|grep
>> chilli") as that's the other way to pass that option to chilli. If
>> it's not in the conf files, or as a command line argument, then chilli
>> isn't listening for the packets that radclient is sending so you are
>> throwing them at a brick wall.
>> Being udp, there is no establishment of connection to check it's
>> working. Also do 'netstat -u  -l -n' to list all UDP ports listening
>> and check that 3779 is one of them.
>>
>> Hope that gets you somewhere.
>>
>> Tim
>>
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> Grase-hotspot mailing list
>> Gr***t@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/grase-hotspot
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Grase-hotspot mailing list
> Gr***t@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/grase-hotspot
>

Thread