blob: a7ae9afbce4860149d1766a5a4e5cc33578708d2 [file] [log] [blame]
JP Abgrall511eca32014-02-12 13:46:45 -08001.\" Copyright (c) 1994, 1996, 1997
2.\" The Regents of the University of California. All rights reserved.
3.\"
4.\" Redistribution and use in source and binary forms, with or without
5.\" modification, are permitted provided that: (1) source code distributions
6.\" retain the above copyright notice and this paragraph in its entirety, (2)
7.\" distributions including binary code include the above copyright notice and
8.\" this paragraph in its entirety in the documentation or other materials
9.\" provided with the distribution, and (3) all advertising materials mentioning
10.\" features or use of this software display the following acknowledgement:
11.\" ``This product includes software developed by the University of California,
12.\" Lawrence Berkeley Laboratory and its contributors.'' Neither the name of
13.\" the University nor the names of its contributors may be used to endorse
14.\" or promote products derived from this software without specific prior
15.\" written permission.
16.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
17.\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
18.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
19.\"
Haibo Huangee759ce2021-01-05 21:34:29 -080020.TH PCAP-SAVEFILE @MAN_FILE_FORMATS@ "24 April 2020"
JP Abgrall511eca32014-02-12 13:46:45 -080021.SH NAME
22pcap-savefile \- libpcap savefile format
23.SH DESCRIPTION
24NOTE: applications and libraries should, if possible, use libpcap to
Elliott Hughesd8845d72015-10-19 18:07:04 -070025read savefiles, rather than having their own code to read savefiles.
JP Abgrall511eca32014-02-12 13:46:45 -080026If, in the future, a new file format is supported by libpcap,
27applications and libraries using libpcap to read savefiles will be able
28to read the new format of savefiles, but applications and libraries
29using their own code to read savefiles will have to be changed to
30support the new file format.
31.PP
32``Savefiles'' read and written by libpcap and applications using libpcap
33start with a per-file header. The format of the per-file header is:
34.RS
35.TS
36box;
37c s
38c | c
39c s.
40Magic number
41_
42Major version Minor version
43_
44Time zone offset
45_
46Time stamp accuracy
47_
48Snapshot length
49_
50Link-layer header type
51.TE
52.RE
53.PP
Haibo Huangee759ce2021-01-05 21:34:29 -080054The per-file header length is 24 octets.
55.PP
JP Abgrall511eca32014-02-12 13:46:45 -080056All fields in the per-file header are in the byte order of the host
57writing the file. Normally, the first field in the per-file header is a
584-byte magic number, with the value 0xa1b2c3d4. The magic number, when
59read by a host with the same byte order as the host that wrote the file,
60will have the value 0xa1b2c3d4, and, when read by a host with the
61opposite byte order as the host that wrote the file, will have the value
620xd4c3b2a1. That allows software reading the file to determine whether
63the byte order of the host that wrote the file is the same as the byte
64order of the host on which the file is being read, and thus whether the
65values in the per-file and per-packet headers need to be byte-swapped.
66.PP
67If the magic number has the value 0xa1b23c4d (with the two nibbles of
68the two lower-order bytes of the magic number swapped), which would be
69read as 0xa1b23c4d by a host with the same byte order as the host that
70wrote the file and as 0x4d3cb2a1 by a host with the opposite byte order
71as the host that wrote the file, the file format is the same as for
72regular files, except that the time stamps for packets are given in
73seconds and nanoseconds rather than seconds and microseconds.
74.PP
75Following this are:
76.IP
77A 2-byte file format major version number; the current version number is
782.
79.IP
80A 2-byte file format minor version number; the current version number is
814.
82.IP
83A 4-byte time zone offset; this is always 0.
84.IP
85A 4-byte number giving the accuracy of time stamps in the file; this is
86always 0.
87.IP
88A 4-byte number giving the "snapshot length" of the capture; packets
89longer than the snapshot length are truncated to the snapshot length, so
90that, if the snapshot length is
91.IR N ,
92only the first
93.I N
94bytes of a packet longer than
95.I N
96bytes will be saved in the capture.
97.IP
98a 4-byte number giving the link-layer header type for packets in the
99capture; see
100.BR pcap-linktype (@MAN_MISC_INFO@)
101for the
102.B LINKTYPE_
103values that can appear in this field.
104.PP
105Following the per-file header are zero or more packets; each packet
106begins with a per-packet header, which is immediately followed by the
107raw packet data. The format of the per-packet header is:
108.RS
109.TS
110box;
111c.
112Time stamp, seconds value
113_
114Time stamp, microseconds or nanoseconds value
115_
116Length of captured packet data
117_
118Un-truncated length of the packet data
119.TE
120.RE
121.PP
Haibo Huangee759ce2021-01-05 21:34:29 -0800122The per-packet header length is 16 octets.
123.PP
JP Abgrall511eca32014-02-12 13:46:45 -0800124All fields in the per-packet header are in the byte order of the host
125writing the file. The per-packet header begins with a time stamp giving
126the approximate time the packet was captured; the time stamp consists of
127a 4-byte value, giving the time in seconds since January 1, 1970,
12800:00:00 UTC, followed by a 4-byte value, giving the time in
129microseconds or nanoseconds since that second, depending on the magic
130number in the file header. Following that are a 4-byte value giving the
131number of bytes of captured data that follow the per-packet header and a
1324-byte value giving the number of bytes that would have been present had
133the packet not been truncated by the snapshot length. The two lengths
134will be equal if the number of bytes of packet data are less than or
135equal to the snapshot length.
136.SH SEE ALSO
Haibo Huangee759ce2021-01-05 21:34:29 -0800137.BR pcap (3PCAP)