These values are going to be defined in the new version of packet.h that
will be released together with WinPcap 4.0beta in a couple of days.
Loris
Gisle Vanem wrote:
The recent pcap-win32.c adds these link types:
NdisMediumBare80211
NdisMediumRadio80211
Searching MS and Google came up blank
Guy Harris wrote:
Loris Degioanni wrote:
Some genius had the idea of adding a new file (print-slow.c) to the
repository few hours before the x.9.2 release, without at least trying
to recompile on all the platforms. Result: tcpdump 3.9.2 doesn't
compile under Windows (even if it us
Some genius had the idea of adding a new file (print-slow.c) to the
repository few hours before the x.9.2 release, without at least trying
to recompile on all the platforms. Result: tcpdump 3.9.2 doesn't compile
under Windows (even if it used to compile the night before the release).
We alread
yes.
Loris
Michael Richardson wrote:
-BEGIN PGP SIGNED MESSAGE-
"Loris" == Loris Degioanni <[EMAIL PROTECTED]> writes:
Loris> No objection. Me and Gianluca still checked in a couple of
Loris> fixes in the Win32 code, and from that point of view w
No objection.
Me and Gianluca still checked in a couple of fixes in the Win32 code,
and from that point of view we should be ready.
Loris
Michael Richardson wrote:
-BEGIN PGP SIGNED MESSAGE-
Any objection to 0.9.2 going out in the next 20 hours?
- --
] Michael Richardson
Michael Richardson wrote:
-BEGIN PGP SIGNED MESSAGE-
"Loris" == Loris Degioanni <[EMAIL PROTECTED]> writes:
Loris> There is an issue compiling 3.9.1 in Windows. The problem is
Loris> that my last patch to win32\prj\windump.dsp (2005/6/4) was
Lo
Guy Harris wrote:
Loris Degioanni wrote:
There is an issue compiling 3.9.1 in Windows. The problem is that my
last patch to win32\prj\windump.dsp (2005/6/4) was not propagated to
the tcpdump_3_9 branch,
Most of us checking in changes were checking them into both branches, so
we might
There is an issue compiling 3.9.1 in Windows. The problem is that my
last patch to win32\prj\windump.dsp (2005/6/4) was not propagated to the
tcpdump_3_9 branch, and therefore the CVS snapshot compiles, but 3.9.1
fails in print-dhcp6.c.
If you're planning to do a subrelease to fix the -A flag
I just wasn't understanding what was the purpose of the new
pcap_open_pipe() function which, from your first message, seemed to be
public.
But, if I understand your second message, pcap_open_pipe() is private
and called by pcap_open_live().
Loris
Gcom, Inc. wrote:
At 11:37 AM 6/30/2005, you
Gcom, Inc. wrote:
I've added explicit support for named pipes to a winpcap 3.1 beta 4
tree, and would like to submit the changes to the libpcap maintainers.
It adds a new file and small changes to several other files. Who should
I send diffs to, or should I send them to the list? Would a mod
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 "no
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 re
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&#
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
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 h
Gianluca Varenni wrote:
- Original Message - From: "Felipe Kellermann" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, February 09, 2005 2:08 AM
Subject: Re: [tcpdump-workers] PCAP-NG suggestion
On Sun, 13 Feb 2005 2:28pm -0800, Loris Degioanni wrote:
I think a block with dat
I think a block with data that starts at an arbitrary position of the
packet would be useful, but it would be impossible (or at least hard)
for the typical sniffer like Ethereal or tcpdump to dissect it. A
possible solution could be to define a new packet block, so that tools
unable to interpre
Hi,
> In some email I received from Loris Degioanni, sie wrote:
> > Other things:
> > - modern network cards don't almost do buffering. The memory inside the
> > board is usually few KB, and its purpose is providing the space for a
packet
> > or two. The actual
Fulvio, Darren
>
> > > > Is the JIT code easily ported to other platforms ?
> > >
> > > Yes, as far as the platform is Intel ;-)
> >
> > That's fine with me :)
> > Do you have a URL for this ?
>
> http://winpcap.polito.it
> You'll find everything in the source pack.
> Cheers,
As Fulvio said, the
Jefferson,
> Fulvio Risso wrote:
> >>[mailto:[EMAIL PROTECTED] Behalf Of Stephen
> >>Donnelly
> >>
> >>Jefferson Ogata wrote:
> >>>Yes, fully fledged decoded captures would use a lot of extra
> >>disk, but a
> >>>raw no-frills capture could be recorded with maybe only 50% or
> >>so overhead.
> >>
Hi,
> In some email I received from Loris Degioanni, sie wrote:
> [ Charset ISO-8859-1 unsupported, converting... ]
> > Ok, I'm going to add a 8-byte hash option for the packet block. Can
anybody
> > suggest the hashing algorithm?
>
> You obviously sent this before
Hi,
>
> - Original Message -
> From: "Loris Degioanni"
> Sent: Monday, April 12, 2004 2:55 PM
> Subject: Re: [tcpdump-workers] Proposed new pcap format
>
>
>
> > Essentially, what you propose is that the SHB CONTAINS a section rather
> than
Michael,
> -BEGIN PGP SIGNED MESSAGE-
>
>
> >>>>> "Loris" == Loris Degioanni <[EMAIL PROTECTED]> writes:
> Loris> It depends on what "our scribe" means: I'll be around the
> Loris> world during the next mont
Ronnie,
>
> - Original Message -
> From: "Loris Degioanni"
> Sent: Monday, April 12, 2004 2:56 PM
> Subject: Re: [tcpdump-workers] Proposed new pcap format
>
>
> > > I'd prefer a general flag field, which would include a direction
> > &
Ok, I'm going to add a 8-byte hash option for the packet block. Can anybody
suggest the hashing algorithm?
Loris
> In some email I received from Ronnie Sahlberg, sie wrote:
> > Oh, I forgot.
> >
> > Another useful thing to have is an option for the packet block where one
> > would store
> > a re
Hi,
> > 3.3
> > the packet block has a description of which interface the packet was
> > captured on.
> > It should also have a mandatory flag that describes whether we picked
the
> > packet from Rx or Tx on the interface.
> > This should be a mandatory field in the header (1 bit) and not
> > opti
Hi,
> Hi list,
> Im pretty new to this discussion (only joined so i could participate in
this
> discussion)
>
> I have looked at http://www.tcpdump.org/pcap/pcap.html
> and have some comments.
>
>
> 3.1 "this makes the parsing of the file slower but it permits to append
> several capture dumps at
Hi,
> -BEGIN PGP SIGNED MESSAGE-
>
>
> Loris had previously written up an ID on a proposed pcap format.
> It is similar, but not identical to what I had proposed.
>
> It is in xml2rfc (rfc2629) format.
> I can't say if the IETF would or should ever consider publishing it.
> I think it is l
28 matches
Mail list logo
