Traceroute for Linux / Patches / #6 Feature request: Display source IP and interface

Dmitry Butskoy - 2025-09-08

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, source interface eth0 |

I understand this may potentially break scripts, so I'd even be fine
gating this behind a flag. Would this be doable? I'd be happy to help
if necessary.

Well, of couse this is doable, and of course there must be a special
flag for this.

So for an interactive usage you shoud add something like "alias
traceroute='traceroute --the-flag' " to your ~/.profile . Will it be
convenient for you?

Could you also pls. describe some cases when it can be useful in
practice? Traceroute is "too basic" utility (included in "minimal
installs" etc.etc.etc), therefore it is undesirable to add an arbitrary
number of rarely used options for it. I would like to get more arguments
for such an addition anyway.

From my point of view, when you discovering an issue and want to
determine a network path, you first run something like "ip route get
......", which should show the source IP and iface name. So a traceroute
option looks just not needed here. If you alter the IP and/or iface by
traceroute flags -- just be sure it uses the IP and iface specified. (If
not sure -- just check by "tcpdump" :) ).

In other words, will it really be useful for a noticeable number of
users around the world?

Regards,
Dmitry Butskoy

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Astrid Yu - 2025-09-08
  
  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 to an arbitrary destination, it's sometimes non-obvious which specific interface or IP the OS decided to use.
  
  Since I'm using it non-interactively, retrieving that information is a bit more of a hassle. I could have the wrapper service use ip route get or getifaddrs(), or make a test socket to the destination IP and call getnameinfo() on it to figure out what the OS assigns, or perform a packet capture of the traceroutes I'm running, but those all feel really overengineered compared to just having the traceroute binary itself pull data out of the socket that it created.
  
  I would imagine that this may be helpful for non-interactive usecases in general where people are running diagnostic scripts on machines that aren't consistently configured.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Dmitry Butskoy - 2025-09-08
    
    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 and independent solution for such
    use cases. Just a quick (partial) example for your case, which adds
    from/dev information just before the traceroute run:
    
    !/bin/sh
    
    prgname=$0
    dest=""
    
    PARSED=getopt -- 'dni:f:Fm:q:w:s:t:' "$@"
    [ $? != 0 ] && exit 2
    
    eval set -- "$PARSED"
    
    while [ $# -gt 0 ]
    do
        case "$1" in
            -i) iface="$2" ;;
            -s) src="$2" ;;
        esac
    
    case "$1" in
            -[dnF]) opts="$opts $1"; shift ;;
            -[isfmqwt]) opts="$opts $1 $2"; shift 2 ;;
            --) shift; break ;;
            *) echo "$prgname: Internal parsing error" >&2; exit 2 ;;
        esac
    done
    
    [ $# -eq 0 ] && {
        echo "$prgname: Internal parsing error" >&2
        exit 2
    }
    
    dest=$1
    shift
    
    set -- ip route get $dest ${iface+dev $iface} ${src+from $src}
    
    while [ $# -gt 0 ]
    do
        case "$1" in
            dev) iface="$2"; shift ;;
            src) src="$2"; shift ;;
        esac
        shift
    done
    
    echo "From IP $src, device $iface"
    exec traceroute $opts $dest
    
    IOW, src&dev information needed for you looks quite "easily obtained"
    (by "ip route get"), so it is not a reason to add en extra option somewhere.
    
    ~buc
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - Astrid Yu - 2025-09-09
      
      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.
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Feature request: Display source IP and interface

Group

Searches

Help

#6 Feature request: Display source IP and interface

Discussion

!/bin/sh