List about the development of tcpdump

Loris Degioanni | 2 Jun 2005 20:42

Picon

pcap_dump_file & CO

Trying to understand why the -C tcpdump option doesn't work under 
Windows, I realized that a file pointer created in a dll can only be 
used inside that dll. This is a documented Windows limitation.
This means that:

- pcap_dump_file and the other functions to make file pointers explicit 
don't have any meaning in Windows, because any stdio function will fail 
with those pointers, so we should probably return a failure value.

- If we want to have tcpdump -C working in Windows, we'll need to add a 
pcap_ftell() or similar function.

Is it ok if I make these changes and check them in the CVS?

Loris

Guy Harris | 2 Jun 2005 23:30

Picon

Re: pcap_dump_file & CO


On Jun 2, 2005, at 11:42 AM, Loris Degioanni wrote:

> Trying to understand why the -C tcpdump option doesn't work under  
> Windows, I realized that a file pointer created in a dll can only  
> be used inside that dll. This is a documented Windows limitation.

So where is this documented?

Gianluca Varenni | 3 Jun 2005 00:42

Picon

Re: pcap_dump_file & CO


----- Original Message ----- 
From: "Guy Harris" <guy <at> alum.mit.edu>
To: <tcpdump-workers <at> lists.tcpdump.org>
Sent: Thursday, June 02, 2005 2:30 PM
Subject: Re: [tcpdump-workers] pcap_dump_file & CO

>
> On Jun 2, 2005, at 11:42 AM, Loris Degioanni wrote:
>
>> Trying to understand why the -C tcpdump option doesn't work under 
>> Windows, I realized that a file pointer created in a dll can only  be 
>> used inside that dll. This is a documented Windows limitation.
>
> So where is this documented?

Here is a KB documenting it

http://support.microsoft.com/default.aspx?scid=kb;en-us;94248

There is a more specific KB regarding the problem (190799) that *should* be 
available on the MS website at

http://support.microsoft.com/default.aspx?scid=kb;en-us;190799

Unfortunately, the link seems to be broken, now. However you can find such 
knowledge base if you have the MSDN library installed on your machine 
(search for 190799).

Have a nice day

(Continue reading)

Guy Harris | 3 Jun 2005 01:10

Picon

Re: pcap_dump_file & CO

On Jun 2, 2005, at 3:42 PM, Gianluca Varenni wrote:

> Here is a KB documenting it
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;94248

That's a bit nastier - not only can't a C runtime file handle (the  
file descriptors returned by the UNIX-like _open() call and used by  
the UNIX-like _read(), _write(), etc. calls) opened by a DLL be used  
outside the DLL, a file handle opened in the main program can't be  
used outside the main program.  (Presumably a "FILE *" has a C  
runtime file handle associated with it.)

This also breaks APIs such as pcap_fopen_offline() and pcap_dump_fopen 
().

However, it sounds as if that only applies if the DLL is using a  
different version, or different instance, of the C runtime:
     Section 4: Problems Encountered When Using Multiple CRT Libraries

     If an application that makes C Run-time calls links to a DLL  
that also makes C Run-time calls, be aware that if they are both  
linked with one of the statically-linked C Run-time libraries  
(LIBC.LIB or LIBCMT.LIB), the .EXE and DLL will have separate copies  
of all C Run-time functions and global variables. This means that C  
Run-time data cannot be shared between the .EXE and the DLL. Some of  
the problems that can occur as a result are:

         o Passing buffered stream handles from the .EXE/DLL to the

(Continue reading)

Loris Degioanni | 3 Jun 2005 19:10

Picon

Re: pcap_dump_file & CO

Guy,

Guy Harris wrote:
> 
> On Jun 2, 2005, at 3:42 PM, Gianluca Varenni wrote:
> 
>> Here is a KB documenting it
>>
>> http://support.microsoft.com/default.aspx?scid=kb;en-us;94248
> 
> 
> That's a bit nastier - not only can't a C runtime file handle (the  file 
> descriptors returned by the UNIX-like _open() call and used by  the 
> UNIX-like _read(), _write(), etc. calls) opened by a DLL be used  
> outside the DLL, a file handle opened in the main program can't be  used 
> outside the main program.  (Presumably a "FILE *" has a C  runtime file 
> handle associated with it.)
> 
> This also breaks APIs such as pcap_fopen_offline() and pcap_dump_fopen ().
> 
> However, it sounds as if that only applies if the DLL is using a  
> different version, or different instance, of the C runtime:

