[Winpcap-users] pcap_fopen_offline not exported?

[Okraszewski, Marcin]

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