Re: MIME type for libpcap-format capture files

[Guy Harris <guy () alum mit edu>]

On Oct 16, 2008, at 1:13 PM, Tyler J. Wagner wrote:

> On Thursday 16 October 2008 20:39:39 Guy Harris wrote:
> > I've considered biting the bullet and writing up a pcap(5) man page,
> > as part of libpcap.  Libpcap 1.0 will probably come out later this
> > month, so perhaps it's time to write it.
>
> Do you mean something like utmp(5)?

Yes.

> If so, I think I can take on the drudgery
> of writing that.  Unless pcap files have become a lot more  
> complicated since
> 0.8.

I've checked one into the main and 1.0 branches.

Some man pages are now generated by the configure script, as the  
section into which they go depends on the OS on which you're  
installing them - in some systems, file formats go into section 5 and  
"miscellaneous information" (such as pcap-filter and pcap-linktype)  
goes into section 7, in other systems file formats go into section 4  
and "miscellaneous information" goes into section 5.  In addition,  
pages that refer to those pages are also generated by the configure  
script.

The file format man page is pcap-savefile(SECTION), where SECTION is  
either 5 or 7.

> On a related subject, what are "extended pcap" files?  Attached is  
> the mime
> type I wrote, recently modified for Phil's recommendations.  I took  
> the pcap
> header values from /usr/share/file/magic, which had four possible  
> values for
> the beginning of a libpcap capture:
>
> 0  ubelong  0xa1b2c3d4      tcpdump capture file (big-endian)
> 0  ulelong  0xa1b2c3d4      tcpdump capture file (little-endian)
> 0  ubelong  0xa1b2cd34      extended tcpdump capture file (big-endian)
> 0  ulelong  0xa1b2cd34      extended tcpdump capture file (little- 
> endian)
>
> What are these last two?

An experimental libpcap file format that I think Alexey Kuznetzov did  
a while ago for Linux, with some extra information in the per-packet  
header.

Unfortunately, in one patch the experimental format used the standard  
magic number, and the next two patches fixed that but produced two  
different extended formats with the same magic number and different  
per-packet headers.  Wireshark goes through some ugly heuristics to  
try to guess which format is being used; Wireshark's capture file code  
assumes it can seek in the capture file, so it can't read from a pipe  
- libpcap supports reading from pipes so doing similar heuristics  
would be more difficult.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.