Ticket #596 (closed Bug report: fixed)

Opened 10 years ago

Last modified 10 years ago

Time-based Abuse Control Window not working properly

Reported by: anonymous Owned by:
Priority: high Milestone: Not yet assigned to a Milestone
Component: Auth server, Authentication, permissions and access control Version:
Keywords: Cc:

Description

Hi, I wanted to post this here because I couldn't find any other ticket that was having a similar problem.

I've installed wifidog (both the gateway and the auth server on the same system) on a Debian Lenny box. Everything works wonderfully. Since I have this set up for our guest network, however, I would like to set some limits with the Abuse Control Window. For test purposes, I set a window of 20 minutes and a connection duration limit of 10 minutes. After staying connected for longer than 10 minutes, I am not kicked off of the network (as I am with a bandwidth limit - which also works fine). Instead, I am not given an error until after go back to the Wifidog login page, log out, then log back in. Of course, I would like a user to be directed back to the login page or whatever as soon as possible after the 10 minute limit.

Any ideas? Any help is greatly appreciated.

Some extra info if needed: My CheckInterval? is at its default 60, with the Timeout at the default 5. My DHCP lease time is 600 seconds (But I didn't change the max, still at 7200). I did find a patch for fw_iptables.c somewhere that seemed pretty recent. I made the necessary changes (in two spots referenced in the ticket - I'm sorry I don't remember the number), but that also did not seem to work.

Thank you.

Attachments

stats.JPG Download (114.9 KB) - added by anonymous 10 years ago.
Stats of test account while still in use

Change History

  Changed 10 years ago by benoitg

  • priority changed from normal to high
  • summary changed from Abuse Control Window not working properly to Time-based Abuse Control Window not working properly

Thank you for your very complete bug report. Just to make sure I understand correctly, what you are saying is that:

  • Abuse control using bandwidth limits work fine (including kicking out the user mid-connection)
  • Abuse control using time limits does NOT kick out the user. In your scenario, a user is still connected after 15 minutes.
  • If however the user manually logs out after 15 minutes, he will receive an error message (If so can you give us the exact message).

Is that all correct?

  Changed 10 years ago by anonymous

Yes, that is all correct.

I don't have the exact error message at the moment, but it says something along the lines of "An error has occurred while trying to log in. In the last 20:00 period, you were connected for 15:32 which exceeds the network limit of 10:00." Then I believe it references a file (either .html or .php) in the wifidog auth server directory.

If that is not helpful, I can get the exact message to you on Monday.

Thank you for responding so quickly.

  Changed 10 years ago by anonymous

Okay, here is the exact error message I receive:

Detailed error was: Uncaught Exception During the last 00:20:00 period, you were online
for a duration of 00:15:23.039027 throughout the network, which exceeds the 00:10:00 limit
for the entire network. 
(0) thrown in file /var/www/wifidog-auth/wifidog/classes/User.php, line 631
#0 /var/www/wifidog-auth/wifidog/login/index.php(208): User->generateConnectionToken()
#1 {main}

Also, on my portal page I added the User usage information content that tells me how long I've been connected/my bandwidth usage for both the node and the network. I noticed that since I did not have a time limit for my node (I only have one), there was an "unlimited" time limit set for the node but still the 10 minute limit for the network. Could this be the issue? I will try now to set a 10 minute limit for both the node and the network - but I suppose this may still potentially be a bug.

  Changed 10 years ago by anonymous

Alright, another update.

I just tested it having a 10 minute limit set on both the network and the node; however, I ended with the same result - it does not disconnect me and errors when I log out and back in.

  Changed 10 years ago by anonymous

One more update that might be interesting:

While logged onto my test account, I went to the off-site login page using the external IP and logged in as my administrator account. From there, I generated the statistics page for the test account (attached picture).

You will notice that the Time Spent category has an N/A for the most recent entry, while the account is still INUSE. Is this where the problem lies? Does the program not calculate time spent while the account is still active (I thought about this when I noticed there was no timer shown for a client when I ran

/etc/init.d/wifidog status

on my Debian box)?

If that's the case, I hope this at least points you in the right direction for fixing the problem. Thanks again for your help.

Changed 10 years ago by anonymous

Stats of test account while still in use

  Changed 10 years ago by anonymous

One last update hopefully, as I'm sure you guys have enough information to know what the problem is.

After learning a quick thing or two about Postgres, I started pulling up information on my connections to see if the SQL database was keeping track of connection times. I quickly found out that with each conn_id, only two timestamps are kept: timestamp_in and timestamp_out. Of course, timestamp_out doesn't have a value while I'm still connected, because I haven't logged out yet.

I'm assuming that the way Wifidog keeps track of connection times is by comparing these two values (or subtracting one from the other, or whatever). In this case, it ONLY has a connection time value AFTER someone logs out. Therefore, once you've logged in once, you are on indefinitely as far as any time limit is concerned (If the two numbers are subtracted, I suppose it may actually give back a negative value for connection time - which I also assume the Content Filter I mentioned above simply registers as "None").

Of course, I have no idea how one would fix that sort of issue - obviously, since I'm not a programmer of any kind. But I hope this helps you guys in making this piece of software even better.

  Changed 10 years ago by benoitg

Damn, you're on the right track! Indeed, any connection with a NULL timestamp out wasn't counted, which is every active connection!

Fixing it is a little more delicate, but I am working on it.

  Changed 10 years ago by benoitg

I commited an experimental fix in [1413], can you give it a try?

  Changed 10 years ago by anonymous

Hey benoitg, thanks so much for the update. I just tested your fix and here's what I got:

I think the fix technically worked, but I may have run into another issue. After being connected for a little over 15 minutes, I was still connected to the internet with no problem. I went back to the portal page to see if I could figure anything out there and found that my test account was no longer logged in. I don't know if that's what your fix does, but it seems to log me out once I break the connection limit (at least within 5 minutes - which wouldn't be a problem). However, after getting logged out, I was still connected to the internet. When I log back in using my test account, I do not receive the same error message I did before (I was still within the 20 minute abuse control window).

So I think your fix helped, thank you. I'm wondering if maybe this second issue is unrelated and possibly has something to do with my iptables?

  Changed 10 years ago by anonymous

Sorry, I was wrong apparently. The portal page simply says I am logged off, but if I pull up the statistics page for the test account, it still says "N/A" for "Time spent" and that the account is INUSE.

Likewise, the SQL database still has a NULL for the timestamp_out on that connection. So I am not actually disconnected, sorry.

follow-up: ↓ 12   Changed 10 years ago by anonymous

And you're probably getting tired of me posting so much, but I have a new update.

Your fix worked! What I didn't realize when I was looking through your changes is that you edited the code for the NODE connection duration, not the NETWORK one. So I actually ended up taking out the time limit on the node and that's when I got the above results. Now that I put the time limit back in for the node, it works perfectly! (I didn't really notice it until I saw the ContentFilter? that kept track of the information was now actually posting a time, but only for the Node line)

I suppose now if you could fix the code to take into consideration the Network connection duration, that would take care of everything.

Thank you again for your help.

in reply to: ↑ 11   Changed 10 years ago by benoitg

  • status changed from new to closed
  • resolution set to fixed

Replying to anonymous:

And you're probably getting tired of me posting so much, but I have a new update.

Not at all.

Your fix worked! What I didn't realize when I was looking through your changes is that you edited the code for the NODE connection duration, not the NETWORK one. So I actually ended up taking out the time limit on the node and that's when I got the above results. Now that I put the time limit back in for the node, it works perfectly! (I didn't really notice it until I saw the ContentFilter? that kept track of the information was now actually posting a time, but only for the Node line) I suppose now if you could fix the code to take into consideration the Network connection duration, that would take care of everything.

Ok, done [1415], thanks for your help!

Note: See TracTickets for help on using tickets.