New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Quota use continues to count failed access attempts / negative #20

Closed
kleinig opened this Issue May 7, 2012 · 3 comments

Comments

Projects
None yet
2 participants
@kleinig
Contributor

kleinig commented May 7, 2012

9 kleserver Kleing 8.0 GB -830969.0 B 4.0 GB 1 33.0 B/s Yes More...

fileserver had used all it's quota again, gathering it just went over little before tollgate caught it, but is this what you want to display? (-830969.0 B)

@micolous

This comment has been minimized.

Owner

micolous commented May 7, 2012

What that's representing there is failed attempts to continue to consume quota, even after it has been exceeded.

I don't believe there's any time delay between tollgate catching it (despite synchronisation cron jobs being every 10 minutes) -- that's all done in-kernel, and the kernel knows how much quota a user should have available. And when that synchronisation happens, tollgate updates the values in the kernel from what it has in the database (because you might be using CARP or some other shared-database setup).

The sequence in the firewall goes something like this:

  1. If the site is an unmetered host, allow it and stop processing.
  2. If no quota is available or a connection to a blacklisted service, and this is the first packet in a TCP connection on port 80, redirect it to the captivity handler and stop processing.
  3. If this is a blacklisted service, reject the packet and stop processing.
  4. Increment the quota usage counter.
  5. If quota is available, decrement the quota available counter and allow the traffic and stop processing.
  6. If the traffic hasn't been processed at this point, reject it and stop processing.

The reason for this complex sequence is that it's actually crossing a few different firewall tables, and then going through different chains.

I could fix this by adding a rule before step 4 such that if there is no quota available, immediately reject the packet and stop processing.

I like to continue to have the counters "go into negative" as this can identify when there is a synchronisation issue, like a user still being unmetered when they shouldn't be, or if there is some issue where the quota remaining counter in the kernel is too high, or if there are multiple instances of tollgate on the same database and the user has actually used up quota before a synchronisation event.

micolous added a commit that referenced this issue May 8, 2012

Prevent tollgate from counting internet usage if the packet would not…
… be allowed through, causing big negative numbers. Potential fix for issue #20, however will require some more testing.

micolous added a commit that referenced this issue May 8, 2012

@micolous

This comment has been minimized.

Owner

micolous commented May 8, 2012

I've shuffled the rules about, but I'm going to need to do some more testing before this gets pushed anywhere.

I've merged the positive and negative counters, because it seems you can call the same filter module in iptables twice and it appears to behave. So the process will go something like (from step 4):

  • If quota is available, decrement the quota available counter, increment the quota usage counter, allow the traffic and stop processing.
  • If the traffic hasn't been processed yet, reject it and stop processing.

I also want to find out which kernel versions, if any, do not allow you to have the same iptables "matches" extension called multiple times in the same rule. It appears to work locally on kernel 3.2.0.

@micolous

This comment has been minimized.

Owner

micolous commented May 11, 2012

The patch appears to work correctly. Closing this now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment