You are right. I forgot one of the main sources of a working technical solution to the problem of ascertaining direction of bufferbloat. Your contribution is so much appreciated in this respect, @tievolu! You cracked one of the major problems.
From memory you use nping, right? So did you face the issues identified above with nping? That it is a little slow? I have found results are improved by getting the tick duration really small, which seems impossible with nping.
Yeah, I use nping. I ping three reflectors once every two seconds, with the ping requests set to time out after one second. Now that you mention it I did find that things would break if I tried to do it more frequently than that, but for my own purposes two seconds is sufficient.
My script still uses the tactic of resting at max bandwidth and reducing it temporarily if latency gets bad, with "bad latency" defined as at least 3 out of the last 10 requests/replies exceeding 30ms for all reflectors.
Usually bad latency looks like the example above, with all three reflectors returning bad results at the same time, all back to back, and only one bandwidth reduction is needed to address it, so the script typically mitigates bufferbloat after about six seconds.
My script is very much tailored to my own connection and I haven't made any attempt to implement a moving ping baseline or any of the other clever stuff you guys are working on. Another thing to note is that I'm doing all this on a Qotom x86 box, so results might be different on more typical router hardware.
Had a feeling this question would be waiting for me when I got home
But no not yet. I wanted to test on the router, and for that I need to break out a cross-compilation toolchain.
Safest way to get the dependencies right is to make a package for it I'd assume, so I'd gotta remember how that works again as well. Or I could always compile a static binary so there's no dependency issues.
And I'm not entirely sure how to use the thing, the notes in the fork helps, but I still don't know what the MAC addresses are for.
I think you need to run a make make package/network/utils/hping3/clean first to get all the errors.
Tried here myself and it's complaining about some byteorder file. The ./configure script does some weird stuff. It doesn't seem to handle cross compilation well.
It compiles byteorder with the cross compiler, and then tries to run it after. If you don't QEMU setup with binfmt, that's gonna fail hard. Gonna look at what the byteorder program does and see if we can be rid of it
It's definitely getting further for me with your updated Makefile and source. But I'm still getting a build error (I'm x86_64_musl): https://pastebin.com/Ghq0y8Be
Okay I dunno why it worked on the older toolchain, but the delaytable variable was defined in both hping2.h and main.c which made GCC / linker mad. Made the one in hping2.h extern and it looks to compile with latest snapshot SDK as well.
That did the trick! I got a clean compile now--thank you! I just had to remember to grab your latest commit hash to update my Makefile. Funny commit messages you have there
Okay, so the binary technically doesn't error, but also doesn't seem to be functioning? @Lochnair You're not facing the same behavior are you?
Nope, works as expected for me. Although I get no response from 1.1.1.1, I think between the bigger DNS providers only 9.9.9.9 answered timestamp requests @Lynx?
Weird, I'm not seeing that behavior. Shows the WAN interface as it should here.
I'll keep poking around at it this evening. I'm wondering if it's something unique to my configuration. I just am not getting any responses with hping3:
Summary
root@OpenWrt:~# hping3 9.9.9.9 --icmp --icmp-ts -c 2000 -i u500 -I eth0
HPING 9.9.9.9 (eth0 9.9.9.9): icmp mode set, 28 headers + 0 data bytes
--- 9.9.9.9 hping statistic ---
2000 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
root@OpenWrt:~# ping 9.9.9.9
PING 9.9.9.9 (9.9.9.9) 56(84) bytes of data.
64 bytes from 9.9.9.9: icmp_seq=1 ttl=57 time=24.6 ms
64 bytes from 9.9.9.9: icmp_seq=2 ttl=57 time=25.1 ms
64 bytes from 9.9.9.9: icmp_seq=3 ttl=57 time=20.9 ms
64 bytes from 9.9.9.9: icmp_seq=4 ttl=57 time=23.1 ms
64 bytes from 9.9.9.9: icmp_seq=5 ttl=57 time=21.7 ms
^C
--- 9.9.9.9 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 20.885/23.072/25.149/1.639 ms
Update... I think I see what's going on. My eth0 (WAN) iface has an additional static IP on my cable modem's subnet so I can communicate with my modem's status page. That is the IP that hping3 is assuming when I specify eth0. I'll pull that IP off the iface in a bit and test again.
Update 2... Yep--it was having the modem subnet (192.168.100.0/24) IP statically set on my eth0 iface that was messing with hping3. Took that off the iface and I'm seeing success here!
OpenDNS and Comodo DNS also respond to timestamped ping requests. A sizeable list of potential reflectors can be found here. (I compiled this list by simply trying out all the hosts listed as DoH servers here.)