Quota use continues to count failed access attempts / negative

[kleinig]

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]

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]

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]

The patch appears to work correctly. Closing this now.