"Pat Marion" <[email protected]> wrote:
This works, but seeking on the file pointer using ftell/fseek does not
work. For example, on linux ftell() will return the offset 24 after
pcap_fopen_offline(), while on Windows the returned file offset is 4096.
So it appears that my plan to use file seeking may not be possible on
Windows. I am using the winpcap 4.1.2 development package and dll.
I think your problems stems from this ugliness in <pcap/pcap.h>:
#if defined(WIN32)
pcap_t *pcap_hopen_offline(intptr_t, char *);
#if !defined(LIBPCAP_EXPORTS)
#define pcap_fopen_offline(f,b) \
pcap_hopen_offline(_get_osfhandle(_fileno(f)), b)
#else /*LIBPCAP_EXPORTS*/
static pcap_t *pcap_fopen_offline(FILE *, char *);
#endif
#else /*WIN32*/
pcap_t *pcap_fopen_offline(FILE *, char *);
#endif /*WIN32*/
(indented for clarity). But since there's several variant of this
in the official libpcap vs. WinPcap, it's hard to tell what code
you're using.
Anyway, when you call 'pcap_fopen_offline()' in the DLL (with it's
own independent C-runtime lib), it expects the 'FILE *fp' argument to
be relative to this CRT. But it's not apparently not. You give
winpcap.dll a 'fp' that is relative to *your* C-runtime library. I.e.
you're mixing data between boundaries. This is a big no-no on Windows.
Remember that stuff related to 'FILE *fp' data is just an address
into an '_iotab[]' array (check <stdio.h>. While '_get_osfhandle'
returns a low level OS file descriptor.
Your code was probably built with '-DLIBPCAP_EXPORTS' (it's default).
The fix could be to put something like this in your code (untested):
#undef pcap_fopen_offline
#define pcap_fopen_offline(fp,err_buf) \
pcap_hopen_offline (_get_osfhandle(_fileno(fp)), err_buf)
Ref. the docs on _get_osfhandle():
http://msdn.microsoft.com/en-us/library/ks2530z6(v=vs.71).aspx
--gv
_______________________________________________
Winpcap-users mailing list
[email protected]
https://www.winpcap.org/mailman/listinfo/winpcap-users
