[Winpcap-users] Packet random access using file seek

[Pat Marion]

Hi,

Here's an update-

I compiled packet.lib and wpcap.lib myself, using Visual Studio 2008.  I
changed the Visual Studio option Runtime Library to Multi-threaded DLL
(link flag /MD) for both solution files.  Inspecting the dlls with
Dependency Walker shows the dependency on MSVCR90.dll.  Still, no luck.
Running my test program I got the same result as before.  I thought that
this should have worked, perhaps I made a mistake along the way.

So, I decided I'd add the functions I needed to the wpcap dll.  I added:

int pcap_fgetpos(pcap_t *p, fpos_t *pos)
{
  return fgetpos(p->sf.rfile, pos);
}

int pcap_fsetpos(pcap_t *p, fpos_t *pos)
{
  return fsetpos(p->sf.rfile, pos);
}

If I use these functions from the wcap.dll then my program runs correctly.
I can live with this for now.

It anyone has other ideas for implementing pcap file seeking, I'd be
interested to know.  Clemens' email suggested I look at Wireshark's wiretap
library.  I read that, and it appears to implement packet seeking, but the
wiretap library may be a larger dependency then I can take on, and I'm not
sure if the library is meant to be used by programs other than Wireshark.

Pat





On Wed, Apr 24, 2013 at 3:49 AM, Guy Harris <guy at alum.mit.edu> wrote:

>
> 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.
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winpcap.org/pipermail/winpcap-users/attachments/20130502/9466e43e/attachment-0001.html>