File:  [ELWIX - Embedded LightWeight unIX -] / embedaddon / mtr / FORMATS
Revision 1.1.1.2 (vendor branch): download - view: text, annotated - select for diffs - revision graph
Mon Oct 21 14:25:31 2019 UTC (4 years, 8 months ago) by misho
Branches: mtr, elwix, MAIN
CVS tags: v0_92, HEAD
mtr ver 0.92

    1: 
    2: The "split" format is for a separating the gui from the main program.
    3: The main program can be installed setuid, and you don't want to link a
    4: gui-library with a setuid program.
    5: 
    6: 
    7: The split format is:
    8: 
    9: <pos> <host> <loss%> <rcvd pckts> <sent pckts> <best> <avg> <worst> 
   10: 
   11: 
   12: The "raw" format is:
   13: 
   14: hostline|xmitline|pingline|dnsline|timestampline
   15: 
   16: hostline:
   17: h <pos> <host IP>
   18: 
   19: xmitline:
   20: x <pos> <seqnum>
   21: 
   22: pingline:
   23: p <pos> <pingtime (ms)> <seqnum>
   24: 
   25: dnsline: 
   26: d <pos> <hostname>
   27: 
   28: timestampline:
   29: t <pos> <pingtime> <timestamp>
   30: 
   31: 
   32: Timestampline is not  yet implemented. Need to find out how to do
   33: ICMP timestamping first. :-)
   34: 
   35: 
   36: Someone suggested to put the following text here. As to context: Some
   37: people are wondering why mtr sometimes reports hosts beyond the
   38: destination host. 
   39: 
   40: 
   41: The FINAL host will occasionally be mentioned at position n, n+1, n+2
   42: etc.
   43: 
   44: You know traceroute, right? It sends a packet, waits for the reply to
   45: come back and when it comes back, it sends the next packet.
   46: 
   47: If say hosts 5-8 do not send "time exceeded" packets, you'll wait a
   48: 4*3 = twelve seconds extra before you get any results on hosts 9 and
   49: further. MTR doesn't work like that.
   50: 
   51: In theory we could send out a probe for host 1-40 all at once. But
   52: this would pose an unnecessary burden on the network. So what we do,
   53: is we send out probes for a max of 5 hosts beyond where we've seen a
   54: reply. So in the example above, we'd see a reply from router at
   55: position 4, then we'd send out 5-9 (and because the max-host is now at
   56: 9, we'll send them out at 1s/9 = 111ms intervals). When the reply from
   57: host 9 comes back, we'll start probing for host 10-15 (at about 60ms
   58: intervals). But suppose the network delay up to host 9 is already 200ms
   59: and suppose our destination host is at position 11. Then by the time
   60: the packet from host 11 comes back, we'll already have sent probe
   61: packets for position 12, 13, and 14! Those will come back as
   62: "destination reached" and be reported by the "raw" mode.
   63: 
   64: Curses mode will stop showing hosts with position numbers beyond the
   65: first reply of the destination host. It could gather the information
   66: about replies to packets sent as probes FURTHER than it actually is
   67: into the line displayed at its true position, but it doesn't (yet).
   68: 
   69: In fact the above example is almost completely true:
   70: 
   71: % mtr -r -n -c 2 152.179.99.218 | tail -5
   72:  13.|-- 144.232.18.238 0.0% 2 94.8 95.4 94.8 96.0 0.8
   73:  14.|-- 152.63.16.182 0.0% 2 95.1 95.5 95.1 95.8 0.5
   74:  15.|-- 152.63.64.106 0.0% 2 163.9 163.9 163.9 164.0 0.1
   75:  16.|-- 152.63.50.89 50.0% 2 163.7 163.7 163.7 163.7 0.0
   76:  17.|-- 152.179.99.218 50.0% 2 168.2 168.2 168.2 168.2 0.0
   77: % mtr -l -c 2 152.179.99.218 | grep -v "^[dp]" |tail -7
   78: h 10 144.232.1.41
   79: h 11 144.232.4.96
   80: h 16 152.179.99.218
   81: h 17 152.179.99.218
   82: h 18 152.179.99.218
   83: h 12 144.232.18.238
   84: h 13 152.63.16.182
   85: 
   86: As you can see we get the reply from the destination host at position
   87: 16 AFTER we've sent probes for position 17 and 18. When those come
   88: back, they are reported. That's what raw mode does. It reports the raw
   89: information.
   90: 
   91: If you write a backend for the raw mode, it's up to you to
   92: filter/display the results.
   93: 
   94: h 10 144.232.1.41
   95: h 11 144.232.4.96
   96: h 12 144.232.18.238
   97: h 13 152.63.16.182
   98: h 14 152.63.64.106
   99: h 15 152.63.50.89
  100: h 16 152.179.99.218
  101: h 17 152.179.99.218
  102: h 18 152.179.99.218
  103: 

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>