headers
Fabian Schneider | 2 Jul 2007 08:54
Picon
Favicon

Re: Packet capture performance comparison of


Hi,

> I've read Fabian Schneider's thesis "Performance evaluation of packet
> capturing systems for high-speed networks", which compares capture
> performance under variable testing and generally finds that dual-core
> Opterons perform somewhat better under heavy capture load than dual-core
> Xeons. But now that quad-core Xeons are available, I'm curious whether
> anyone has measured capture improvement using four cores. 

Unfortunately we haven't got such a system by now. But we are trying to 
get one soon. But i do not expect to much improvement regarding the 
difference between dual- and quad-core because i think the main bottleneck 
is the memory accessibility. Nevertheless i think it is necessary by now 
to examine the performance of the new Intel Core processor architecture, 
which could yield major improvments. 

> I should expect four cores to do better, but I'd be interested in any 
> empirical results to that effect. I'm wondering, for example, how close 
> a box with a couple of dual-port PCIe Gb NICs (Endace or nPulse) and 
> dual quad-core processors could come to 4Gb/s aggregate capture speed, 
> while writing some packets to disk. Has anyone out there put together 
> such a box and come up with some performance statistics?

We are hopefully going to do this soon, but i cannot promise a date.

   best
   Fabian

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Max Laier | 3 Jul 2007 12:30
X-Face

Re: About promiscuous mode

On Tuesday 03 July 2007, l0he1g <at> 126.com wrote:
>     I'm a college student,now I'm programing a small sniffer use
> pcaplib.when I put into promiscuous mode as:
> handle=pcap_open_live(dev,SNAP_LEN,1,1000,errbuf); it only can receive
> packets post from or sent to me,cannot inercept any packets from others
> who is in the same LAN(Ethernet).My os is linux,but their are
> Windows.Does this has any matter?And what should I to if I want to
> capture all packets in my LAN?

[this is not necessarily the right mailinglist for this question, but ...]

In a switched LAN you will only see broadcasts and packets destined to the 
address(es) that are advertised behind your switch port.  The sollution 
is:
 a) use the "monitor" port on your switch
 b) use a hub rather than a switch
 c) overflow the forwarding table of your switch to turn it into a hub

The first being the preferred option, of course.

--

-- 
/"\  Best regards,                      | mlaier <at> freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier <at> EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
Permalink | Reply | 1 comment |
headers
Guy Harris | 3 Jul 2007 18:20
Picon
Favicon

Re: About promiscuous mode

Max Laier wrote:

> [this is not necessarily the right mailinglist for this question, but ...]

Well, Wireshark has separate wireshark-dev and wireshark-users lists, 
but tcpdump-workers is really the union of "tcpdump-users", 
"tcpdump-dev", "libpcap-users" ("users" in the sense of people writing 
libpcap-based applications), and "libpcap-dev" ("dev" in the sense of 
people fixing or extending libpcap), so it's probably as good a list as any.

> In a switched LAN you will only see broadcasts and packets destined to the 
> address(es) that are advertised behind your switch port.  The sollution 
> is:
>  a) use the "monitor" port on your switch
>  b) use a hub rather than a switch
>  c) overflow the forwarding table of your switch to turn it into a hub

See

	http://wiki.wireshark.org/CaptureSetup/Ethernet

for more information on capturing on a switched Ethernet.

That page refers to

	http://wiki.wireshark.org/SwitchReference

which has pages for various switch vendors with instructions, or 
pointers to vendor manuals with instructions, on using monitor 
ports/mirrored ports/whatever the vendor calls them.
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Healy | 6 Jul 2007 05:30
Picon
Picon
Favicon

Odd behaviour under Linux 2.6.21


We've encountered some odd behaviour with tcpdump/libpcap under Linux
2.6.21 (debian etch) and are hoping that others might be able to shed
some light on it for us.

The following 2 pcap files are from 2 hosts involved in a short scp
transmission:

