Traceroute for Linux Activity
Brought to you by:
buc
Activity for Traceroute for Linux
-
Dmitry Butskoy posted a comment on ticket #19
Shunsuke Matsumoto wrote: OPTIONS -4, -6 Explicitly force IPv4 or IPv6 tracerouting. By default, the program will try to resolve the name given, and choose the appropriate protocol automatically. If resolving a host name returns both IPv4 and IPv6 addresses, traceroute will use IPv4. Yes, surely it must be changed. Thanks for the report.
-
Shunsuke Matsumoto created ticket #19
man page revision
-
Astrid Yu posted a comment on ticket #6
I will have the wrapping service consult the routing tables then, but it still feels like a more convoluted solution than having the binary output information it already has.
-
Astrid Yu wrote: Since I'm using it non-interactively, retrieving that information is a bit more of a hassle. Well, maybe just use wrappers? Wrapper is a more correct way here, especially given the non-interactive nature of use. In addition, this is a more universal way, because allows you to add the necessary output functionality without the need for any change in the utilities involved. Sometimes the writing of the wrappers looks difficult or bulky at first glance, but this is a really correct...
-
I'm not sure if I can answer for other users, but it certainly would be helpful in my specific use case, which is a monitoring service running on machines in various locations for remotely running traceroutes (i.e. send a request to the service, it delegates to the traceroute CLI, and responds with parsed output to be consumed by the requestor). The reason this feature would help me is because the remote hosts running my service often have multiple IPs and interfaces. When performing a traceroute...
-
Astrid Yu wrote: I know there is a way to explicitly provide a source IP and interface. However, if you don't do that, unless I'm mistaken, I don't believe there is a way to tell what source IP, starting port, and interface is being used. I've looked through the |--help| and I don't think I've found any flags for that, either. ... ||Ideally, I'd like the header to look something like this instead: |traceroute to google.com (64.233.177.113), 30 hops max, 60 byte packets, source IP 192.168.192.168:33434,...
-
Feature request: Display source IP and interface
-
Well, there is already such a patch that has been made for a long time by ALTLinux Distro. That distribution for some reason professes more pedantic warning options, and just like you, uses -W (or -Wextra) by default. Most of the warnings that you reported are taking place due to the fact that the -Wsign-compare option is activated (which is part of the -Wextra set). For the moment, -Wsign-compare is not considered by leading distributions as a mandatory compilation option. For example, neither Fedora...
-
Kirill created ticket #18
warnings in traceroute-2.1.6
-
Sebastian Moeller wrote: FreeBSD's traceroute for IPv4 (a different bninary from traceroute6) has a very interesting diagnostiuc/debug mode that allows to record and then analyse modification to the IP header along a path: Unfortunately we don't have access to the raw IP headers anyway due to implementation limitations. All information is obtained only by the recvmsg(2) system call with the MSG_ERRQUEUE flag set. This way allows unprivileged users to use "udp" and/or "icmp/echo" traces without having...
-
moeller0 created ticket #17
Feature request:
-
Jan Macku posted a comment on ticket #16
Thank you for quick fix.
-
RFC-3484: Traceroute should defaults to IPv6 instead of IPv4 if possible
-
Fixed in 2.1.6 .
-
Enable large file support (LFS)
-
Traceroute for Linux released /traceroute/traceroute-2.1.6/README-2.1.6.txt
-
-
Hello Dmitry, Thank you for your prompt response. Can you imagine some negative use cases in practice due to the removal of the current mandatory IPv4 default? (I mean the risk of significant breakage of someone's habits, scripts, etc.) I think this change should be safe. But even if it affects some scripts, mitigation should be straightforward by using the -4 option. As you mentioned, ping already has such a behavior. [root@R9 ~]# ping kernel.org PING kernel.org(dfw.source.kernel.org (2604:1380:4641:c500::1))...
-
Jan Macku wrote: Traceroute defaults to IPv4 addresses even when IPv6 addresses are available. While there is the traceroute6 option, The RFC below appears to indicate that this should not be the case. RFC-3484 - Default Address Selection for Internet Protocol version 6 (IPv6) https://www.rfc-editor.org/info/rfc3484 Well, sounds reasonable, since ping(8) has long used the results of getaddrinfo(3) to determine the default address family. Can you imagine some negative use cases in practice due to...
-
RFC-3484: Traceroute should defaults to IPv6 instead of IPv4 if possible
-
Taoyu Saijo wrote: To be compatible with large file support shall we consider compiling the project with the following flags? |-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE| |Traceroute does not use filesystems in any way in its work. So nothing special in this context -- just use the standard compiler flags from your Linux distribution. ~buc |
-
Taoyu Saijo created ticket #15
Enable large file support (LFS)
-
-
-
Add option to display MSS TCP option
-
Very thanks for the idea! Implemented now in 2.1.4
-
-
-
Francois wrote: Existing traceroute -T -O mss=xxx lets a user specifies the value within the TCP MSS option. To detect issues with clamping (routers rewriting the MSS with a different value), it would be nice to display the MSS value as found in the ICMP and TCP replies. Today this can be achieved by running a tcpdump at the same time traceroute is running. Attaching a patch with a proof of concept. What do you think? Thanks for the info! Currently we only parse TCP flags and only from the final...
-
Francois created ticket #5
Add option to display MSS TCP option
-
-
-
Incorrect placement of asterisks for probe timeouts
-
RFE: send many, wait for few
-
I believe since the version of 2.1.0, this (or similar) feature is now implemented. See "-w" option description in manual. (IOW, no more wait for long replies when there are already some fast replies received). So close now.
-
Sudden "send: No route to host" with 6.1.x kernels
-
Thenks for fix and report. Confirmed with kernel-6.2.0 on Fedora Rawhide. Fixed in traceroute-2.1.2
-
-
-
Mantas created ticket #14
Sudden "send: No route to host" with 6.1.x kernels
-
-
-
Tyler posted a comment on ticket #13
Ok, I think I understand. If the first n probes for a given hop don't get a response, you will have n asterisks ahead of the IP if/when it actually does respond. This is because tracert doesn't know the IPs or response times of the hops until it gets a response back for that hop. Sometimes it's possible to get the false impression that it is discovering IPs and then pinging them. Thanks for the clarification!
-
Tyler wrote: Even with the 3 hop default this is possible: |$ traceroute -m 3 45.56.99.171 -n traceroute to 45.56.99.171 (45.56.99.171), 3 hops max, 60 byte packets 1 * * * 2 198.19.123.1 19.705 ms * 19.674 ms 3 * 198.19.110.1 26.045 ms 27.674 ms | I only noticed this because I was trying to parse traceroute output so I was looking more closely... This isn't expected behavior right? Yes, it is expected behaviour. The IP address is printed at the first answered probe in a line. When the first answered...
-
Incorrect placement of asterisks for probe timeouts
-
Tomasz Kłoczko posted a comment on ticket #12
As I wrote this is not about switching to as you call it "facebook for the coders". This is about possibiolity of interraction build systems with VCS repo. If repository provides URL with exact commit patch like https://github.com/facebookincubator/BOLT/tree/6a13ca6d183d8de3cffcf357ef00fa919f451540 it is possible to plug it and use it straight into build procedure of exact package. Simple SF web interface DOES NOT HAVE at all such possibiti for svn or git. In other words it is stricte technical reson...
-
Tomasz Kłoczko wrote: [bugs:#12] https://sourceforge.net/p/traceroute/bugs/12/ traceroute VCS repo? Status: open Group: v1.0 (example) Created: Mon Mar 15, 2021 08:41 PM UTC by Tomasz Kłoczko Last Updated: Mon Mar 15, 2021 08:41 PM UTC Owner: nobody Is it anywhwere some public VCS repo with traceroute source code? If not is it possible to crrate it instead on sf.net on github or gitlab? (those two it have way better rest interface to download axact commits over that interface) You already asked it...
-
traceroute VCS repo?
-
traceroute VCS repo?
-
ssdfdsfw2e2ef23 created ticket #11
more information for --as-path-lookups
-
G4JC modified a comment on ticket #10
I do not trust sourceforge for a variety of reasons. However, even if I did, without...
-
I not trust sourceforge for a variety of reasons. However, even if I did, without...
-
It would sound reasonable if I'll choose some own site for upstream. But for now,...
-
Feature Request: Source tarball integrity
-
-
-
Wishlist: please remove build date from version string
-
Done in 2.0.22
-
Compile with musl libc
-
Done in 2.0.22 Thanks.
-
Add support to set SO_REUSEADDR for tcp probes
-
Done in 2.0.22 (Option name changed to be just `reuse')
-
-
-
IDN is planned for musl-1.15 Well, whether it could be applicable to temporary use...
-
Felix Janda posted a comment on ticket #3
Yes, the TCPOPT constants have been added. IDN is planned for musl-1.15. (musl-1.13...
-
According to http://git.musl-libc.org/cgit/musl/commit/?id=53f41fb568ae43034c9876cc9bd3961fd6d13671...
-
According to http://git.musl-libc.org/cgit/musl/commit/?id=53f41fb568ae43034c9876cc9bd3961fd6d13671...
-
Richard Sheehan posted a comment on ticket #4
Diff
-
Add support to set SO_REUSEADDR for tcp probes
-
Thank you very much.
-
OK, I'll resolve the macros issue as well.
-
Thanks. Agree with all except the TCPOPT_MAXSEG -- this macro is present in standard...
-
Patch 3
-
Patch 3
-
Patch 2
-
Patch 1
-
Compile with musl libc
-
Graham Inggs created ticket #9
Wishlist: please remove build date from version string
-
I'm getting expected results from traceroute 2.0.21 on Ubuntu Utopic (kernel 3.16)....
-
RFE: send many, wait for few
-
Problem with --mtu on kernels >= 3.13
-
Fixed in 2.0.21 The problem seems to be inspired as a side effect from some changes...
-
-
-
jdg posted a comment on ticket #8
I'd like to confirm that this bug is still present in 2.0.20, as I've just run into...
-
So on newer kernels I see one packet arriving with ee->ee_origin = SO_EE_ORIGIN_LOCAL...
-
So on newer kernels I see one packet arriving with ee->ee_origin = SO_EE_ORIGIN_LOCAL...
-
Craig Tong posted a comment on ticket #8
I can confirm this behavior on Gentoo: traceroute 2.0.18 works on 3.12.21 kernel...
-
There's also a bug report for 2.0.19 segfaulting with the --mtu switch in Arch Linux:...
-
Without --mtu or with -I or -T are all fine. 2.0.19 on Trusty, Utopic and Sid all...
-
Looks like impossible... Any numbers cannot be printed accompanied to `*' ... Probably...
-
Problem with --mtu on recent Debian/Ubuntu distributions
-
Andrew Schwartz posted a comment on ticket #7
Looks good on 2.0.20. Thanks Dmitry.
-
fwmark option
-
fwmark option
-
traceroute shows incorrect ttl for first echo reply
-
New version 2.0.20 is released. Please check whether the problem still persist or...
1 >
