neulab/tldr huggingface dataset:
The general format of a TCP protocol line is: src > dst: Flags [tcpflags], seq data-seqno, ack ackno, win window, urg urgent, options [opts], length len Src and dst are the source and destination IP addresses and ports. Tcpflags are some combination of S (SYN), F (FIN), P (PUSH), R (RST), U (URG), W (ECN CWR), E (ECN-Echo) or `.' (ACK), or `none' if no flags are set.  Data-seqno describes the portion of sequence space covered by the data in this packet (see example below).  Ackno is sequence number of the next data expected the other direction on this connection.  Window is the number of bytes of receive buffer space available the other direction on this connection.  Urg indicates there is `urgent' data in the packet. Opts are TCP options (e.g., mss 1024).  Len is the length of payload data.
Iptype, Src, dst, and flags are always present.  The other fields depend on the contents of the packet's TCP protocol header and are output only if appropriate.
Here is the opening portion of an rlogin from host rtsg to host csam. IP rtsg.1023 > csam.login: Flags [S], seq 768512:768512, win 4096, opts [mss 1024] IP csam.login > rtsg.1023: Flags [S.], seq, 947648:947648, ack 768513, win 4096, opts [mss 1024] IP rtsg.1023 > csam.login: Flags [.], ack 1, win 4096 IP rtsg.1023 > csam.login: Flags [P.], seq 1:2, ack 1, win 4096, length 1 IP csam.login > rtsg.1023: Flags [.], ack 2, win 4096 IP rtsg.1023 > csam.login: Flags [P.], seq 2:21, ack 1, win 4096, length 19 IP csam.login > rtsg.1023: Flags [P.], seq 1:2, ack 21, win 4077, length 1 IP csam.login > rtsg.1023: Flags [P.], seq 2:3, ack 21, win 4077, urg 1, length 1 IP csam.login > rtsg.1023: Flags [P.], seq 3:4, ack 21, win 4077, urg 1, length 1 The first line says that TCP port 1023 on rtsg sent a packet to port login on csam.  The S indicates that the SYN flag was set.  The packet sequence number was 768512 and it contained no data.  (The notation is `first:last' which means `sequence numbers first up to but not including last'.)  There was no piggy-backed ACK, the available receive window was 4096 bytes and there was a max-segment-size option requesting an MSS of 1024 bytes.
Csam replies with a similar packet except it includes a piggy-backed ACK for rtsg's SYN.  Rtsg then ACKs csam's SYN.  The `.' means the ACK flag was set.  The packet contained no data so there is no data sequence number or length.  Note that the ACK sequence number is a small integer (1).  The first time tcpdump sees a TCP `conversation', it prints the sequence number from the packet.  On subsequent packets of the conversation, the difference between the current packet's sequence number and this initial sequence number is printed.  This means that sequence numbers after the first can be interpreted as relative byte positions in the conversation's data stream (with the first data byte each direction being `1').  `-S' will override this feature, causing the original sequence numbers to be output.
On the 6th line, rtsg sends csam 19 bytes of data (bytes 2 through 20 in the rtsg → csam side of the conversation).  The PUSH flag is set in the packet.  On the 7th line, csam says it's received data sent by rtsg up to but not including byte 21.  Most of this data is apparently sitting in the socket buffer since csam's receive window has gotten 19 bytes smaller.  Csam also sends one byte of data to rtsg in this packet.  On the 8th and 9th lines, csam sends two bytes of urgent, pushed data to rtsg.
If the snapshot was small enough that tcpdump didn't capture the full TCP header, it interprets as much of the header as it can and then reports ``[|tcp]'' to indicate the remainder could not be interpreted.  If the header contains a bogus option (one with a length that's either too small or beyond the end of the header), tcpdump reports it as ``[bad opt]'' and does not interpret any further options (since it's impossible to tell where they start).  If the header length indicates options are present but the IP datagram length is not long enough for the options to actually be there, tcpdump reports it as ``[bad hdr length]''.
Capturing TCP packets with particular flag combinations (SYN-ACK, URG- ACK, etc.)
There are 8 bits in the control bits section of the TCP header:
CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
Let's assume that we want to watch packets used in establishing a TCP connection.  Recall that TCP uses a 3-way handshake protocol when it initializes a new connection; the connection sequence with regard to the TCP control bits is
1) Caller sends SYN 2) Recipient responds with SYN, ACK 3) Caller sends ACK
Now we're interested in capturing packets that have only the SYN bit set (Step 1).  Note that we don't want packets from step 2 (SYN-ACK), just a plain initial SYN.  What we need is a correct filter expression for tcpdump.
Recall the structure of a TCP header without options:
0                            15                              31 ----------------------------------------------------------------- |          source port          |       destination port        | ----------------------------------------------------------------- |                        sequence number                        | ----------------------------------------------------------------- |                     acknowledgment number                     | ----------------------------------------------------------------- |  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            | ----------------------------------------------------------------- |         TCP checksum          |       urgent pointer          | -----------------------------------------------------------------
A TCP header usually holds 20 octets of data, unless options are present. The first line of the graph contains octets 0 - 3, the second line shows octets 4 - 7 etc.
Starting to count with 0, the relevant TCP control bits are contained in octet 13:
0             7|             15|             23|             31 ----------------|---------------|---------------|---------------- |  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            | ----------------|---------------|---------------|---------------- |               |  13th octet   |               |               |
Let's have a closer look at octet no. 13:
|               | |---------------| |C|E|U|A|P|R|S|F| |---------------| |7   5   3     0|
These are the TCP control bits we are interested in.  We have numbered the bits in this octet from 0 to 7, right to left, so the PSH bit is bit number 3, while the URG bit is number 5.
Recall that we want to capture packets with only SYN set.  Let's see what happens to octet 13 if a TCP datagram arrives with the SYN bit set in its header:
|C|E|U|A|P|R|S|F| |---------------| |0 0 0 0 0 0 1 0| |---------------| |7 6 5 4 3 2 1 0|
Looking at the control bits section we see that only bit number 1 (SYN) is set.
Assuming that octet number 13 is an 8-bit unsigned integer in network byte order, the binary value of this octet is
00000010
and its decimal representation is
7     6     5     4     3     2     1     0 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 + 0*2  =  2
We're almost done, because now we know that if only SYN is set, the value of the 13th octet in the TCP header, when interpreted as a 8-bit unsigned integer in network byte order, must be exactly 2.
This relationship can be expressed as tcp[13] == 2
We can use this expression as the filter for tcpdump in order to watch packets which have only SYN set: tcpdump -i xl0 tcp[13] == 2
The expression says "let the 13th octet of a TCP datagram have the decimal value 2", which is exactly what we want.
Now, let's assume that we need to capture SYN packets, but we don't care if ACK or any other TCP control bit is set at the same time.  Let's see what happens to octet 13 when a TCP datagram with SYN-ACK set arrives:
|C|E|U|A|P|R|S|F| |---------------| |0 0 0 1 0 0 1 0| |---------------| |7 6 5 4 3 2 1 0|
Now bits 1 and 4 are set in the 13th octet.  The binary value of octet 13 is
00010010
which translates to decimal
7     6     5     4     3     2     1     0 0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2   = 18
Now we can't just use 'tcp[13] == 18' in the tcpdump filter expression, because that would select only those packets that have SYN-ACK set, but not those with only SYN set.  Remember that we don't care if ACK or any other control bit is set as long as SYN is set.
In order to achieve our goal, we need to logically AND the binary value of octet 13 with some other value to preserve the SYN bit.  We know that we want SYN to be set in any case, so we'll logically AND the value in the 13th octet with the binary value of a SYN:
00010010 SYN-ACK              00000010 SYN AND  00000010 (we want SYN)   AND  00000010 (we want SYN) --------                      -------- =    00000010                 =    00000010
We see that this AND operation delivers the same result regardless whether ACK or another TCP control bit is set.  The decimal representation of the AND value as well as the result of this operation is 2 (binary 00000010), so we know that for packets with SYN set the following relation must hold true:
( ( value of octet 13 ) AND ( 2 ) ) == ( 2 )
This points us to the tcpdump filter expression tcpdump -i xl0 'tcp[13] & 2 == 2'
Some offsets and field values may be expressed as names rather than as numeric values. For example tcp[13] may be replaced with tcp[tcpflags]. The following TCP flag field values are also available: tcp-fin, tcp-syn, tcp-rst, tcp-push, tcp-ack, tcp-urg.
This can be demonstrated as: tcpdump -i xl0 'tcp[tcpflags] & tcp-push != 0'
Note that you should use single quotes or a backslash in the expression to hide the AND ('&') special character from the shell.
UDP Packets
UDP format is illustrated by this rwho packet: actinide.who > broadcast.who: udp 84 This says that port who on host actinide sent a UDP datagram to port who on host broadcast, the Internet broadcast address.  The packet contained 84 bytes of user data.
Some UDP services are recognized (from the source or destination port number) and the higher level protocol information printed.  In particular, Domain Name service requests (RFC-1034/1035) and Sun RPC calls (RFC-1050) to NFS.
TCP or UDP Name Server Requests
(N.B.:The following description assumes familiarity with the Domain Service protocol described in RFC-1035.  If you are not familiar with the protocol, the following description will appear to be written in Greek.)
Name server requests are formatted as src > dst: id op? flags qtype qclass name (len) h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37) Host h2opolo asked the domain server on helios for an address record (qtype=A) associated with the name ucbvax.berkeley.edu.  The query id was `3'.  The `+' indicates the recursion desired flag was set.  The query length was 37 bytes, excluding the TCP or UDP and IP protocol headers. The query operation was the normal one, Query, so the op field was omitted.  If the op had been anything else, it would have been printed between the `3' and the `+'.  Similarly, the qclass was the normal one, C_IN, and omitted.  Any other qclass would have been printed immediately after the `A'.
A few anomalies are checked and may result in extra fields enclosed in square brackets:  If a query contains an answer, authority records or additional records section, ancount, nscount, or arcount are printed as `[na]', `[nn]' or  `[nau]' where n is the appropriate count.  If any of the response bits are set (AA, RA or rcode) or any of the `must be zero' bits are set in bytes two and three, `[b2&3=x]' is printed, where x is the hex value of header bytes two and three.
TCP or UDP Name Server Responses
Name server responses are formatted as src > dst:  id op rcode flags a/n/au type class data (len) helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273) helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97) In the first example, helios responds to query id 3 from h2opolo with 3 answer records, 3 name server records and 7 additional records.  The first answer record is type A (address) and its data is internet address 128.32.137.3.  The total size of the response was 273 bytes, excluding TCP or UDP and IP headers.  The op (Query) and response code (NoError) were omitted, as was the class (C_IN) of the A record.
In the second example, helios responds to query 2 with a response code of non-existent domain (NXDomain) with no answers, one name server and no authority records.  The `*' indicates that the authoritative answer bit was set.  Since there were no answers, no type, class or data were printed.
Other flag characters that might appear are `-' (recursion available, RA, not set) and `|' (truncated message, TC, set).  If the `question' section doesn't contain exactly one entry, `[nq]' is printed.
SMB/CIFS decoding
tcpdump now includes fairly extensive SMB/CIFS/NBT decoding for data on UDP/137, UDP/138 and TCP/139.  Some primitive decoding of IPX and NetBEUI SMB data is also done.
By default a fairly minimal decode is done, with a much more detailed decode done if -v is used.  Be warned that with -v a single SMB packet may take up a page or more, so only use -v if you really want all the gory details.
For information on SMB packet formats and what all the fields mean see https://download.samba.org/pub/samba/specs/ and other online resources. The SMB patches were written by Andrew Tridgell (tridge@samba.org).
NFS Requests and Replies
Sun NFS (Network File System) requests and replies are printed as: src.sport > dst.nfs: NFS request xid xid len op args src.nfs > dst.dport: NFS reply xid xid reply stat len op results sushi.1023 > wrl.nfs: NFS request xid 26377 112 readlink fh 21,24/10.73165 wrl.nfs > sushi.1023: NFS reply xid 26377 reply ok 40 readlink "../var" sushi.1022 > wrl.nfs: NFS request xid 8219 144 lookup fh 9,74/4096.6878 "xcolors" wrl.nfs > sushi.1022: NFS reply xid 8219 reply ok 128 lookup fh 9,74/4134.3150 In the first line, host sushi sends a transaction with id 26377 to wrl. The request was 112 bytes, excluding the UDP and IP headers.  The operation was a readlink (read symbolic link) on file handle (fh) 21,24/10.731657119.  (If one is lucky, as in this case, the file handle can be interpreted as a major,minor device number pair, followed by the inode number and generation number.) In the second line, wrl replies `ok' with the same transaction id and the contents of the link.
In the third line, sushi asks (using a new transaction id) wrl to lookup the name `xcolors' in directory file 9,74/4096.6878. In the fourth line, wrl sends a reply with the respective transaction id.
Note that the data printed depends on the operation type.  The format is intended to be self explanatory if read in conjunction with an NFS protocol spec.  Also note that older versions of tcpdump printed NFS packets in a slightly different format: the transaction id (xid) would be printed instead of the non-NFS port number of the packet.
If the -v (verbose) flag is given, additional information is printed. For example: sushi.1023 > wrl.nfs: NFS request xid 79658 148 read fh 21,11/12.195 8192 bytes @ 24576 wrl.nfs > sushi.1023: NFS reply xid 79658 reply ok 1472 read REG 100664 ids 417/0 sz 29388 (-v also prints the IP header TTL, ID, length, and fragmentation fields, which have been omitted from this example.)  In the first line, sushi asks wrl to read 8192 bytes from file 21,11/12.195, at byte offset 24576. Wrl replies `ok'; the packet shown on the second line is the first fragment of the reply, and hence is only 1472 bytes long (the other bytes will follow in subsequent fragments, but these fragments do not have NFS or even UDP headers and so might not be printed, depending on the filter expression used).  Because the -v flag is given, some of the file attributes (which are returned in addition to the file data) are printed: the file type (``REG'', for regular file), the file mode (in octal), the UID and GID, and the file size.
If the -v flag is given more than once, even more details are printed.
NFS reply packets do not explicitly identify the RPC operation.  Instead, tcpdump keeps track of ``recent'' requests, and matches them to the replies using the transaction ID.  If a reply does not closely follow the corresponding request, it might not be parsable.
AFS Requests and Replies
Transarc AFS (Andrew File System) requests and replies are printed as:
src.sport > dst.dport: rx packet-type src.sport > dst.dport: rx packet-type service call call-name args src.sport > dst.dport: rx packet-type service reply call-name args elvis.7001 > pike.afsfs: rx data fs call rename old fid 536876964/1/1 ".newsrc.new" new fid 536876964/1/1 ".newsrc" pike.afsfs > elvis.7001: rx data fs reply rename In the first line, host elvis sends a RX packet to pike.  This was a RX data packet to the fs (fileserver) service, and is the start of an RPC call.  The RPC call was a rename, with the old directory file id of 536876964/1/1 and an old filename of `.newsrc.new', and a new directory file id of 536876964/1/1 and a new filename of `.newsrc'.  The host pike responds with a RPC reply to the rename call (which was successful, because it was a data packet and not an abort packet).
In general, all AFS RPCs are decoded at least by RPC call name.  Most AFS RPCs have at least some of the arguments decoded (generally only the `interesting' arguments, for some definition of interesting).
The format is intended to be self-describing, but it will probably not be useful to people who are not familiar with the workings of AFS and RX.
If the -v (verbose) flag is given twice, acknowledgement packets and additional header information is printed, such as the RX call ID, call number, sequence number, serial number, and the RX packet flags.
If the -v flag is given twice, additional information is printed, such as the RX call ID, serial number, and the RX packet flags.  The MTU negotiation information is also printed from RX ack packets.
If the -v flag is given three times, the security index and service id are printed.
Error codes are printed for abort packets, with the exception of Ubik beacon packets (because abort packets are used to signify a yes vote for the Ubik protocol).
AFS reply packets do not explicitly identify the RPC operation.  Instead, tcpdump keeps track of ``recent'' requests, and matches them to the replies using the call number and service ID.  If a reply does not closely follow the corresponding request, it might not be parsable.
KIP AppleTalk (DDP in UDP)
AppleTalk DDP packets encapsulated in UDP datagrams are de-encapsulated and dumped as DDP packets (i.e., all the UDP header information is discarded).  The file /etc/atalk.names is used to translate AppleTalk net and node numbers to names.  Lines in this file have the form number    name
1.254          ether 16.1      icsd-net 1.254.110 ace The first two lines give the names of AppleTalk networks.  The third line gives the name of a particular host (a host is distinguished from a net by the 3rd octet in the number - a net number must have two octets and a host number must have three octets.)  The number and name should be separated by whitespace (blanks or tabs).  The /etc/atalk.names file may contain blank lines or comment lines (lines starting with a `#').
AppleTalk addresses are printed in the form net.host.port
144.1.209.2 > icsd-net.112.220 office.2 > icsd-net.112.220 jssmag.149.235 > icsd-net.2 (If the /etc/atalk.names doesn't exist or doesn't contain an entry for some AppleTalk host/net number, addresses are printed in numeric form.) In the first example, NBP (DDP port 2) on net 144.1 node 209 is sending to whatever is listening on port 220 of net icsd node 112.  The second line is the same except the full name of the source node is known (`office').  The third line is a send from port 235 on net jssmag node 149 to broadcast on the icsd-net NBP port (note that the broadcast address (255) is indicated by a net name with no host number - for this reason it's a good idea to keep node names and net names distinct in /etc/atalk.names).
NBP (name binding protocol) and ATP (AppleTalk transaction protocol) packets have their contents interpreted.  Other protocols just dump the protocol name (or number if no name is registered for the protocol) and packet size.
NBP packets are formatted like the following examples: icsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*" jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250 techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186 The first line is a name lookup request for laserwriters sent by net icsd host 112 and broadcast on net jssmag.  The nbp id for the lookup is 190. The second line shows a reply for this request (note that it has the same id) from host jssmag.209 saying that it has a laserwriter resource named "RM1140" registered on port 250.  The third line is another reply to the same request saying host techpit has laserwriter "techpit" registered on port 186.
ATP packet formatting is demonstrated by the following example: jssmag.209.165 > helios.132: atp-req  12266<0-7> 0xae030001 helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000 jssmag.209.165 > helios.132: atp-req  12266<3,5> 0xae030001 helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000 jssmag.209.165 > helios.132: atp-rel  12266<0-7> 0xae030001 jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002 Jssmag.209 initiates transaction id 12266 with host helios by requesting up to 8 packets (the `<0-7>').  The hex number at the end of the line is the value of the `userdata' field in the request.
Helios responds with 8 512-byte packets.  The `:digit' following the transaction id gives the packet sequence number in the transaction and the number in parens is the amount of data in the packet, excluding the ATP header.  The `*' on packet 7 indicates that the EOM bit was set.
Jssmag.209 then requests that packets 3 & 5 be retransmitted.  Helios resends them then jssmag.209 releases the transaction.  Finally, jssmag.209 initiates the next request.  The `*' on the request indicates that XO (`exactly once') was not set.
stty(1), pcap(3PCAP), bpf(4), nit(4P), pcap-savefile(5), pcap-filter(7), pcap-tstamp(7)
https://www.iana.org/assignments/media- types/application/vnd.tcpdump.pcap
The original authors are:
Van Jacobson, Craig Leres and Steven McCanne, all of the Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.
It is currently being maintained by tcpdump.org.
The current version is available via HTTPS:
https://www.tcpdump.org/
The original distribution is available via anonymous ftp:
ftp://ftp.ee.lbl.gov/old/tcpdump.tar.Z
IPv6/IPsec support is added by WIDE/KAME project.  This program uses OpenSSL/LibreSSL, under specific configurations.
To report a security issue please send an e-mail to security@tcpdump.org.
To report bugs and other problems, contribute patches, request a feature, provide generic feedback etc. please see the file CONTRIBUTING in the tcpdump source tree root.
NIT doesn't let you watch your own outbound traffic, BPF will.  We recommend that you use the latter.
On Linux systems with 2.0[.x] kernels:
packets on the loopback device will be seen twice;
packet filtering cannot be done in the kernel, so that all packets must be copied from the kernel in order to be filtered in user mode;
all of a packet, not just the part that's within the snapshot length, will be copied from the kernel (the 2.0[.x] packet capture mechanism, if asked to copy only part of a packet to userspace, will not report the true length of the packet; this would cause most IP packets to get an error from tcpdump);
capturing on some PPP devices won't work correctly.
We recommend that you upgrade to a 2.2 or later kernel.
Some attempt should be made to reassemble IP fragments or, at least to compute the right length for the higher level protocol.
Name server inverse queries are not dumped correctly: the (empty) question section is printed rather than real query in the answer section. Some believe that inverse queries are themselves a bug and prefer to fix the program generating them rather than tcpdump.
A packet trace that crosses a daylight savings time change will give skewed time stamps (the time change is ignored).
Filter expressions on fields other than those in Token Ring headers will not correctly handle source-routed Token Ring packets.
Filter expressions on fields other than those in 802.11 headers will not correctly handle 802.11 data packets with both To DS and From DS set.
ip6 proto should chase header chain, but at this moment it does not.  ip6 protochain is supplied for this behavior.
Arithmetic expression against transport layer headers, like tcp[0], does not work against IPv6 packets.  It only looks at IPv4 packets.
GO-FIX(1)                    General Commands Manual                   GO-FIX(1)
go-fix - update packages to use new APIs
go fix [packages]
Fix runs the Go fix command on the packages named by the import paths.
For more about fix, see 'go doc cmd/fix'. For more about specifying packages, see go-packages(7).
To run fix with specific options, run 'go tool fix'.
go-fmt(1), go-vet(1).
This manual page was written by Michael Stapelberg <stapelberg@debian.org> and is maintained by the Debian Go Compiler Team <team+go-compiler@tracker.debian.org> based on the output of 'go help fix' for the Debian project (and may be used by others).
avahi-browse(1)              General Commands Manual             avahi-browse(1)
avahi-browse - Browse for mDNS/DNS-SD services using the Avahi daemon
avahi-browse [options] service-type
avahi-browse [options] --all
avahi-browse [options] --browse-domains
avahi-browse [options] --dump-db
avahi-browse-domains [options]
Browse for mDNS/DNS-SD network services and browsing domains using the Avahi daemon.
Specify a DNS-SD service type (e.g. _http._tcp) to browse for on the command line, or -a to browse for all available service types. Items that appear on the network are prefixed with "+", items that disappear are prefixed with "-". If --resolve is passed items that are resolved are prefixed with "=".
-a | --all Browse for all service types registered on the LAN, not just the one specified on the command line.
-D | --browse-domains Browse for browsing domains instead for services. avahi-browse- domains is equivalent to avahi-browse --browse-domains
-d | --domain= DOMAIN Browse in the specified domain. If omitted avahi-browse will browse in the default browsing domain (usually: local)
-v | --verbose Enable verbose mode.
-t | --terminate Terminate after dumping a more or less complete list.
-c | --cache Terminate after dumping all entries available in the cache.
-l | --ignore-local Ignore local services, show only remote services.
-r | --resolve Automatically resolve services found.
-f | --no-fail Don't fail if the daemon is not found running. Instead, wait until it appears. If it disconnects, try to reconnect.
-p | --parsable Make output easily parsable for usage in scripts. If enabled fields are separated by semicolons (;), service names are escaped. It is recommended to combine this with --no-db-lookup.
-k | --no-db-lookup Don't lookup services types in service type database.
-b | --dump-db Dump the service type database (may be combined with -k)
-h | --help Show help.
-V | --version Show version information.
The Avahi Developers <avahi (at) lists (dot) freedesktop (dot) org>; Avahi is available from http://avahi.org/
avahi-publish(1), avahi-resolve(1), avahi-daemon(8)
This man page was written using xml2man(1) by Oliver Kurth.
MKVMERGE(1)                       User Commands                      MKVMERGE(1)
mkvmerge - Merge multimedia streams into a Matroska(TM) file
mkvmerge [global options] {-o out} [options1] {file1} [[options2] {file2}] [@options-file.json]
This program takes the input from several media files and joins their streams (all of them or just a selection) into a Matroska(TM) file; see the Matroska(TM) website[1].
Important The order of command line options is important. Please read the section "Option order" if you're new to the program.
Global options -v, --verbose Increase verbosity.
-q, --quiet Suppress status output.
-o, --output file-name Write to the file file-name. If splitting is used then this parameter is treated a bit differently. See the explanation for the --split option for details.
-w, --webm Create a WebM compliant file. This is also turned on if the output file name's extension is "webm". This mode enforces several restrictions. The only allowed codecs are VP8, VP9 video and Opus, Vorbis audio tracks. The DocType header item is changed to "webm".
For chapters and tags only a subset of elements are allowed. mkvmerge(1) will automatically remove all elements not allowed by the specification.
--title title Sets the general title for the output file, e.g. the movie name.
--default-language language-code Sets the default language code that will be used for tracks for which no language is set with the --language option and for which the source container doesn't provide a language.
The default language code is 'und' for 'undefined'.
Segment info handling (global options) --segmentinfo filename.xml Read segment information from an XML file. This file can contain the segment family UID, segment UID, previous and next segment UID elements. An example file and a DTD are included in the MKVToolNix distribution.
See the section about segment info XML files below for details.
--segment-uid SID1,SID2,... Sets the segment UIDs to use. This is a comma-separated list of 128-bit segment UIDs in the usual UID form: hex numbers with or without the "0x" prefix, with or without spaces, exactly 32 digits.
If SID starts with = then its rest is interpreted as the name of a Matroska file whose segment UID is read and used.
Each file created contains one segment, and each segment has one segment UID. If more segment UIDs are specified than segments are created then the surplus UIDs are ignored. If fewer UIDs are specified than segments are created then random UIDs will be created for them.
Chapter and tag handling (global options) --chapter-language language-code Sets the ISO 639-2 language code that is written for each chapter entry. Defaults to 'eng'. See the section about chapters below for details.
This option can be used both for simple chapter files and for source files that contain chapters but no information about the chapters' language, e.g. MP4 and OGM files.
The language set with this option is also used when chapters are generated with the --generate-chapters option.
--chapter-charset character-set Sets the character set that is used for the conversion to UTF-8 for simple chapter files. See the section about text files and character sets for an explanation how mkvmerge(1) converts between character sets.
This switch does also apply to chapters that are copied from certain container types, e.g. Ogg/OGM and MP4 files. See the section about chapters below for details.
--chapter-sync d[,o[/p]] Adjust the timestamps of the chapters in the following source file by d ms. Alternatively you can use the --sync option with the special track ID -2 (see section special track IDs).
o/p: adjust the timestamps by o/p to fix linear drifts.  p defaults to 1 if omitted. Both o and p can be floating point numbers.
Defaults: no manual sync correction (which is the same as d = 0 and o/p = 1.0).
This option can be used multiple times for an input file applying to several tracks by selecting different track IDs each time.
--generate-chapters mode mkvmerge(1) can create chapters automatically. The following two modes are currently supported:
•   'when-appending' – This mode creates one chapter at the start and one chapter whenever a file is appended.
This mode also works with split modes 'parts:' and 'parts-frames:'. For these modes one chapter will be generated for each appended timestamp range (those whose start timestamps are prefixed with '+').
Note mkvmerge(1) requires a video or an audio track to be present in order to be able to determine when a new file is appended. If one or more video tracks are muxed the first one is used. Otherwise the first audio track is used.
•   'interval:time-spec' – This mode creates one chapter at fixed intervals given by time-spec. The format is either the form HH:MM:SS.nnnnnnnnn or a number followed by one of the units 's', 'ms' or 'us'.
Example: --generate-chapters interval:45s
The names for the new chapters are controlled by the option --generate-chapters-name-template. The language is set with --chapter-language which must occur before --generate-chapters.
--generate-chapters-name-template template This sets the name template for chapter names generated by the option --generate-chapters. If the option is not used then default 'Chapter <NUM:2>' will be used.
There are several variables that can be used in the template that are replaced by their actual values when a chapter is generated. The string '<NUM>' will be replaced by the chapter number. The string '<START>' will be replaced by the chapter's start timestamp.
The strings '<FILE_NAME>' and '<FILE_NAME_WITH_EXT>' are only filled when generating chapters for appended files. They will be replaced by the appended file's name wihtout respectively with its extension. Note that only the file's base name and extension are inserted, not its directory or drive components.
You can specify a minimum number of places for the chapter number with '<NUM:places>', e.g. '<NUM:3>'. The resulting number will be padded with leading zeroes if the number of places is less than specified.
You can control the format used by the start timestamp with <START:format>. The format defaults to '%H:%M:%S' if none is given. Valid format codes are:
•   %h – hours
•   %H – hours zero-padded to two places
•   %m – minutes
•   %M – minutes zero-padded to two places
•   %s – seconds
•   %S – seconds zero-padded to two places
•   %n – nanoseconds with nine places
•   %<1-9>n – nanoseconds with up to nine places (e.g. three places with %3n)
--cue-chapter-name-format format mkvmerge(1) supports reading CUE sheets for audio files as the input for chapters.  CUE sheets usually contain the entries PERFORMER and TITLE for each index entry.  mkvmerge(1) uses these two strings in order to construct the chapter name. With this option the format used for this name can be set.
If this option is not given then mkvmerge(1) defaults to the format '%p - %t' (the performer, followed by a space, a dash, another space and the title).
If the format is given then everything except the following meta characters is copied as-is, and the meta characters are replaced like this:
•   %p is replaced by the current entry's PERFORMER string,
•   %t is replaced by the current entry's TITLE string,
•   %n is replaced by the current track number and
•   %N is replaced by the current track number padded with a leading zero if it is < 10.
--chapters file-name Read chapter information from the file file-name. See the section about chapters below for details.
--global-tags file-name Read global tags from the file file-name. See the section about tags below for details.
General output control (advanced global options) --track-order FID1:TID1,FID2:TID2,... This option changes the order in which the tracks for an input file are created. The argument is a comma separated list of pairs IDs. Each pair contains first the file ID (FID1) which is simply the number of the file on the command line starting at 0. The second is a track ID (TID1) from that file. If some track IDs are omitted then those tracks are created after the ones given with this option have been created.
--cluster-length spec Limit the number of data blocks or the duration of data in each cluster. The spec parameter can either be a number n without a unit or a number d postfixed with 'ms'.
If no unit is used then mkvmerge(1) will put at most n data blocks into each cluster. The maximum number of blocks is 65535.
If the number d is postfixed with 'ms' then mkvmerge(1) puts at most d milliseconds of data into each cluster. The minimum for d is '100ms', and the maximum is '32000ms'.
mkvmerge(1) defaults to putting at most 65535 data blocks and 5000ms of data into a cluster.
Programs trying to find a certain frame can only seek directly to a cluster and have to read the whole cluster afterwards. Therefore creating larger clusters may lead to imprecise or slow seeking.
--clusters-in-meta-seek Tells mkvmerge(1) to create a meta seek element at the end of the file containing all clusters. See also the section about the Matroska(TM) file layout.
--timestamp-scale factor Forces the timestamp scale factor to factor. Valid values are in the range 1000..10000000 or the special value -1.
Normally mkvmerge(1) will use a value of 1000000 which means that timestamps and durations will have a precision of 1ms. For files that will not contain a video track but at least one audio track mkvmerge(1) will automatically chose a timestamp scale factor so that all timestamps and durations have a precision of one audio sample. This causes bigger overhead but allows precise seeking and extraction.
If the special value -1 is used then mkvmerge(1) will use sample precision even if a video track is present.
--enable-durations Write durations for all blocks. This will increase file size and does not offer any additional value for players at the moment.
--no-cues Tells mkvmerge(1) not to create and write the cue data which can be compared to an index in an AVI.  Matroska(TM) files can be played back without the cue data, but seeking will probably be imprecise and slower. Use this only if you're really desperate for space or for testing purposes. See also option --cues which can be specified for each input file.
--no-date By default mkvmerge(1) sets the "date" segment information field to the time & date when multiplexing started. With this option that field is not written at all.
--disable-lacing Disables lacing for all tracks. This will increase the file's size, especially if there are many audio tracks. This option is not intended for everyday use.
--disable-track-statistics-tags Normally mkvmerge(1) will write certain tags with statistics for each track. If such tags are already present then they will be overwritten. The tags are BPS, DURATION, NUMBER_OF_BYTES and NUMBER_OF_FRAMES.
Enabling this option prevents mkvmerge(1) from writing those tags and from touching any existing tags with same names.
--disable-language-ietf Normally mkvmerge(1) will write the new IETF BCP 47 language elements in addition to the legacy language elements in track headers, chapters and tags. If this option is used, only the legacy elements are written.
File splitting, linking, appending and concatenation (more global options) --split specification Splits the output file after a given size or a given time. Please note that tracks can only be split right before a key frame. Therefore the split point may be a bit off from what the user has specified.
At the moment mkvmerge(1) supports the following modes:
1. Splitting by size.
Syntax: --split [size:]d[k|m|g]
Examples: --split size:700m or --split 150000000
The parameter d may end with 'k', 'm' or 'g' to indicate that the size is in KB, MB or GB respectively. Otherwise a size in bytes is assumed. After the current output file has reached this size limit a new one will be started.
The 'size:' prefix may be omitted for compatibility reasons.
2. Splitting after a duration.
Syntax: --split [duration:]HH:MM:SS.nnnnnnnnn|ds
Examples: --split duration:00:60:00.000 or --split 3600s
The parameter must either have the form HH:MM:SS.nnnnnnnnn for specifying the duration in up to nano-second precision or be a number d followed by the letter 's' for the duration in seconds. HH is the number of hours, MM the number of minutes, SS the number of seconds and nnnnnnnnn the number of nanoseconds. Both the number of hours and the number of nanoseconds can be omitted. There can be up to nine digits after the decimal point. After the duration of the contents in the current output has reached this limit a new output file will be started.
The 'duration:' prefix may be omitted for compatibility reasons.
3. Splitting after specific timestamps.
Syntax: --split timestamps:A[,B[,C...]]
Example: --split timestamps:00:45:00.000,01:20:00.250,6300s
The parameters A, B, C etc must all have the same format as the ones used for the duration (see above). The list of timestamps is separated by commas. After the input stream has reached the current split point's timestamp a new file is created. Then the next split point given in this list is used.
The 'timestamps:' prefix must not be omitted.
4. Keeping specific parts by specifying timestamp ranges while discarding others.
Syntax: --split parts:start1-end1[,[+]start2-end2[,[+]start3-end3...]]
1. --split parts:00:01:20-00:02:45,00:05:50-00:10:30
2. --split parts:00:01:20-00:02:45,+00:05:50-00:10:30
3. --split parts:-00:02:45,00:05:50-
The parts mode tells mkvmerge(1) to keep certain ranges of timestamps while discarding others. The ranges to keep have to be listed after the parts: keyword and be separated by commas. A range itself consists of a start and an end timestamp in the same format the other variations of --split accept (e.g. both 00:01:20 and 80s refer to the same timestamp).
If a start timestamp is left out then it defaults to the previous range's end timestamp. If there was no previous range then it defaults to the start of the file (see example 3).
If an end timestamp is left out then it defaults to the end of the source files which basically tells mkvmerge(1) to keep the rest (see example 3).
Normally each range will be written to a new file. This can be changed so that consecutive ranges are written to the same file. For that the user has to prefix the start timestamp with a +. This tells mkvmerge(1) not to create a new file and instead append the range to the same file the previous range was written to. Timestamps will be adjusted so that there will be no gap in the output file even if there was a gap in the two ranges in the input file.
In example 1 mkvmerge(1) will create two files. The first will contain the content starting from 00:01:20 until 00:02:45. The second file will contain the content starting from 00:05:50 until 00:10:30.
In example 2 mkvmerge(1) will create only one file. This file will contain both the content starting from 00:01:20 until 00:02:45 and the content starting from 00:05:50 until 00:10:30.
In example 3 mkvmerge(1) will create two files. The first will contain the content from the start of the source files until 00:02:45. The second file will contain the content starting from 00:05:50 until the end of the source files.
Note Note that mkvmerge(1) only makes decisions about splitting at key frame positions. This applies to both the start and the end of each range. So even if an end timestamp is between two key frames mkvmerge(1) will continue outputting the frames up to but excluding the following key frame.
5. Keeping specific parts by specifying frame/field number ranges while discarding others.
Syntax: --split parts-frames:start1-end1[,[+]start2-end2[,[+]start3-end3...]]
1. --split parts-frames:137-258,548-1211
2. --split parts-frames:733-912,+1592-2730
3. --split parts-frames:-430,2512-
The parts-frames mode tells mkvmerge(1) to keep certain ranges of frame/field numbers while discarding others. The ranges to keep have to be listed after the parts-frames: keyword and be separated by commas. A range itself consists of a start and an end frame/field number. Numbering starts at 1.
If a start number is left out then it defaults to the previous range's end number. If there was no previous range then it defaults to the start of the file (see example 3).
If an end number is left out then it defaults to the end of the source files which basically tells mkvmerge(1) to keep the rest (see example 3).
Normally each range will be written to a new file. This can be changed so that consecutive ranges are written to the same file. For that the user has to prefix the start number with a +. This tells mkvmerge(1) not to create a new file and instead append the range to the same file the previous range was written to. Timestamps will be adjusted so that there will be no gap in the output file even if there was a gap in the two ranges in the input file.
Note Note that mkvmerge(1) only makes decisions about splitting at key frame positions. This applies to both the start and the end of each range. So even if an end frame/field number is between two key frames mkvmerge(1) will continue outputting the frames up to but excluding the following key frame. In example 1 mkvmerge(1) will create two files. The first will contain the content starting from the first key frame at or after 137 up to but excluding the first key frame at or after 258. The second file will contain the content starting from 548 until 1211.
In example 2 mkvmerge(1) will create only one file. This file will contain both the content starting from 733 until 912 and the content starting from 1592 until 2730.
In example 3 mkvmerge(1) will create two files. The first will contain the content from the start of the source files until 430. The second file will contain the content starting from 2512 until the end of the source files.
This mode considers only the first video track that is output. If no video track is output no splitting will occur.
Note The numbers given with this argument are interpreted based on the number of Matroska(TM) blocks that are output. A single Matroska(TM) block contains either a full frame (for progressive content) or a single field (for interlaced content). mkvmerge does not distinguish between those two and simply counts the number of blocks. For example: If one wanted to split after the 25th full frame with interlaced content one would have to use 50 (two fields per full frame) as the split point.
6. Splitting after specific frames/fields.
Syntax: --split frames:A[,B[,C...]]
Example: --split frames:120,237,891
The parameters A, B, C etc must all be positive integers. Numbering starts at 1. The list of frame/field numbers is separated by commas. After the input stream has reached the current split point's frame/field number a new file is created. Then the next split point given in this list is used.
The 'frames:' prefix must not be omitted.
7. Splitting before specific chapters.
Syntax: --split chapters:all or --split chapters:A[,B[,C...]]
Example: --split chapters:5,8
The parameters A, B, C etc must all be positive integers. Numbering starts at 1. The list of chapter numbers is separated by commas. Splitting will occur right before the first key frame whose timestamp is equal to or bigger than the start timestamp for the chapters whose numbers are listed. A chapter starting at 0s is never considered for splitting and discarded silently.
The keyword all can be used instead of listing all chapter numbers manually.
The 'chapters:' prefix must not be omitted.
Note The Matroska(TM) file format supports arbitrary deeply nested chapter structures called 'edition entries' and 'chapter atoms'. However, this mode only considers the top-most level of chapters across all edition entries.
For this splitting mode the output filename is treated differently than for the normal operation. It may contain a printf like expression '%d' including an optional field width, e.g. '%02d'. If it does then the current file number will be formatted appropriately and inserted at that point in the filename. If there is no such pattern then a pattern of '-%03d' is assumed right before the file's extension: '-o output.mkv' would result in 'output-001.mkv' and so on. If there's no extension then '-%03d' will be appended to the name.
Another possible pattern is '%c' which will be replaced by the name of the first chapter in the file. Note that when '%c' is present, the pattern '-%03d' will not be added automatically.
--link Link files to one another when splitting the output file. See the section on file linking below for details.
--link-to-previous segment-UID Links the first output file to the segment with the segment UID given by the segment-UID parameter. See the section on file linking below for details.