Yes, but this doesn't solve the problem. You just cannot force the many 
libpcap users on windows to use a specific runtime, telling them that 
otherwise some of the API will not work.
Think for example about this: the user wants to use the default 
(release) WinPcap with a debug version of his application: the library 
wouldn't work, even if it used to work with the release version of his code!

(Continue reading)

Christian Kreibich | 6 Jun 2005 23:33

Re: pcap_dump_file & CO

Hi Loris,

On Fri, 2005-06-03 at 10:10 -0700, Loris Degioanni wrote:
> Guy,
> 
> Guy Harris wrote:
> >
> > However, it sounds as if that only applies if the DLL is using a  
> > different version, or different instance, of the C runtime:
> 
> Yes, but this doesn't solve the problem. You just cannot force the many 
> libpcap users on windows to use a specific runtime, telling them that 
> otherwise some of the API will not work.

I don't understand -- all that is required is that both lib and app
developers pick the shareable CRT (CRTDLL.LIB/MSVCRT.LIB). Why is that a
difficult requirement? To put it another way, why would you *not* want
to use the shareable CRT always, especially with these kinds of issues
presumably well known in the Windows community?

Sorry if that's naive; I'm a very un*x type of guy and my Windows
development experience is limited to a little bit of mingw.

Thanks,
Christian.
--

-- 
________________________________________________________________________
                                          http://www.cl.cam.ac.uk/~cpk25
                                                    http://www.whoop.org

(Continue reading)

Fulvio Risso | 7 Jun 2005 07:51

Picon

Re: pcap_dump_file & CO


> -----Original Message-----
> From: tcpdump-workers-owner <at> lists.tcpdump.org
> [mailto:tcpdump-workers-owner <at> lists.tcpdump.org]On Behalf Of Christian
> Kreibich
> Sent: lunedì 6 giugno 2005 23.33
> To: tcpdump workers
> Subject: Re: [tcpdump-workers] pcap_dump_file & CO
>
>
> Hi Loris,
>
> On Fri, 2005-06-03 at 10:10 -0700, Loris Degioanni wrote:
> > Guy,
> >
> > Guy Harris wrote:
> > >
> > > However, it sounds as if that only applies if the DLL is using a
> > > different version, or different instance, of the C runtime:
> >
> > Yes, but this doesn't solve the problem. You just cannot force the many
> > libpcap users on windows to use a specific runtime, telling them that
> > otherwise some of the API will not work.
>
> I don't understand -- all that is required is that both lib and app
> developers pick the shareable CRT (CRTDLL.LIB/MSVCRT.LIB). Why is that a
> difficult requirement? To put it another way, why would you *not* want
> to use the shareable CRT always, especially with these kinds of issues
> presumably well known in the Windows community?

(Continue reading)

Guy Harris | 7 Jun 2005 09:26

Picon

Re: pcap_dump_file & CO

Fulvio Risso wrote:

> Personally, I never use CRTDLL.LIB/MSVCRT.LIB, because in this case I'm
> forced to distribute my application with tons of DLL (MSVC*.DLL), which are
> far bigger than the application itself.
> Therefore, I'm always using the standard C library.

The difference here, for the benefit of those of us who are used to UN*X 
systems, is, as I understand it, that, unlike UN*X systems, where all 
the dynamically-linked libraries needed to support C are usually shipped 
as part of the OS, not as part of the compiler, that's not the case on 
Windows.

Bruce M Simpson | 7 Jun 2005 10:26

Re: pcap_dump_file & CO

On Tue, Jun 07, 2005 at 12:26:11AM -0700, Guy Harris wrote:
> >Personally, I never use CRTDLL.LIB/MSVCRT.LIB, because in this case I'm
> >forced to distribute my application with tons of DLL (MSVC*.DLL), which are
> >far bigger than the application itself.
> >Therefore, I'm always using the standard C library.
> The difference here, for the benefit of those of us who are used to UN*X 
> systems, is, as I understand it, that, unlike UN*X systems, where all 
> the dynamically-linked libraries needed to support C are usually shipped 
> as part of the OS, not as part of the compiler, that's not the case on 
> Windows.

I believe MSVCRT.DLL is now regarded as an OS component by Microsoft, but
that all other names for this file represent different versions of it
shipped with different MS compilers; MSVCRT.DLL on the other hand is tied
only to the OS and the version of the compiler used to build that version
of the OS.

BMS

Bruce M Simpson | 7 Jun 2005 12:49

XORP, Win32, libpcap, and MSVCRT.DLL

Hi,

This is a bit of a long mail, so I'll address some of the points raised
in a previous thread, and raise some of my own.

MSVCRT.DLL
----------

MinGW uses MSVCRT.DLL explicitly. The newer MS VC++ compilers do not. They may
be configured to do so. The rule is -- don't mix runtime versions, and
all will be fine. See this Python/Win32 thread for more info:
 http://mail.python.org/pipermail/python-list/2004-December/256723.html

I should add this information comes by way of the MinGW lists/forums, and
general inspection of binaries which reside under %SystemRoot% (usually
C:\WINDOWS) -- the .EXEs and .DLLs there generally link to MSVCRT.DLL if they
are written in C or C++ (or in some cases, Visual Basic).

So whilst the compiler itself (MS VC++ 6.x or MinGW) is happy to link and use
what ships with the system (MinGW will link to the MSVCRT.DLL which ships with
the system you build on by default), it's necessary to use headers and import
libraries which match the MSVCRT.DLL version in use (and thus the APIs and
ABIs, i.e. functions and structs etc).

XORP currently builds and links against the shipped system MSVCRT.DLL, by
way of the MinGW toolchain, just like a Windows system .EXE.

The nice thing about this is we don't violate the terms of our own license
by incorporating virally licensed code (CYGWIN1.DLL is GPL, not LGPL), and
we generally work across platforms with a major WINVER of 0x501 and up

(Continue reading)

Guy Harris | 7 Jun 2005 23:25

Picon

Re: XORP, Win32, libpcap, and MSVCRT.DLL

On Jun 7, 2005, at 3:49 AM, Bruce M Simpson wrote:

>  1) Compatibility of WinPcap vs libpcap -- it would be nice if we
>     could build both Win32 and UNIX versions from the same libpcap  
> tree,
>     but this is something we can work around at XORP makefile level;

Build Win32 and UNIX versions of XORP, or of libpcap?

If libpcap, what are the problems that prevent using standard libpcap/ 
WinPcap, built (if necessary) and installed (if necessary) from their  
source trees?

>     as I understand it from the current thread, WinPcap and libpcap  
> are
>     pretty much separate projects -- it would be nice if they could be
>     re-integrated in the same way as libevent and libdnet are.

"Re-integrated" in what sense?

The WinPcap developers track what's done in libpcap, and contribute  
back their changes to the shared portions of the code.

However, unlike UN*Xes, which have a native packet capture mechanism  
that libpcap uses, Windows doesn't - WinPcap also includes drivers  
for Windows OT (95, 98, Me) and NT (NT4, W2K, WXP, W2K3) and  
libraries that talk to the driver, with the actual libpcap portion  
implemented atop the API provided by the library.

(Continue reading)

Guy Harris | 3 Jun 2005 19:40

Picon

Re: pcap_dump_file & CO

Loris Degioanni wrote:

> When were pcap_fopen_offline(), pcap_dump_fopen() and the other FILE 
> related functions introduced?

November 2004:

	https://sourceforge.net/tracker/index.php?func=detail&aid=1051449&group_id=53067&atid=469577

> We still don't export them in WinPcap, and 
> I don't see them in the pcap manual at tcpdump.org yet.

As happens all too often, patches that add new APIs don't include a 
patch to pcap.3.

> At this point wouldn't it make sense to rethink about their inclusion in 
> libpcap 0.9, to avoid introducing possible problems?

I presume Chris Lightfoot had a reason why he wanted to be able to open 
capture files outside of libpcap and have libpcap read or write them, so 
I'd prefer not to remove them from libpcap 0.9; perhaps we could make 
them UN*X-only (yes, that punishes people with the bad luck of having to 
use an OS whose vendor can't figure out how to make something as 
straightforward and useful as passing file descriptors and FILE pointers 
between shared libraries and applications work, but that's life in 
Redmond...).

Guy Harris | 4 Jun 2005 00:30

Picon

Re: pcap_dump_file & CO


On Jun 3, 2005, at 10:40 AM, Guy Harris wrote:

> As happens all too often, patches that add new APIs don't include a  
> patch to pcap.3.

Either that patch did, or I added it, as those routines *are*  
documented in pcap.3.

Loris Degioanni | 3 Jun 2005 23:29

Picon

Re: pcap_dump_file & CO

Guy,

