headers
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
Permalink | Reply | 24 comments |
headers
Guy Harris | 2 Jun 2005 21:04
Picon
Favicon

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)

Permalink | Reply | 0 comments |
headers
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/                 [
Permalink | Reply | 1 comment |
headers
Michael Richardson | 2 Jun 2005 22:39
Picon

hold up on 3.9


The only thing left to do for 3.9 is the Changes file.
At:
	http://www.tcpdump.org/changes/2005-05-27.18:25:04.html

is the summary of all commits since 3.8. If someone wanted to go
through that and condense it down to 10-30 lines...

I have these wet diapers to change...

--

-- 
] 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/                 [
Permalink | Reply | 0 comments |
headers
Guy Harris | 2 Jun 2005 23:30
Picon
Favicon

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?
Permalink | Reply | 20 comments |
headers
Guy Harris | 2 Jun 2005 23:32
Picon
Favicon

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?
Permalink | Reply | 0 comments |
headers
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)

Permalink | Reply | 19 comments |
headers
Guy Harris | 3 Jun 2005 01:10
Picon
Favicon

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)

Permalink | Reply | 18 comments |
headers
Automatic cvs log generator /tcpdump/bin/makelog | 3 Jun 2005 11:08
Picon

Automatic report from sources (tcpdump libpcap htdocs) between 02.06.2005 - 03.06.2005 GMT

CVS log entries from 02.06.2005 (Thu) 09:07:03 - 03.06.2005 (Fri) 09:07:00 GMT
=====================================================
Summary by authors
=====================================================
Author: guy
	File: htdocs/wpcap.html; Revisions: 1.5

Author: hannes
	File: tcpdump/print-bgp.c; Revisions: 1.97, 1.91.2.6

=====================================================
Combined list of identical log entries
=====================================================
Description:
bugfix: we truncate the iso nsap strings by one byte, print next-hop length in the MP_REACH attribute
Modified files:
	File: tcpdump/print-bgp.c; Revision: 1.97;
	Date: 2005/06/03 07:28:24; Author: hannes; Lines: (+7 -5)
	File: tcpdump/print-bgp.c; Revision: 1.91.2.6;
	Date: 2005/06/03 07:31:43; Author: hannes; Lines: (+7 -5)
=====================================================
Log entries
=====================================================
Description:
Update links for WinDump, and remove "currently" from the note on the
WinPcap list (if there's ever a separate WinDump list, we'll update the
page).
Modified files:
	File: htdocs/wpcap.html; Revision: 1.5;
	Date: 2005/06/02 16:51:08; Author: guy; Lines:  (+3 -3)
(Continue reading)

Permalink | Reply | 0 comments |
headers
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)

Permalink | Reply | 17 comments |

Gmane