Ethereal-users: Re: [Ethereal-users] Capturing "broken" packets with Ethereal W32 0.8.16?
> Sorry for the somewhat longwinded question;
>
> I've been getting familliar with some network monitoring tools including
> Ethereal to try to shed some light on occasional problems I see with my
> network. (2 3com unmanaged 10baseT hubs connected by fiber, Cisco routers to
> Adtran T-1 CSU/DSU's to other buildings, about 70 mixed Win9x and WinNT
> clients on a WinNT server network running TCP/IP)
>
> Occasionally, I will see instances where network response will go way down,
> it will be almost impossible to login or map a drive. I can watch the hubs
> at these times, and the "packet" light on the hubs is on steady, and
> sometimes there are many collisions.
>
> In an attempt to find out what is happening, I fire up Ethereal, but the
> program captures few packets; this morning about 1000 in maybe 20/30
> seconds. When I look at the decoded packets, I don't see anything that looks
> "out of whack" to my untrained eye. In other words, I only see the same kind
> of traffic that I see normally when the network is "OK".
>
> In reading the website of a large supplier of network monitoring software, I
> got the impression that the ability to capture "broken" or "Incorrect"
> packets is dependent on the combination of the Packet driver and the actual
> network interface card used. "Of course, they recommend their own!"
>
> Is there any truth to this?
Well, that depends on what you mean by "broken" and "incorrect".
If a packet has a bogus IP or TCP header, say, few if any network cards
will know the difference - they'll happily receive the packet, and the
driver will just pass it up through the networking code (on BSD I'm
including the BPF code in "the networking code"), so a packet capture
program should see it.
However, if the packet is a "runt" packet (Ethernet packet shorter than
60 bytes + 4 bytes of CRC, as I remember), or a packet with a bad CRC,
the card may well not provide the packet to the host, or the driver may
well discard it before handing it to the networking code, so a capture
program might not see it.
Now, another possibility might be that Ethereal, or the WinPcap driver,
or the NT networking code, might be having trouble keeping up with the
networking traffic - as you're running in promiscuous mode, there may
well be a *LOT* of traffic on your network segment, although, if it's
only 10baseT, that might not be too bad.