http://caia.swin.edu.au/urp/newtcp/files/scp-sender-2.6.21.dmp
http://caia.swin.edu.au/urp/newtcp/files/scp-receiver-2.6.21.dmp

The hosts are connected via a crossover cable and are using gigabit
Intel cards. Jumbo frames are not enabled.

The sender pcap file indicates that some packets that went out were
>1500 bytes in size, however the receiver side says that packets with
the same IP ID were exactly 1500 bytes long.

At first we thought the packets were being truncated, but when we review
the files using tcpdump's -X option, it appears that the packets are
being fragmented and the sender side instance of tcpdump/libpcap is
unaware of it.

The third pcap file is from the sender side of a SCP transfer with the
same setup but under a 2.6.12 kernel (a Knoppix 4.0.2 live cd). It
records all outgoing packets as <= 1500 bytes as expected:

http://caia.swin.edu.au/urp/newtcp/files/scp-sender-2.6.12.dmp

Any tips? This one has us stumped!
(Continue reading)

Permalink | Reply | 501 comments |
headers
James Healy | 6 Jul 2007 07:44
Picon
Picon
Favicon

Re: Odd behaviour under Linux 2.6.21


James Healy wrote:
> We've encountered some odd behaviour with tcpdump/libpcap under Linux
> 2.6.21 (debian etch) and are hoping that others might be able to shed
> some light on it for us.

I've got some more information on this:

I ran the same test under various Linux kernels (using standard Debian
kernel packages), always with the same hardware setup and tcpdump 3.9.5
/ libpcap 0.9.5.

The sending host was running Linux, and the receiving host FreeBSD 6.2.
However we've seen the same behaviour on Linux to Linux transfers.

The following list indicates the kernels under which I observed the odd
behaviour:

2.6.12 - No
2.6.15 - No
2.6.16 - No
2.6.17 - Yes
2.6.18 - Yes
2.6.21 - Yes

So, the next question is, what changed between kernels 2.6.16 and 2.6.17?

James
Permalink | Reply | 502 comments |
headers
Gianluca Varenni | 6 Jul 2007 08:10
Favicon

Re: Odd behaviour under Linux 2.6.21

I guess it's some sort of TCP offloading done at the board level. The driver 
sends big frames (>1500bytes) to the NIC card, and the NIC card is 
responsible from creating smaller segments that are sent over the wire. I've 
seen a similar behavior on Windows with some gigabit network cards (if i 
remember well at least with some broadcom chipsets).

In this case libpcap, like any other software capture engine, captures what 
is passed to the NIC, so it was capture the big frames instead of what's 
actually transmitted on the wire.

Hope it helps
GV

----- Original Message ----- 
From: "James Healy" <jhealy <at> swin.edu.au>
To: <tcpdump-workers <at> lists.tcpdump.org>
Cc: <lastewart <at> swin.edu.au>
Sent: Thursday, July 05, 2007 10:44 PM
Subject: Re: [tcpdump-workers] Odd behaviour under Linux 2.6.21

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> James Healy wrote:
>> We've encountered some odd behaviour with tcpdump/libpcap under Linux
>> 2.6.21 (debian etch) and are hoping that others might be able to shed
>> some light on it for us.
>
> I've got some more information on this:
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Max Laier | 6 Jul 2007 13:42
X-Face

Re: Small configure diff to use pflog header from host

On Saturday 30 June 2007, Max Laier wrote:
> Hi,
>
> the attached makes libpcap and tcpdump use pfvar.h/if_pflog.h from the
> host system (if available) - which is what most people will want[*].
> Tested with OpenBSD 4.1 and FreeBSD where I'm in the progress of doing
> an update to pf which will break the header format - hence the interest
> in this.
>
> Is this something that can be included?  Thanks in advance.

haven't heard back on this one.  Any chance to get it moving, please?

--

-- 
FreeBSD Status reports due: 07/07/07 :-)

/"\  Best regards,                      | mlaier <at> freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier <at> EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
Permalink | Reply | 0 comments |
headers
rmkml | 4 Jul 2007 19:21
Picon
Favicon

tcpdump v3.9.6 archive incorrect version ?

Hello,
Im downloaded last tcpdump v3.9.6 (http://www.tcpdump.org/release/tcpdump-3.9.6.tar.gz),
sha256 cksum : 242b27388ada00d0c40097cef0d56ac5bdbb0a5d81dffb480cdd91b109e10d8d tcpdump-3.9.6.tar.gz
If I untar/ungzip this archive and look on CHANGES files :
  $Header: /tcpdump/master/tcpdump/CHANGES,v 1.87.2.12 2006/09/19 18:24:44 ken Exp $
  Tue.    September 19, 2006. ken <at> xelerance.com. Summary for 3.9.5 tcpdump release
same on another files
This archive contains v395 (not v396)
Libpcap v0.9.6 is ok.
Best Regards
Rmkml
Crusoe Researches
http://www.Crusoe-Researches.com
Permalink | Reply | 5 comments |
headers
Bruce M Simpson | 6 Jul 2007 15:56
Favicon
Gravatar

Re: tcpdump v3.9.6 archive incorrect version ?

I just noticed this too, as I started rolling the FreeBSD port for 
3.9.6/0.9.6.

BMS

rmkml wrote:
> Hello,
> Im downloaded last tcpdump v3.9.6 
> (http://www.tcpdump.org/release/tcpdump-3.9.6.tar.gz),
> sha256 cksum : 
> 242b27388ada00d0c40097cef0d56ac5bdbb0a5d81dffb480cdd91b109e10d8d 
> tcpdump-3.9.6.tar.gz
> If I untar/ungzip this archive and look on CHANGES files :
>  $Header: /tcpdump/master/tcpdump/CHANGES,v 1.87.2.12 2006/09/19 
> 18:24:44 ken Exp $
>  Tue.    September 19, 2006. ken <at> xelerance.com. Summary for 3.9.5 
> tcpdump release
> same on another files
> This archive contains v395 (not v396)
> Libpcap v0.9.6 is ok.
> Best Regards
> Rmkml
> Crusoe Researches
> http://www.Crusoe-Researches.com
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
Permalink | Reply | 4 comments |
headers
Gianluca Varenni | 6 Jul 2007 17:36
Favicon

Re: tcpdump v3.9.6 archive incorrect version ?

Wasn't there supposed to be a x.9.7 release due a couple weeks ago, fixing 
the issue?

Have a nice day
GV

----- Original Message ----- 
From: "Bruce M Simpson" <bms <at> incunabulum.net>
To: <tcpdump-workers <at> lists.tcpdump.org>
Sent: Friday, July 06, 2007 6:56 AM
Subject: Re: [tcpdump-workers] tcpdump v3.9.6 archive incorrect version ?

>I just noticed this too, as I started rolling the FreeBSD port for 
>3.9.6/0.9.6.
>
> BMS
>
> rmkml wrote:
>> Hello,
>> Im downloaded last tcpdump v3.9.6 
>> (http://www.tcpdump.org/release/tcpdump-3.9.6.tar.gz),
>> sha256 cksum : 
>> 242b27388ada00d0c40097cef0d56ac5bdbb0a5d81dffb480cdd91b109e10d8d 
>> tcpdump-3.9.6.tar.gz
>> If I untar/ungzip this archive and look on CHANGES files :
>>  $Header: /tcpdump/master/tcpdump/CHANGES,v 1.87.2.12 2006/09/19 18:24:44 
>> ken Exp $
>>  Tue.    September 19, 2006. ken <at> xelerance.com. Summary for 3.9.5 tcpdump 
>> release
>> same on another files
(Continue reading)

Permalink | Reply | 3 comments |

Gmane