Im not sure, but it could have somthing to do with the temp files that are created (maybe I should delete them to).

As far as I know, the temp files are completely overwritten with the amount of data transferred since the last pass-through of the script. Conveniently, this allows you to delete/move last month's usage.db, but not lose any of the bandwidth info that passes through the router while you're doing so. But it also means that other than the very first write to the new usage.db, you shouldn't get any residual bandwidth from last month being put into your current month's usage.db.

How much data is measured for it to go 150mb over, and what are you comparing this "overage" to that makes you deem it an inaccuracy? It is possible that the 150mb is overhead. I can't think of any other explanation? If it is indeed overhead, then you probably DO want that to be in your bandwidth count since your ISP will include it on your bill anyway. Certain things, like Torrents, use a crazy amount of overhead. The bandwidth measurement wouldn't be anywhere close to the size of the file(s) you were downloading.

Firstly, from your answer, I should just leave the traffic files alone and continue to remove the usage.db file only?

Secondly, I should have mentioned what I am comparing it against.

Basically, after I call the custom reset function I created (backs up the /tmp/usage.db and then removes it), I also reset the WAN Traffic monitor data (set it back to 0).

Then I compare the wrtbwmon total usage for users (down and up) against the WAN usage (down and up).

I expect about 3 to 5 MB diff for the down and about 1-2 for the Up, as its a fairly complicated script and reset can mean that some data is lost.

But I expect this differece to not keep on rising.

Ill post a copy of my script that I am using.

Just a quick question in regards to this.

Say the router has been up and running for 5 mins (but wrtbwmon is not running), and then I manually start the wrtmon to start monitoring, does that mean I will lose the data for those first 5 minutes, and wrtbwmon will basically just start collecting data from when I started it or does the iptables record the data so wrtbwmon does not lose any information?

I have been looking pretty closely at the wrtbwmon and I have come across a very interesting issue.

Its to do with the setup command

Basically this step checks to see if a iptables rule has been set up and that its always at rule position 1. If it exists, but its not number 1, then delete it and reassign it.

This will mean that it will get executed first when new traffic comes in (its the first rule)

Once the rule is verified, we then go through all the currently connected IP's (/proc/etc/arp file) and assign the IPs to the rule (Only br0 IPs are added as the grep 'br0' command filters the vlan one out).

Issues: The original version for deleting the rule is iptables -D RRPDT (something like that).

Unfortunately, this does not work on some versions of DD-WRT (or if it worked at all).

If it doesnt work, you get multiple entries for RRPDT in the 'iptables -L FORWARD list'. This is bad, as what this causes it double up or quadruple up (so on) to occur on usage data.

The fix suggested in this topic is to find the line number iptables -L FORWARD --line-numbers | grep RRPDT | awk 'print{1}' and then delete the rule by line number.

This is good in theory, except when the rules move up or down before the delete takes place (everything takes time, no matter how small), which has happened to me...10 times. I now have 10 entries (after 5 hours) for RRPDT in my FORWARD chain rules. I downloaded 10MBs and it was reported as 120MB or something lol.

I hate to think what actual rule I was deleting lol.

Fortunately its easy to detect the cause of the issue. If you usage is really unexpectedly high, its getting counted more than once and you MUST check the iptables for multiple rules.

I finally got wrtbwmon working on my Buffalo WZR-HP-G300NH. Like many, I suffered from the lack of a 'sort' command.
The fact I know next than diddly about Linux slowed me down a bit too. Lots of learning curve. :-)

Anyway, I'm left with a couple of questions:

1) There's a reference to a MAC-to-Name file which associates MAC addresses with machine names (or whatever name you want). The LAN Status page already has a table that includes machine names & MACs. Is there some sort of script (or perhaps somebody would like to write one) that can somehow hook into this "already known" info and generate the file wrtbwmon uses?

2) On the missing 'sort' thing (and again, remember that I know almost nothing about Linux): is there not some way for the script to check if sort is available on the router, and just use cat instead? Rather than making people hand-edit wrtbwmon to change one line?

3) In the table, is it correct to assume that "total down" & "total up" values are "since last router reboot"? Or is it basically "forever"? Somebody earlier mentioned some sort of "by month" upgrade, which would be super-cool. In my specific case though, if this were to become available someday, I'd be hoping for some sort of "definition" of when a month begins, to match my ISP account "month" (ie. my "month" starts at midnight of the 15th of each calendar month).

Thanks to all who are working on this. This particular "feature" is one of the primary reasons I made the leap into the world of DD-WRT in the first place (iptables-based firewall being another).

Thanks for that. The last bit slightly exceeds my comprehension of Linux commands, but I understand enough that I could probably play with it a while. I'm always game to learn new things. :-)

For the first question, what I was actually referring to was the info in the Status->LAN page (keep in mind I'm running the Buffalo-branded DD-WRT so some of my screens may be slightly different).
My page has an "Active Clients" table, which has machine names in the first column, assigned IP in the second, and MAC in the third.
There's also another table on that page called "DHCP Clients", which also has name, IP, MAC columns.

Having said that, I only have about a dozen "active" machines on my network, so it's not like I couldn't make a hand-rolled MAC->Name file easily enough.

What I have bolded is the total bytes that have come through this rule.

Now, any person would think well, if we have this total on the rule, then the SUM of all clients below it (IPs that is has been assigned against) should add up or get very close to it, right?

I understand there is overhead and timing issues between when the packets get read and a new IP gets assigned the rule, but its only 5 to 10 seconds (depending on how you have it set up).

However, I am seeing a larger difference between the sum of the clients and the actual rule total. Its now at 23MBs.

The thing is, the client usage updating is working correctly. The right stuff is getting added to the right MAC etc and going up according to the bytes value.

So, what could be happening?

I only have ideas, but I bet someone with a bit of knowledge around iptables and how the rules have been setup will be able to inform us.

1. Could it be a ghost client? Very unlikely as even the MAC address would be shown on the usage output.

2. Its just overhead thats not getting assigned to the IP's. Like incoming/outgoing traffic that has been blocked by the firewall maybe

3. Becasue the rule is an 'all in' rule, it records traffic over every device that is using the internet. This could mean system calls etc which are not considered clients could be executing web requests etc.

Really I am not too sure.

All I know it the recorded total bytes by the wrtbwmon RULE is very close to the total bytes shown by the WEB UI's WAN monitor. So this proves that the wrtbwmon is recording information correctly.

If anyone is wanting to be clever about this. You could write into the publish script a few lines that pull out the total recorded bytes by the wrtbwmon RULE and display that as the total.

Then total up all the clients usage, and basically work out the amount of data that is not being assigned to any MAC/Client.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou cannot download files in this forum