[Winpcap-users] pcap_fopen_offline not exported?
Gianluca Varenni
gianluca.varenni at cacetech.com
Tue Aug 19 20:53:54 GMT 2008
Marcin,
I'm including your small sample in the devpack of WinPcap.
Is it ok for you to put the copyright below at the beginning of
the source file?
Have a nice day
GV
/*
* Copyright (c) 2008 CACE Technologies, Davis (California)
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. Neither the name of CACE Technologies nor the names of its
* contributors may be used to endorse or promote products derived from
* this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
* This sample was contributed by
* Marcin Okraszewski (Marcin.OkraszewskiATpl.compuware.com)
*
*/
----- Original Message -----
From: "Okraszewski, Marcin" <Marcin.Okraszewski at pl.compuware.com>
To: <winpcap-users at winpcap.org>
Sent: Wednesday, July 30, 2008 6:34 AM
Subject: RE: [Winpcap-users] pcap_fopen_offline not exported?
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
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>
More information about the Winpcap-users
mailing list