Monitoring bandwidth used per user. (Because metered internet.)

Not sure, but there may may something strange with ipv6 reporting in 17.01

The app has worked ok in master, and reports nicely both ipv4 and ipv6 traffic. But so far in 17.01 I have got only ipv4 stats and ipv6 if 0, but I have not yet analysed if ipv6 is included in the ipv4 numbers or if they are missing from the stats.

And this might be just due to my environment & config, but I thought to highlight the issue in any case.

1 Like

Hmmm... I can confirm that the IPv6 tab shows zero data for v6 with 17.01.0.

I have a v4-only isp, so I didn't expect to see any v6 traffic. But I suppose that some internal traffic might have been v6. I don't have time to investigate now, sorry.

jow suggested by email that I should test installing kmod-nf-conntrack6 in 17.01, but I can't test it right now.

Hi Rich. Why are you on Lede 17.01.0, when there is Lede 17.01.2 (which I'm on)? :confused:

ENOTIME. It's working fine, my family depends on it, and I haven't gotten 'round to updating. It's on the list to do when things slow down (summer's pretty busy here - I'm associated with a hospitality business on a pond in Lyme NH :slight_smile:

PS Do you see IPv6 traffic with 17.01.2?

Probably not.
I tested with 17.01 HEAD that 17.01.2 + newer stuff, and did not see IPv6 traffic.

I made a test build of master with Qualcomm Fastpath using @dissent1 patch.
On that build, nlbwmon (new netlink based per-host traffic stats app from @jow ) did not report ipv6 stats but seemed to report ipv4 normally.

New build from the same commit without fastpath, and nlbwmon again reports ipv6 stats.

Looks like fastpath may cause peculiar problems for netlink-related stuff.

I had earlier noticed similar missing ipv6 data in nlbwmon with 17.01, so this might not be exactly about fastpath, but in general about netlink in some conditions.

just install a captive portal to add per bandwidth limitations per user. You can also set bandwidth quotas as well.

You can block the MAC address of the device.

I'm on LEDE Reboot 17.01.2 and I don't see any IPv6 traffic.

But could this mean it's simply because I'm not using IPv6? How can I double check?

Just surf to ipv6.google.com
You can reach that search engine only with ipv6. If you see that page, you are using ipv6.

1 Like

Eh, I had it installed and did a heap of IPV6 speed tests - no usage displayed in nlbwm under ipv6, think it may be a bug.

With my recent 17.01 build from two days ago, nlbwmon does report ipv6 stats. On the other hand, I have also noticed the absence of ipv6 data at least once after flashing a master build.
I guess that there may be some kind of startup race condition, or something, which may make nlbwmon to fail getting the ipv6 stats sometimes. Maybe something that @jow might look into. Delayed startup for nlbwmon?

Just a me too. I installed your LEDE master build from 20170814 on a wndr3700v2 and the IPv4 stats appear, but so far no values in the IPv6 fields (I will report back if IPv6 counters will start to show up after reboots).

Best Regards & many thanks for your great builds!

Looks like the nlbwmon ipv6 data absence is a startup race-condition problem, or something like that.

I have ipq806x R7800 master r4696-df3295f50e and it has not shown IPv6 stats after the flashing yesterday. Only ipv4 stats have been visible.
Now I just restarted the nlbwmon service without doing anything else.
And nlbwmon started to count also ipv6 traffic...

I guess that the ipv6 ramp-up in the boot can take so long (odhcpd and odhcp6c) that nlbwmon starts before the ipv6 interface is properly up and misses the data.

Not sure about that, as I have not tried to look closer into source code, but that is my educated guess.

Okay, restarting nlbwmon got me some IPv6 counter increases, but these do not match what I expect. I ran several speedtests (dslreports, either IPv4 or IPv6) and only with IPv4 I see counter increases that roughly match the tests transferred data volume, IPv6 seems to severely underestimate the volume... Not sure why.

thanks @hnyman. Going to ipv6.google.com worked for me. So that means I'm using ipv6. Now I'm wondering whether the bandwidth stats collected by nlbwmon are incomplete because of nlbwmon's ipv6-collection issue.

That should be easy to test, go to dslreports get a free registration and configure both an IPv4 and an IPv6 test, run both and see whether the nlbwmon counters increase (in the detailed information there is a view into textual output from the test that ends with reporting the actually transferred volume for both directions). In my quick test I just watched whether IPv6 tests increase the IPv6 counters (result the counters do not show all the IPv6 volume) and whether the IPv4 test increased the IPv4 counters (result: counters increased by the correct order of magnitude, do not expect the counter increases and the transferred volume to be identical, they are measured on different network layers after all). I did not test whether the IPv6 test increased the counters associated with my testing computer (I believe for your use case that is the relevant test, you want to correctly split a bill by usage and do not care about which protocol was used, correct?)).

Best Regards

P.S.: PLease note that the counter update happens every 30 seconds by default, so give at least 30 seconds after a speedtest for the couters to increase; also perform this test in an otherwise quite period.

1 Like

Moeller, Thanks so much for your helpful reply. :slight_smile:

I'm on a metered connection :blush:. How much bandwidth do the tests use?

This is bad, isn't it?

Not sure if correct order of magnitude is enough for me, is it? I need nlbwmon's counters to be accurate. Don't I need the counters to tell me -- for example -- that 492.5 MB of bandwidth was used when a 492.5 MB iso was downloaded?

Maybe I'm a noob for asking, but shouldn't that be my expectation? If nlbwmon's counter increases and the transferred volume aren't identical, then nlbwmon is still not doing the job I wish it did. Am I misunderstanding?

Oh, that's too bad. Wish you did. :wink:

Correct, I don't care whether the protocol I used is torrent or http or https or IRC or VoIP or ftp or whatever. I just need a way to measure my bandwidth use, just as it looks from the perspective of the ISP.

Hmmm... it will be quiet on the wifi. but the wired connection may be active. Will that be a problem? I'm guessing that this will be okay, right?

You forget the protocol overhead. Packet reqs, acks, resends etc. For example, if you transfer a 100 MB file, you have typically transferred at least 100+3 MB download plus maybe 2 MB upload (packet requests, acks), making the down+up counters to show maybe 105 MB total traffic. If you experience packet loss (bad line, jam, QOS throttling), there may even be higher amount of re-transmissions.

I think that TCP/IP overhead (for TCP) is typically 2-4% in the optimal case.

And same limitation will hold true for vnstat, darkstat etc. They all measure the traffic from some network layer, but counter will not match the exact filesize of the transferred size.

But if you assume that each of these tools makes similar errors for all users, you can still use the traffic data for calculating the proportion that each has used internet, but not exact byte count.

3 Likes