Make sure you reboot after disabling NAT acceleration, otherwise it will still be active.
The traffic monitoring reads its data from the network interface, which is the same closed source code as on stock firmware.
Alright, I reinstalled the beta2 firmware and then clicked the Reboot button in the UI. HW Acceleration remained disabled the whole time. Using all the same settings I was using with the stock firmware.
After Reboot, the 24Hour Internet Connection (WAN) shows:
0.00 KB/s 0.03 KB/s 5.91 KB/s 2,414.08 KB
0.00 KB/s 0.00 KB/s 0.10 KB/s 10.26 KB
Transferred a 76 MB file up and then downloaded it twice via FTP. After doing this, 24hour Internet Connection (WAN) shows:
1826.39 KB/s 50.21 KB/s 139316.44 KB/s 4,236.77 MB
0.00 KB/s 48.26 KB/s 136445.72 KB/s 4,072.24 MB
Note: my ISP is 150(down)/10(up) Mbps. So either the Traffic Monitoring code isn't actually the same between the stock firmware ( RT-AC68U_3.0.0.4_384_20648-g21e3702.trx ) and yours or the code communicating with it is doing something different or interpreting data wrong.
I doubt this would impact it, but I did notice the following concerning the USB stick where I store the traffic data. Would this impact it any? It seems to read and write the data on there fine.
May 10 14:10:12 kernel: tfat info: FAT32 volume name 'KINGSTON', version 0.0.
May 10 14:10:12 kernel: tfat warning (device sda1, pid 711): fat_fill_super(): FAT volume KINGSTON is dirty. You should unmount and repair it.
May 10 14:10:12 hotplug[681]: USB vfat fs at /dev/sda1 mounted on /tmp/mnt/KINGSTON
May 10 14:10:12 usb: USB vfat fs at /dev/sda1 mounted on /tmp/mnt/KINGSTON.
Edit:
I changed the traffic to be stored in RAM, transferred files and the data in the 24hour looked like it should. So, I went the Network Map and click the USB Drive and did a Health Scan which cleared the dirty flag.
Scan results:
fatfsck 3014.9.11
Checking boot region...
Checking fsinfo region...
Checking FAT tables...
Checking root directory...
Checking directory structure and allocations...
Checking FAT table allocation...
Using 23/243972 clusters.
Clearing dirty flag...
Repair finished with no repaired inconsistencies.
File system is clean.
I then changed the traffic to be stored back on the USB drive in the same place. I transferred some files and the Traffic Monitor is showing correct values still.
So, perhaps a file system problem on the USB drive was causing it to read/store values incorrectly or changing it to RAM and back set some value somewhere that wasn't? We'll see how it keepa behaving.