You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have read the contributing guideline and understand that I have made the correct modifications
Description:
Replace the busybox traceroute binary with the more fully-featured one available in the community APK repository.
Benefits of this PR and context:
This allows the tcpping script to leverage traceroute instead of falling back to tcptraceroute. tcptraceroute has some strange issues with certain types of responses, notably an unexplained delay in processing responses from specific targets:
$ docker compose exec --user abc smokeping time /usr/bin/tcpping -Czx 25 speedtest.qld.edgeix.net.au 8080
traceroute does not support -M parameter, switching to tcptraceroute
/usr/bin/tcptraceroute -f 255 -m 255 -q 1 -w 1 speedtest.qld.edgeix.net.au 8080
speedtest.qld.edgeix.net.au : 4.045 7.251 13.231 9.323 11.507 10.339 8.279 8.171 4.429 5.751 5.520 8.590 4.451 11.315 11.588 5.221 5.022 4.892 6.489 4.892 4.753 4.527 10.546 5.053 10.615
real 4m 29.37s
user 0m 0.16s
sys 0m 0.11s
Running tcptraceroute directly with the -d flag reveals that each execution of tcptraceroute against this target takes 10 seconds, although the response is received much faster than that:
$ docker compose exec --user abc smokeping time /usr/bin/tcptraceroute -f 255 -m 255 -q 1 -w 1 -d -A speedtest.qld.edgeix.net.au 8080
debug: tcptraceroute 1.5beta7, x86_64-alpine-linux-musl
debug: Compiled with libpcap 1.10.5, libnet 1.3 (API 110)
debug: o_ack set
debug: entering getinterfaces()
debug: ifreq buffer set to 32
debug: Successfully retrieved interface list
debug: Discovered interface lo with address 127.0.0.1
debug: Discovered interface eth0 with address 10.5.1.25
debug: Discovered interface eth1 with address 192.168.0.25
debug: leaving getinterfaces()
debug: Determined source address of 192.168.0.25 to reach 103.215.15.11
debug: entering finddev()
debug: finddev() returning eth1
debug: debugoptions():
debug: TEXTSIZE: 1024 SNAPLEN: 92 IPTOSBUFFERS: 12
debug: ALLOCATEID_CACHE: 512 datalink: 1 datalinkoffset: 14
debug: o_minttl: 255 o_maxttl: 255 o_timeout: 1
debug: o_debug: 1 o_numeric: 0 o_pktlen: 0
debug: o_nqueries: 1 o_dontfrag: 0 o_tos: 0
debug: o_forceport: 0 o_syn: 0 o_ack: 1
debug: o_ecn: 0 o_nofilter: 0 o_nogetinterfaces: 0
debug: o_trackport: 0 datalinkname: ETHERNET device: eth1
debug: o_noselect: 0 o_dnat: 0 isn: 1019473394
Selected device eth1, address 192.168.0.25, port 42173 for outgoing packets
debug: pcap filter is:
(tcp and src host 103.215.15.11 and src port 8080 and dst host 192.168.0.25)
or ((icmp[0] == 11 or icmp[0] == 3) and dst host 192.168.0.25)
Tracing the path to speedtest.qld.edgeix.net.au (103.215.15.11) on TCP port 8080 (http-alt), 255 hops max
debug: Generating a new batch of 512 IP ID's
debug: Sent probe 1 of 1 for hop 255, IP ID 39778, source port 42173, ACK
debug: received 46 byte IP packet from pcap_next()
debug: Received TCP packet
debug: Received TCP packet 103.215.15.11:8080 -> 192.168.0.25:42173, flags RST
debug: displayed hop
255 103.215.15.11 [closed] 5.529 ms
real 0m 10.10s
user 0m 0.00s
sys 0m 0.00s
tcptraceroute is also effectively unmaintained. The latest release (and the one available in the image) is v1.5beta7, released in 2006, and there have been no commits to the repository since 2017, so I'm not expecting any bugs to be fixed any time soon. I've elected to keep the installation of tcptraceroute in the Dockerfile despite this, to avoid breaking any configurations in the wild that explicitly rely on its presence.
How Has This Been Tested?
I installed the updated traceroute binary in an existing docker-smokeping container using apk -U add traceroute and gave the binary setuid access with chmod a+s /usr/bin/traceroute. A test of tcpping using the -z flag shows the correct binary and flags being used:
@nasaboy my 25 tests were also a much lower RTT than yours. Please take the time to educate yourself on how this tool works before commenting, thank you.
Okay, you're absolutely right; this tool does exhibit this behavior. However, using tcping works correctly.Hopefully, this pull request will be merged soon.
I tested tcpping v2.7 and found that it actually includes the -n parameter, it just wasn't displayed in the help message (-h). With this parameter added, the test time using tcptraceroute will be normal.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
MattKobayashi
force-pushed
the
fix/install-traceroute
branch
from
github-project-automation
bot
moved this from PRs
to PRs Approved
in Issue & PR Tracker
Description:
Replace the busybox
traceroutebinary with the more fully-featured one available in thecommunityAPK repository.Benefits of this PR and context:
This allows the
tcppingscript to leveragetracerouteinstead of falling back totcptraceroute.tcptraceroutehas some strange issues with certain types of responses, notably an unexplained delay in processing responses from specific targets:Running
tcptraceroutedirectly with the-dflag reveals that each execution oftcptracerouteagainst this target takes 10 seconds, although the response is received much faster than that:tcptracerouteis also effectively unmaintained. The latest release (and the one available in the image) is v1.5beta7, released in 2006, and there have been no commits to the repository since 2017, so I'm not expecting any bugs to be fixed any time soon. I've elected to keep the installation oftcptraceroutein the Dockerfile despite this, to avoid breaking any configurations in the wild that explicitly rely on its presence.How Has This Been Tested?
I installed the updated
traceroutebinary in an existingdocker-smokepingcontainer usingapk -U add tracerouteand gave the binary setuid access withchmod a+s /usr/bin/traceroute. A test oftcppingusing the-zflag shows the correct binary and flags being used:Source / References: