Hi.
-Messaggio Originale-
Da: Michael T. Stolarchuk <[EMAIL PROTECTED]>
A: Loris Degioanni <[EMAIL PROTECTED]>
Data invio: giovedì 14 dicembre 2000 16.39
Oggetto: Re: R: [tcpdump-workers] Re: R: [Ethereal-dev] Re: Fwd:
kyxtech: freebsd outsniffed by wintendo !!?!?
>
>
On 12 Dec, Fulvio Risso wrote:
> I do not agree with you.
> Partially supported by Ms Research means that we got:
> - software
> - 1 Dell workstation
>
> That's it.
> I *strongly* suggest to ask someone before opening your mouth.
>
Your tone strongly suggest your research is less than
objective
In message <009801c065c0$a2bd1200$016464c8@lorix>, "Loris Degioanni" writes:
>
>-Messaggio Originale-
>Da: Michael T. Stolarchuk <[EMAIL PROTECTED]>
>A: Fulvio Risso <[EMAIL PROTECTED]>
>freebsd outsniffed by wintendo !!?!?
WRT: http://netgroup-serv.polito.it/winpcap/docs/performance.htm
;[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Data invio: martedì 12 dicembre 2000 17.22
Oggetto: [tcpdump-workers] Re: R: [Ethereal-dev] Re: Fwd: kyxtech:
freebsd outsniffed by wintendo !!?!?
>
>
> typical buffer sizes for bpf these days are still 32K,
> One could then say that
Fulvio Risso wrote:
>
> I do not agree with you.
> Partially supported by Ms Research means that we got:
> - software
> - 1 Dell workstation
>
> That's it.
> I *strongly* suggest to ask someone before opening your mouth.
Mr. Risso, you should know that jessem (who seems to be JMJr. in masquerad
In message <000701c06453$b2e83740$[EMAIL PROTECTED]>, "Fulvio Risso" writes:
>I do not agree with you.
>Partially supported by Ms Research means that we got:
>- software
>- 1 Dell workstation
>
>That's it.
>I *strongly* suggest to ask someone before opening your mouth.
>Cheers,
>
>fulvio
>
>PS
PROTECTED]>
Sent: Tuesday, December 12, 2000 3:36 PM
Subject: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo
!!?!?
>
>
> On 7 Dec, Dragos Ruiu wrote:
> >
> > (Hurm Wintendo outperforming unix???!?? Something's
> > improper about this,
On 2000-12-11 10:49 +0100, Loris Degioanni <[EMAIL PROTECTED]> wrote:
> > # sysctl -w debug.bpf_bufsize=32768 debug.bpf_maxbufsize=4194304
> >
> > makes the default buffer size 32K and limits the size to 4MB, for
> > example.
>
> Notice however that in pcap-bpf.c, pcap_open_live() forces the buf
> On 2000-12-08 00:38 -0800, Guy Harris <[EMAIL PROTECTED]> wrote:
> > (Both FreeBSD and OpenBSD have the maximum buffer size for BPF as
512KB
> > in the top of the CVS tree; NetBSD still has it as 32K.)
>
> You can change both the default and maximum BPF buffer sizes at
> run time (affecting an s
On 2000-12-08 00:38 -0800, Guy Harris <[EMAIL PROTECTED]> wrote:
> (Both FreeBSD and OpenBSD have the maximum buffer size for BPF as 512KB
> in the top of the CVS tree; NetBSD still has it as 32K.)
You can change both the default and maximum BPF buffer sizes at
run time (affecting an subsequent
On Thu, Dec 07, 2000 at 11:39:58PM -0800, Guy Harris wrote:
> Or, as per my other mail, perhaps using, on Windows, a version of the
> standard I/O library that does bigger writes, hence fewer system calls.
Nope. According to "strace for NT":
http://www.securiteam.com/tools/Strace_for_N
:> or with a redirect from tcpdump on a shell line,
:
:Assuming, as I suspect is the case, that they're using the same command
:on the OSes in question (or using "tcpdump" on FreeBSD and "windump" on
:Windows), that's also unlikely - it's just "{tcp,win}dump -w test.acp".
It amounts to th
On Thu, Dec 07, 2000 at 11:38:09PM -0800, Matt Dillon wrote:
> It amounts to the same thing, since -w does nothing more then an
> fopen(..."w"). You get a pidly 8K buffer out of that, and it isn't
> even double buffered.
>
> But I think the last poster had it right... if the bpf
On Thu, Dec 07, 2000 at 09:47:20PM -0800, Matt Dillon wrote:
> Looking at the data I would guess that they
> are appending to a file using write()'s on a packet-by-packet basis
Or, as per my other mail, perhaps using, on Windows, a version of the
standard I/O library that does bigger writ
On Thu, Dec 07, 2000 at 09:47:20PM -0800, Matt Dillon wrote:
> Looking at the data I would guess that they
> are appending to a file using write()'s on a packet-by-packet basis
Unlikely, given that they're using "tcpdump", which, with the "-w" flag,
writes using standard I/O, and doesn't
15 matches
Mail list logo