Guy Harris wrote:
> Loris Degioanni wrote:
> 
>> When were pcap_fopen_offline(), pcap_dump_fopen() and the other FILE 
>> related functions introduced?
> 
> 
> November 2004:
> 
>    
https://sourceforge.net/tracker/index.php?func=detail&aid=1051449&group_id=53067&atid=469577 
> 
> 
>> We still don't export them in WinPcap, and I don't see them in the 
>> pcap manual at tcpdump.org yet.
> 
> 
> As happens all too often, patches that add new APIs don't include a 
> patch to pcap.3.
> 
>> At this point wouldn't it make sense to rethink about their inclusion 
>> in libpcap 0.9, to avoid introducing possible problems?
> 
> 
> I presume Chris Lightfoot had a reason why he wanted to be able to open 
> capture files outside of libpcap and have libpcap read or write them, so 
> I'd prefer not to remove them from libpcap 0.9; perhaps we could make 
> them UN*X-only (yes, that punishes people with the bad luck of having to

(Continue reading)

Guy Harris | 4 Jun 2005 00:28

Picon

Re: pcap_dump_file & CO

On Jun 3, 2005, at 2:29 PM, Loris Degioanni wrote:

> Consistency of the API across different platforms, taking into  
> consideration that some of them could have serious rerstrictions,  
> is an advantage for everybody, developer's and maintainers. Not  
> only Chris Lightfoot. And has always been the main strenght of  
> libpcap and tcpdump.

...as long as consistency doesn't mean that Microsoft's limitation  
doesn't constrain UN*X-only applications (and UN*X limitations don't  
constrain Windows-only applications).  I suspect Chris might not be  
the only person who's wanted to do that.

> At least, let's try to make it very clear which part of the API  
> will be usable everywhere: I've worked quite hard to improve this  
> side of the WinPcap 3.1 manual.

That sounds reasonable.  I can update the man page to say those  
functions can only be used on Windows for binaries built with the  
same C runtime as WinPcap - or we could just make them UN*X-only.

> And, I still think that pcap_dump_ftell() could be useful.

I agree, which is why I just checked in a pcap_dump_ftell()  
implementation, and changes to tcpdump to use it (and to supply its  
own implementation, which "knows" that a "pcap_dumper_t *" is a "FILE  
*", for use with older libpcaps; in those older libpcaps, a  
"pcap_dumper_t *" is a "FILE *").

(Continue reading)

Loris Degioanni | 5 Jun 2005 00:04

Picon

Re: pcap_dump_file & CO

I've removed pcap_fopen_offline() and pcap_dump_fopen() from the WinPcap 
exports and manual.
I've added pcap_dump_ftell(), and I've tested everything with the today 
tcpdump sources: -C now works correctly on Windows.
I had to make a small fix to the DSP of tcpdump in order to have 
print-dhcp6.c compile correctly: I've already checked it in the 
tcpdump.org cvs.

Just a small note: pcap_dump_ftell() returns a long, which on most 
platforms (including Windows64) is a 32-bit value. I think this could 
cause problems with capture files bigger than 4 Gigabytes, which by the 
way will be explicitly supported by the new capture format. What about 
returning a u_int64_t?

Loris

Guy Harris wrote:
> 
> On Jun 3, 2005, at 2:29 PM, Loris Degioanni wrote:
> 
>> Consistency of the API across different platforms, taking into  
>> consideration that some of them could have serious rerstrictions,  is 
>> an advantage for everybody, developer's and maintainers. Not  only 
>> Chris Lightfoot. And has always been the main strenght of  libpcap and 
>> tcpdump.
> 
> 
> ...as long as consistency doesn't mean that Microsoft's limitation  
> doesn't constrain UN*X-only applications (and UN*X limitations don't  
> constrain Windows-only applications).  I suspect Chris might not be  the

(Continue reading)

Guy Harris | 5 Jun 2005 00:21

Picon

Re: pcap_dump_file & CO

Loris Degioanni wrote:
> I've removed pcap_fopen_offline() and pcap_dump_fopen() from the WinPcap 
> exports and manual.

