[Winpcap-users] Packet random access using file seek

Gisle Vanem gvanem at broadpark.no
Tue Apr 23 01:46:18 PDT 2013


"Pat Marion" <pat.marion at kitware.com> wrote:

> I took a look at the implementation of pcap_hopen_offline().  I see that it
> takes the input FILE* and creates a new FILE* using a series of function
> calls:

Not excactly. It takes an OS low level handle and gives you a 'FILE*'
suitable for the CRT you're using in your program. '_get_osfhandle()' is 
documented here:
  http://msdn.microsoft.com/en-us/library/ks2530z6(v=vs.71).aspx

> _fileno()
> _get_osfhandle()
> _open_osfhandle()
> _fdopen()
> 
> So, if I understand correctly, it is creating a new FILE* that is relative
> to its own CRT.

Yes.

> I think that means I can no longer use any information I
> query about the original input FILE*, because winpcap has created its own
> FILE* stream to read from.
 
But check 'pcap_hopen_offline()' and see that it's calling '_fdopen()'.
The ret-val of that is a 'FILE*' suitable for the CRT winpcap.lib was built
for. I fail to see why that shouldn't work. Unless as Guy hints, the layout 
of 'FILE' is different in your program and what it is in winpcap.lib. 

> So that leads me to think that my plan to use ftell() to record file
> positions of packets, and fseek() to jump to the begining of packets, is
> not going to work on Windows.  What do you think?  

It could be that your Windows problem has something to do with 
I/O buffering. I.e. '_ftell()' is lying (giving you a wrong file-position) since 
your 'FILE*' is buffered. You could try to set the 'FILE* ' to unbuffered with:

  your_file = fopen ("bla-bla.pcpa", "rb");
  ...
  setvbuf (your_file, NULL, _IONBF, 0); 

Ref.
  http://msdn.microsoft.com/en-us/library/86cebhfs(v=vs.71).aspx

--gv


More information about the Winpcap-users mailing list