[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