Re: Failing to capture packets....

[Stephen Donnelly <stephen () endace com>]

Most commercial NICs only deliver well formed Ethernet packets (valid
size, correct FCS) to the operating system, and also generally strip out
Ethernet control frames such as 'pause' indications.

Because of this Libpcap would not have any data to deliver to the
capturing application.

You may have to get hold of low level Ethernet test equipment in order
to determine exactly what is there.

Stephen.

On Tue, 2007-01-23 at 12:11 -0600, Paul Armor wrote:
> Hi,
> after Guy's last email where he states:
> "Tcpdump supports capturing *all* network traffic;"
>
> I feel compelled to again ask if anyone can offer any suggestions on how I 
> can achieve my goal of capturing the data I'm seeing on my ethernet 
> segment...  To what I wrote earlier I'd also add that the Force10 switch 
> that's upstream of these systems records a lot of "throttle" packets on 
> that interface.
>
> Any help would be appreciated!
>
> Thanks!
> Paul
>
>
> On Fri, 19 Jan 2007, Paul Armor wrote:
>
> > Hi,
> > I've got a problem that's strange on various levels and using tcpdump isn't 
> > as helpful as I'd have hoped.  Can anyone offer suggestions on how to 
> > capture/interpret my bad data on the wire?  I'm trying to capture from any of 
> > a few other machines with Broadcomm chips, and am wondering if there's a 
> > limitation to hardware/driver that prevents tcpdump/libpcap from "seeing" 
> > that data?
> >
> > Generally speaking, I'm trying to capture data on the wire that's coming from 
> > a computer that's crashed.  That sounds simple enough...
> >
> > BUT, here's the rub... the driver and thus tcpdump/ethereal don't recognize 
> > any "packets", but there's data spraying on the wire, so I don't think 
> > they're at all properly formed ethernet packets.  Here's some interesting 
> > ifconfig (linux 2.6) output:
> >
> > eth0      Link encap:Ethernet  HWaddr 00:14:22:D1:16:B1
> >          RX packets:2491 errors:0 dropped:0 overruns:0 frame:21
> >          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
> >          collisions:0 txqueuelen:1000
> >          RX bytes:2910464 (2.7 MiB)  TX bytes:492 (492.0 b)
> >
> >
> > eth0      Link encap:Ethernet  HWaddr 00:14:22:D1:16:B1
> >          RX packets:2491 errors:0 dropped:0 overruns:0 frame:21
> >          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
> >          collisions:0 txqueuelen:1000
> >          RX bytes:2940992 (2.8 MiB)  TX bytes:492 (492.0 b)
> >
> > Note how RX packets does NOT increase, while RX bytes does.  These two 
> > ifconfig's were run about 1 sec apart from another machine attached via 
> > Xover.  I didn't pay attention to the occurance of the "frame" pkts...
> >
> > How this happens is that I've got a large number of machines running a Fedora 
> > install, and certain users jobs are able to tickle a problem with 
> > memory/memory-controller/CPU (everybody's blaming everybody else), which 
> > sometimes (~60% of the time) causes a crashed machine (a Machine Check 
> > Exception) to start spraying the network with crap.  This crap causes a 
> > broadcast/multicast cache/buffer to overflow on a big Force 10 switch, which 
> > causes other machines to "drop off the network" (as ARP fails, etc).
> >
> > I suspect a problem with BIOS on motherboard or firmware on embedded ethernet 
> > controller (Broadcomm (BCM95704A6) rev 2100 PHY(5704))... and am looking for 
> > evidence.
> >
> > ANY help/suggestions would be greatly appreciated!
> >
> > Thanks!
> > Paul
> k
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
-- 
-----------------------------------------------------------------------
    Stephen Donnelly BCMS PhD           email: sfd () endace com
    Endace Technology Ltd               phone: +64 7 839 0540
    Hamilton, New Zealand               cell:  +64 21 1104378
-----------------------------------------------------------------------

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.