2012-03-29 - Re: [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: 0b7f2c233fd4ac0d9d214a99371b07c167c7c078659dda28e397d2f8c2635f76
Message ID: <CAESLx0Kg6vW6+WwxdP-ZqZoTpyrTkJg68q+Gk+E8FXf2_vFpcA@mail.gmail.com>
Reply To: <CAESLx0JtbTJRt-ZMuxxgbjwJDrwo94wP7evtfSn2SW6qoGwHPQ@mail.gmail.com>
UTC Datetime: 2012-03-29 04:29:06 UTC
Raw Date: Thu, 29 Mar 2012 21:29:06 +1000
Raw message
For anyone who is brave, here is a package you can install with the
fixes, plus a few other fixes that were waiting to be released.
http://dev.packages.grasehotspot.org/pool/main/g/grase-www-portal/grase-www-portal_3.7.4-dev2_all.deb
Please be clear, this is a dev package, because I'm unable to properly
test it atm due my lack of decent computer and dev environment. It
took long enough without my normal computer and environment to fix
this bug, and even longer just to sign this package with my gpg key!
Please consider testing this package, as the bug fixes are very
important for anyone who uses data limits (time limits not so
important). If you do use this package, keep an eye on the list for
any updates or issues, and if you have any issues with it, report back
to the list please.
I will skip version 3.7.4 when I am up and running again, and what
ever the latest 3.7.4-dev package is, that I can then test, it will
become 3.7.5.
Thanks
Tim
p.s. You may add the dev repository to your apt sources, however, at
times it may be broken as it is the dev repository that I push to, to
test, before I push to the one everyone uses
On Thu, Mar 29, 2012 at 8:57 PM, Timothy White <ti***8@gmail.com> wrote:
> 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
>>
>
> ------------------------------------------------------------------------------
> 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
-
Return to March 2012
- Return to “Silvério Santos <SS***s@web.de>”
-
Return to “Timothy White <ti***8@gmail.com>”
- 2012-03-29 (Thu, 29 Mar 2012 20:57:36 +1000) - [GRASE-Hotspot] Bug in Archiving code, MAJOR issue, Fix attached (Was Re: Disconnect Active User) - Timothy White <ti***8@gmail.com>
- 2012-03-29 (Thu, 29 Mar 2012 21:29:06 +1000) - Re: [GRASE-Hotspot] Bug in Archiving code, MAJOR issue, Fix attached (Was Re: Disconnect Active User) - Timothy White <ti***8@gmail.com>
- 2012-03-29 (Thu, 29 Mar 2012 22:07:13 +0200) - Re: [GRASE-Hotspot] Bug in Archiving code, MAJOR issue, Fix attached (Was Re: Disconnect Active User) - Silvério Santos <SS***s@web.de>
- 2012-03-29 (Fri, 30 Mar 2012 06:48:23 +1000) - Re: [GRASE-Hotspot] Bug in Archiving code, MAJOR issue, Fix attached (Was Re: Disconnect Active User) - Timothy White <ti***8@gmail.com>