[Winpcap-users] pcap_fopen_offline not exported?

[Okraszewski, Marcin]

Here is the sample. It starts tshark to convert a trace to libpap and
prints information from pcap header for each packet.

Paths assume it will be in Examples-pcap.

Marcin



-----Original Message-----
From: winpcap-users-bounces at winpcap.org
[mailto:winpcap-users-bounces at winpcap.org] On Behalf Of Gianluca Varenni
Sent: Monday, July 28, 2008 6:06 PM
To: winpcap-users at winpcap.org
Subject: Re: [Winpcap-users] pcap_fopen_offline not exported?

I can definitely try to include it in the next version of WinPcap (4.1 
branch, not in the 4.0.x stable). Can you send me a sample that I can 
include in the developer's pack for it?

Have a nice day
GV

----- Original Message ----- 
From: "Okraszewski, Marcin" <Marcin.Okraszewski at pl.compuware.com>
To: <winpcap-users at winpcap.org>
Sent: Monday, July 28, 2008 6:45 AM
Subject: RE: [Winpcap-users] pcap_fopen_offline not exported?


> So I have it working now. I have slightly modified WinPcap to make the
> API expose the pcap_fopen_offline():
>
> In pcap.h I have added:
> -------------------------------------------------------
> #ifndef LIBPCAP_EXPORTS
> #define pcap_fopen_offline(f,b) \
>        pcap_hopen_offline(_get_osfhandle(_fileno(f)), b)
> #endif
>
> pcap_t  *pcap_hopen_offline(intptr_t, char *);
> -------------------------------------------------------
>
>
> Then in savefile.c:
> -------------------------------------------------------
> pcap_t* pcap_hopen_offline(intptr_t osfd, char *errbuf)
> {
>    int fd;
>    FILE *file;
>
>    fd = _open_osfhandle(osfd, _O_RDONLY);
>    if ( fd < 0 ) {
>        strerror_s(errbuf, PCAP_ERRBUF_SIZE, errno);
> return NULL;
>    }
>
>    file = _fdopen(fd, "rb");
>    if ( file == NULL ) {
>        strerror_s(errbuf, PCAP_ERRBUF_SIZE, errno);
>        return NULL;
>    }
>    return pcap_fopen_offline(file, errbuf);
> }
> -------------------------------------------------------
>
>
> And finally I have added the pcap_hopen_offline to exports in
wpcap.def.
>
>
> Thank you all for input in this matter. Is there any chance this kind
of
> solution to be included in WinPcap?
>
> Thanks,
> Marcin
>
>
>
>
> The contents of this e-mail are intended for the named addressee only.
It 
> contains information that may be confidential. Unless you are the
named 
> addressee or an authorized designee, you may not copy or use it, or 
> disclose it to anyone else. If you received it in error please notify
us 
> immediately and then destroy it.
>
>
> Compuware sp. z o.o. (registration number KRS 595) is a company
registered 
> in Poland whose registered office is at Ul. Dmowskiego 12,80-264
Gdansk 
> Rejestr handlowy KRS 0000000595 Sadu Rejonowego Gdansk-Polnoc w
Gdansku 
> VII Wydzial Gospodarczy Kapital zakladowy 1.140.000 zl oplacony
gotowka; 
> NIP: 584-20-88-050; REGON: 191352920
>
>
> From: winpcap-users-bounces at winpcap.org
> [mailto:winpcap-users-bounces at winpcap.org] On Behalf Of Bryan Kadzban
> Sent: Saturday, July 26, 2008 3:06 PM
> To: winpcap-users at winpcap.org
> Subject: Re: [Winpcap-users] pcap_fopen_offline not exported?
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
> Fish wrote:
>> But the point is, the exported function's prototype could include
>> either a regular file descriptions (int fd) or a Win32 HANDLE
>
> HANDLE, yes.  File descriptor, no; an integer file descriptor is a CRT
> library construction on win32 (likely an index into a table of
HANDLEs,
> possibly plus a few other things, that's private to the run-time
> library), and therefore can't be passed from one CRT to another.  At
> best, it'll return errors when you try to use it (it may also crash);
at
> worst, it'll perform operations on some completely unrelated file.
>
>> but you must still be careful not to have two different modules
>> reading/writing to the same CRT file.
>
> Not just the same CRT file.  You can't use the HANDLE that you passed
> in to _open_osfhandle() *at all*, according to the docs that Guy
Harris
> just posted.  Operations like changing the file pointer that's held in
> that HANDLE will break the assumptions made by the CRT's file
operation
> functions.
>
>> Now of course if both modules were instead always using the Win32
>> file HANDLES to do all their file accessing with (and NOT the C/C++
>> Runtime handle), then again there would NOT be any problem.
>
> I don't know that for sure.  If you opened a file twice, and got two
> HANDLEs to it, then you would probably be correct.  If you opened the
> file once, passed the HANDLE off to other code, and both pieces of
code
> used it (directly), I think the bits of code would probably step on
each
> other.  Because I believe the file pointer is held in the HANDLE -- at
> least unless you're doing overlapped I/O.  That *might* be safe,
because
> the file position pointers are held in the OVERLAPPED struct.  But
there
> may be other bits of information that are held in the HANDLE that
can't
> be shared between two pieces of code.
>
> But using DuplicateHandle (on a normal file, not a socket) should be
> fine.
>
>> The only time a problem comes into play is when two different C/C++
>> Runtimes try accessing the same underlying Win32 File object at the
>> same time using their own CRT file descriptions or buffered FILE*
>> pointers. THAT is the only thing that is dangerous.
>
> Not using overlapped I/O on a normal Win32 HANDLE is dangerous as
well.
> So is using the HANDLE at the same time as a FILE* or a file
descriptor
> that was opened from that HANDLE.  This is not an exhaustive list,
> either; there may be other unsafe operations.
>
>> But as long as only ONE module is ultimately responsible for doing
>> ALL of the read/writing, then there's nothing preventing you from
>> simply changing the prototype of the exported function's parameters
>> to use 'int fd' or HANDLE instead of the existing/dangerous FILE*
>> pointer.
>
> HANDLE, yes.  'int fd', no; see the first paragraph.  ;-)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFIiyFPS5vET1Wea5wRAxKqAJ4pavkGgwZaxI2bmOafQ89x2k5AzgCggzVO
> IkwoBahm6eF7/OiSPw+Fi1g=
> =drRm
> -----END PGP SIGNATURE-----
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users 

_______________________________________________
Winpcap-users mailing list
Winpcap-users at winpcap.org
https://www.winpcap.org/mailman/listinfo/winpcap-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pcap_fopen.zip
Type: application/x-zip-compressed
Size: 6262 bytes
Desc: pcap_fopen.zip
Url : http://www.winpcap.org/pipermail/winpcap-users/attachments/20080730/de1eb347/pcap_fopen.bin