Possible inaccuracies on (linux) bond interfaces

[imsnif]

Someone reported this on twitter: https://twitter.com/LinuxReviews/status/1218547448928444418. I don't have a lot more details unfortunately.

[zhangxp1998]

Not sure if this is due to averaging? if the traffic is bursty our averaging calculation will make the numbers go wild. Looking at these screenshots, it seems that we are always reporting a number lower than other tools, which is consistent with my hypothesis...

[imsnif]

That was my guess too. The person on twitter wasn't willing to participate in an issue here, so I think to just leave this open in case someone else encounters this issue and decides to be helpful.

[amyspark]

👋 this is in Manjaro (kernel version Linux Dianakko 5.4.22-1-MANJARO #1 SMP PREEMPT Mon Feb 24 09:01:11 UTC 2020 x86_64 GNU/Linux).

[imsnif]

Hey @amyspark, thanks for bringing this up. I hope you're okay with helping us debug this a little?

To start, a few questions to help identify a possible cause for this:

1. Does this happen all the time, or just in specific situations? With specific sorts of traffic, or?
2. Does this happen for sustained traffic (eg. leaving the app running for 1-2 minutes?)
3. As far as you can tell, are the differences in traffic more or less consistent, or are they all over the place?

[amyspark]

@imsnif ,

1. All the time, it always underestimates traffic, even though the connections are properly listed.
2. As far as I've used it, yes.
3. No, always ~3KB/s for an usage of ~300KB/s, about two orders of magnitude less.

[imsnif]

Thanks @amyspark. I want to try to troubleshoot this to find out which part of the app is misbehaving. If sometime in the next few days I give you (either a branch to compile or a compiled binary - whichever is more comfortable for you) would you be willing to run it? I essentially just want to cut out all parts of the app except for the traffic sniffer and see if it reports the total traffic correctly in your system.

[amyspark]

Sure @imsnif ! Let me know which branch and I'll test it right away.

[imsnif]

So, this came up again in #155, and I'd like to try to get back and find the root cause for this. I still cannot reproduce this locally, but @TheLostLambda encountered this issue with large volumes of data.

My first guess is that this is somehow related to an issue with the ip payload length reporting in libpnet. I made a branch that measures the size of the Ethernet frame rather than the ip packet to see if this direction might be promising.

@amyspark - I know it's been a while, my apologies for not getting to this, but if you'd be willing to checkout the debug/inaccuracies branch of this repo and see if the problem still happens there, that would be great.

@TheLostLambda - if you'd like to give it a go as well, that would also be great.

In case anyone else would like to try as well, this is how I run bandwhich locally after I checked out the debug/inaccuracies branch:
cargo build && sudo ./target/debug/bandwhich

There will probably be a little more back and forth, as if this is not the issue, I have some other guesses and things I'd like to look into. Thanks in advance for bearing with me. :)

[TheLostLambda]

Hi!

I've given this a go and, unfortunately, the same issue persists. Bandwhich reporting ~4MBps when I'm pulling ~25MBps.

Thanks so much for helping with the debugging!

[imsnif]

Hrm... How about if you start bandwhich (in this branch or normally) with the -i <your interface> flag?

If that still happens, I'll update the debug branch and try to remove everything except the packet sniffer and some text that updates the total bandwidth on screen. Try to peel away as much stuff as possible.

[TheLostLambda]

No luck unfortunately, with either my wifi interface or a virtual docker interface