2011-08-03 - Re: [GRASE-Hotspot] Problem with blocking users and with occasional error on opening anything Google related

Header Data

From: Timothy White <ti***8@gmail.com>
Message Hash: 0f5cb16c541f833cbcc8e941bd0733faef40c7b982ea6fca57b5fb460897867f
Message ID: <CAESLx0+JVer++u7Z+DCf4KGWX3qk1pYqHn-UZ42=imFWtMZWxw@mail.gmail.com>
Reply To: <b1d68b68-5f88-4403-a21a-b4bdc2dadf9a@ATACOGREGA>
UTC Datetime: 2011-08-03 15:19:29 UTC
Raw Date: Thu, 04 Aug 2011 08:19:29 +1000

Raw message 

> The problem we have is with the latest version (v3.3), this problem did not
> exist in previous versions. As most of our users are here for the long-term
> stay, and we charge the internet usage monthly, we were using the Time Limit
> attribute of the users set to 0 minutes to block the users at the beginning
> of the month, to get them to pay. Since version v3.3 GRASE interface does
> not let us set 0 minutes for Time Limit, we can only use 1 minute for
> example. And even when this 1 minute is up for the user, this value goes in
> to negative numbers and doesn't really block the user, the system still
> let's users connect. Previous versions did not let users connect anymore, if
> the limit was 0 or below. I also tried setting Time Limit attribute
> (Max-All-Session) in the database raidus, radcheck table, to 0, but the same
> happens. Users can still connect, and their time limit goes into negative
> values. As I said before, this only started happening with the latest
> version, 3.3, version 3.2 was OK, Time Limit worked as expected, setting
> limit to 0 or anything below that actually blocked users from connecting.

I've just tested with the next version I'm releasing (3.4) which I'll
post links to the list for testing soon. It appears to work for me
with limit set to 0. I've had to make some fixes so it detects that 0
is a valid number (and not "false"). I couldn't see anything that had
changed betweeen 3.2 and 3.3 that should have caused problems, as most
of the changes were in the freeradius stuff. I've done some basic
testing and setting it to 0 does lock me out.

>
> The next problem is I think squid3 problem.. After some time after
> restarting the server, our users start observing a strange behavior with
> opening Google and Youtube or anything google related for that matter, even
> if a site uses Google Analytics, this problem will show. This problem is,
> those sites just stop opening, they get resolved normally, but then it's
> just waiting for eternity.. If you wait long enough, squid throws out an
> error (unfortunately everything works right now, so I can't provide the
> exact error) and that is it.. The error has something to do with IPv6 and
> timeout if I remember correctly, but I'll provide the exact error the next
> time I get it.

My guess is that it's a DNS problem. Maybe you have IPv6 available but
not working properly? Just check to see if the gateway machine has
IPv6 available, and if so, if it's working when the problems occur.
Having said that, Google won't serve IPv6 address by default to
prevent this very problem (and instead most peoples IPv6 tunnel
provider will have it setup so you can do IPv6 google).
In the next release or one shortly after, I'm going to be making
dnsmasq a requirement again, as we seem to have the odd DNS issue that
will be nicely solved by dnsmasq. Maybe that'll fix it for you.

Tim

Thread