"Pat Marion" <[email protected]> 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
_______________________________________________
Winpcap-users mailing list
[email protected]
https://www.winpcap.org/mailman/listinfo/winpcap-users
