[Winpcap-users] Packet random access using file seek

[Guy Harris]

On Apr 23, 2013, at 4:11 AM, Pat Marion <pat.marion at kitware.com> wrote:

> Perhaps, as Guy suggests, I am making dangerous assumptions on the pcap file layout,

No, the pcap file layout isn't going to change.

What you might be making is the dangerous assumption that every capture file opened by libpcap/WinPcap will be a pcap file (which is already not true for libpcap, starting with libpcap 1.1.0, and will eventually not be true for WinPcap, either), so *if* your program "knows" that there's a 24-byte header at the beginning of the file and that every record has a 16-byte header, its knowledge is potentially out-of-date.

In addition, if you seek around in a pcap-ng file, you might end up reading blocks such as Interface Description Blocks twice; the current libpcap code assumes it's reading the file sequentially, and doesn't realize that it might have seen an IDB before, and might get confused.  (I'll check whether it'd be confused by that.)

> and my general strategy of using file seeking is one that I will have to ultimately abandon.
> 
> Anyway, the output values depend on the pcap file used for testing.  An example output on macosx:
> 
> File position after pcap_fopen_offline: 24
> File position after pcap_next_ex: 1288
> Expected file position: 1288 
> 
> While on Windows it prints:
> 
> File position after pcap_fopen_offline: 4096
> File position after pcap_next_ex: 4096
> Expected file position: 1288
> 
> My speculation is that file buffering is used by stdio,

That's true, by default, on all platforms.

> and ftell called within the winpcap dll would report the correct file read position, but ftell called by my program returns the location at the end of the read buffer.

More precisely, ftell called by your program is making assumptions about the content of the FILE structure when calculating the read position that are not true about the FILE structure a pointer to which is returned by pcap_fopen_offline(), and, as a result of making that assumption, it's calculating an incorrect value that happens to be the location at the end of the read buffer.