--- embedaddon/mtr/FORMATS	2013/07/21 23:43:42	1.1.1.1
+++ embedaddon/mtr/FORMATS	2023/09/27 11:18:58	1.1.1.4
@@ -6,25 +6,30 @@ gui-library with a setuid program.
 
 The split format is:
 
-<pos> <host> <loss%> <rcvd pckts> <sent pckts> <best> <avg> <worst> 
+<pos> <host> <loss%> <rcvd pckts> <sent pckts> <best> <avg> <worst>
 
 
 The "raw" format is:
 
-hostline|pingline|dnsline|timestampline
+hostline|xmitline|pingline|dnsline|timestampline|mplsline
 
 hostline:
 h <pos> <host IP>
 
+xmitline:
+x <pos> <seqnum>
+
 pingline:
-p <pos> <pingtime (ms)>
+p <pos> <pingtime (ms)> <seqnum>
 
-dnsline: 
+dnsline:
 d <pos> <hostname>
 
 timestampline:
 t <pos> <pingtime> <timestamp>
 
+mplsline:
+m <pos> <label> <traffic_class> <bottom_stack> <ttl>
 
 Timestampline is not  yet implemented. Need to find out how to do
 ICMP timestamping first. :-)
@@ -32,7 +37,7 @@ ICMP timestamping first. :-)
 
 Someone suggested to put the following text here. As to context: Some
 people are wondering why mtr sometimes reports hosts beyond the
-destination host. 
+destination host.
 
 
 The FINAL host will occasionally be mentioned at position n, n+1, n+2
@@ -52,7 +57,7 @@ reply. So in the example above, we'd see a reply from 
 position 4, then we'd send out 5-9 (and because the max-host is now at
 9, we'll send them out at 1s/9 = 111ms intervals). When the reply from
 host 9 comes back, we'll start probing for host 10-15 (at about 60ms
-intervals). But suppose the network delay upto host 9 is already 200ms
+intervals). But suppose the network delay up to host 9 is already 200ms
 and suppose our destination host is at position 11. Then by the time
 the packet from host 11 comes back, we'll already have sent probe
 packets for position 12, 13, and 14! Those will come back as
@@ -97,4 +102,3 @@ h 15 152.63.50.89
 h 16 152.179.99.218
 h 17 152.179.99.218
 h 18 152.179.99.218
-