'Re: [Winpcap-users] pcap_fopen_offline not exported?'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       winpcap-users
Subject:    Re: [Winpcap-users] pcap_fopen_offline not exported?
From:       "Gianluca Varenni" <gianluca.varenni () cacetech ! com>
Date:       2008-08-19 20:53:54
Message-ID: 041701c9023d$b1b85cc0$1a4da8c0 () NELSON2
[Download RAW message or body]

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@pl.compuware.com>
To: <winpcap-users@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@winpcap.org
[mailto:winpcap-users-bounces@winpcap.org] On Behalf Of Gianluca Varenni
Sent: Monday, July 28, 2008 6:06 PM
To: winpcap-users@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@pl.compuware.com>
To: <winpcap-users@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@winpcap.org
> [mailto:winpcap-users-bounces@winpcap.org] On Behalf Of Bryan Kadzban
> Sent: Saturday, July 26, 2008 3:06 PM
> To: winpcap-users@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@winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users@winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users 

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

> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users@winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>
_______________________________________________
Winpcap-users mailing list
Winpcap-users@winpcap.org
https://www.winpcap.org/mailman/listinfo/winpcap-users
[prev in list] [next in list] [prev in thread] [next in thread] 