OK - should we #ifdef them out on Win32, so that they're not even 
compiled into the library?  (And then update the man page to say "not 
available on Windows".)

> Just a small note: pcap_dump_ftell() returns a long, which on most 
> platforms (including Windows64) is a 32-bit value. I think this could 
> cause problems with capture files bigger than 4 Gigabytes, which by the 
> way will be explicitly supported by the new capture format. What about 
> returning a u_int64_t?

That's not defined on all systems; we'd need to arrange that it do so.

The "obvious" answer would be "pcap_dump_ftello()", but "ftello()" 
returns an "off_t", which I'm not sure Windows defines - and which I 
think differs in type on many UN*X systems depending on whether the 
appropriate large file #define is defined, so we'd be back at "the ABI 
differs depending on how the library was built, which breaks its use 
with applications built differently".

The API should always return a 64-bit value (and we'll want to define 
64-bit integral types when we support Pcap-NG, in any case, as it has 
64-bit counters in the statistics records).

I can probably arrange, with UN*X C compilers (or compilers that started 
out on UN*X, such as the DOS and Windows GCC ports), to make them be 
"long" or "long long" depending on the sizes of those types - I don't

(Continue reading)

Loris Degioanni | 5 Jun 2005 01:12

Picon

Re: pcap_dump_file & CO

Guy Harris wrote:

> Loris Degioanni wrote:
> 
>> I've removed pcap_fopen_offline() and pcap_dump_fopen() from the 
>> WinPcap exports and manual.
> 
> 
> OK - should we #ifdef them out on Win32, so that they're not even 
> compiled into the library?  (And then update the man page to say "not 
> available on Windows".)
> 
>> Just a small note: pcap_dump_ftell() returns a long, which on most 
>> platforms (including Windows64) is a 32-bit value. I think this could 
>> cause problems with capture files bigger than 4 Gigabytes, which by 
>> the way will be explicitly supported by the new capture format. What 
>> about returning a u_int64_t?
> 
> 
> That's not defined on all systems; we'd need to arrange that it do so.

So no all Unix systems have types.h? What about using something like the 
bittypes.h in the missing folder of tcpdump?

> The "obvious" answer would be "pcap_dump_ftello()", but "ftello()" 
> returns an "off_t", which I'm not sure Windows defines - and which I 
> think differs in type on many UN*X systems depending on whether the 
> appropriate large file #define is defined, so we'd be back at "the ABI 
> differs depending on how the library was built, which breaks its use 
> with applications built differently".

(Continue reading)

Guy Harris | 6 Jun 2005 00:07

Picon

Re: pcap_dump_file & CO

Loris Degioanni wrote:

> So no all Unix systems have types.h?

Not all UN*X systems necessarily have a types.h that define u_int64_t or 
uint64_t.

> What about using something like the 
> bittypes.h in the missing folder of tcpdump?

That might be one way.

>> Can the MSVC++ I/O routines handle files >4GB?  In at least some UN*Xes 
> 
> Yes they can.
> 
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_crt__tell.2c_._telli64.asp 
> 
> I'm not sure, however, if there's a 64-bit ftell.

Sorry, I guess that's my UN*Xcentrism - by "I/O routines" I was thinking 
about fopen(), fread(), fwrite(), fseek(), ftell(), etc., not the 
_open()/_read()/_write()/_lseek()-style routines that work like the UNIX 
core I/O routines.

Mark Pizzolato | 5 Jun 2005 13:57

Re: pcap_dump_file & CO

Loris Degioanni wrote:
> Guy Harris wrote:
>
> > Loris Degioanni wrote:

> > Can the MSVC++ I/O routines handle files >4GB?  In at least some UN*Xes
>
> Yes they can.
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_crt__tell.2c_._telli64.asp
>
> I'm not sure, however, if there's a 64-bit ftell.

Well there isn't a 64-bit ftell (the _tell and _telli64 calls are looking at 
a different position than the file position in the buffered environment 
provided by fread and fwrite).  However, you could easily implement one by 
wrapping a call to fgetpos.  In the MS CRTL, a fpos_t is a 64bit integer, 
while on other platforms it may be a structure of some sort.  Accessing 
files greater than 2GB(4GB) were supported before 64bit integers were 
supported by compilers and hardware.  Many platforms still implement a 
fpos_t as a structure so doing arithmetic on an fpos_t isn't going to be 
very portable (Not the concern here).

- Mark Pizzolato

Guy Harris | 6 Jun 2005 00:09

Picon

Re: pcap_dump_file & CO

Mark Pizzolato wrote:
> In the MS CRTL, a fpos_t 
> is a 64bit integer, while on other platforms it may be a structure of 
> some sort.

Does Microsoft explicitly promise that an fpos_t is a 64-bit integer on 
Windows?  (It doesn't matter about UN*X, as ftello() can be used there, 
and, as I understand it, when built with the right options on a UN*X 
platform with standard (Large File Summit) large file support, the off_t 
it returns is larger than 32 bits.)

Mark Pizzolato | 6 Jun 2005 01:37

Re: pcap_dump_file & CO

Guy Harris wrote:
> Mark Pizzolato wrote:
> > In the MS CRTL, a fpos_t
> > is a 64bit integer, while on other platforms it may be a structure of
> > some sort.
>
> Does Microsoft explicitly promise that an fpos_t is a 64-bit integer on
> Windows?

Well, I've used this functionality for going on 8 years and it has been a 
64bit fpos_t.  The include file which defines fpos_t has a legacy definition 
for compiler environments which don't have 64bit data types (i.e. the old 
16bit compilers as a structure of 2 longs).  Winpcap provides Win32 support 
(no support for the pre Win95 Win 3.x world), so it would work fine on all 
supported Windows platforms, and it would be hard to imagine why this would 
change in a way that would hurt us.

