Return to FORMATS CVS log

Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / mtr

Annotation of embedaddon/mtr/FORMATS, revision 1.1.1.3

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