> (It doesn't matter about UN*X, as ftello() can be used there,
> and, as I understand it, when built with the right options on a UN*X
> platform with standard (Large File Summit) large file support, the off_t
> it returns is larger than 32 bits.)

This has been my experience as well.

- Mark Pizzolato

mcr | 2 Jun 2005 22:35

Picon

Re: pcap_dump_file & CO


>>>>> "Loris" == Loris Degioanni <loris.degioanni <at> gmail.com> writes:
    Loris> - pcap_dump_file and the other functions to make file
    Loris> pointers explicit don't have any meaning in Windows, because
    Loris> any stdio function will fail with those pointers, so we
    Loris> should probably return a failure value.

    Loris> - If we want to have tcpdump -C working in Windows, we'll
    Loris> need to add a pcap_ftell() or similar function.

  Seems reasonable, but it certainly seems like a Windows.dll silly to me.

    Loris> Is it ok if I make these changes and check them in the CVS?

  Or, maybe "windump" shouldn't be built with a .dll version of libpcap.

--

-- 
] Michael Richardson          Xelerance Corporation, Ottawa, ON |  firewalls  [
] mcr  <at>  xelerance.com           Now doing IPsec training, see   |net architect[
] http://www.sandelman.ca/mcr/    www.xelerance.com/training/   |device driver[
]                    I'm a dad: http://www.sandelman.ca/lrmr/                 [

Guy Harris | 2 Jun 2005 23:32

Picon

Re: pcap_dump_file & CO

On Jun 2, 2005, at 1:35 PM, mcr wrote:

>   Seems reasonable, but it certainly seems like a Windows.dll silly  
> to me.

Yes, but, as per my mail, there are arguably other reasons why  
pcap_dump_ftell() should exist, namely that applications should have  
the idea that a "pcap_dumper_t" is just a "FILE *" wired into them.

>     Loris> Is it ok if I make these changes and check them in the CVS?
>
>   Or, maybe "windump" shouldn't be built with a .dll version of  
> libpcap.

That could be done, but that seems like a bit of a hack - why should  
tcpdump/WinDump have a limitation that other programs using libpcap/ 
WinPcap don't?

Guy Harris | 2 Jun 2005 21:04

Picon

Re: pcap_dump_file & CO

Loris Degioanni wrote:
> Trying to understand why the -C tcpdump option doesn't work under 
> Windows, I realized that a file pointer created in a dll can only be 
> used inside that dll. This is a documented Windows limitation.

Gak.  That sux.  Ethereal's capture file library is also done as a dll
on Windows, and it has a routine to get the FILE * corresponding to a
file being written to, and parts of Ethereal use that; I'm curious
whether that's caused any long-standing problems.

> This means that:
> 
> - pcap_dump_file and the other functions to make file pointers explicit 
> don't have any meaning in Windows, because any stdio function will fail 
> with those pointers, so we should probably return a failure value.

The pcap(3) man page should probably be update to deprecate those
routines, noting that they work only on UN*X.

> - If we want to have tcpdump -C working in Windows, we'll need to add a 
> pcap_ftell() or similar function.

pcap_dump_ftell(), if it works on a pcap_dumper_t.

That should exist even for UN*X, as the current tcpdump code "knows"
that a pcap_dumper_t is really just a FILE * referring to the file,
meaning that if we change what a pcap_dumper_t is, that code won't work.

> Is it ok if I make these changes and check them in the CVS?

(Continue reading)

Return

Return to gmane.network.tcpdump.devel.

Project Web Page

List about the development of tcpdump

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane