ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Wireshark-users: Re: [Wireshark-users] Two questions on wireshark

From: Sake Blok <sake@xxxxxxxxxx>
Date: Thu, 27 Sep 2007 00:59:14 +0200
On Wed, Sep 26, 2007 at 03:41:09PM +0200, Matthias Feurstein wrote:
> 1: How good does Wireshark perform with gigabit ethernet? For example
> occasionally I have a burst of "ACKed Lost Segment" packets (about a dozen,
> sometimes more, sometimes less) coming from the hw we are testing. It looks
> like erroneous behavior by the component I am testing since there is very
> little time between these packets (some us's) but I wonder if maybe
> wireshark might miss some packets?

Wireshark itself does not perform as good since it needs to keep state of
conversations. It shows you an indication on how many packets it was 
not able to process in the discarded packets in the summary.

However, Wireshark uses the executable dumpcap to do the actual 
capturing. Dumpcap has been written to do *just* that. Capture
packets and write them to disk. It is very good at it's task :-)

Whether it can keep up with a full Gbit/s load is up to the type
of card used, the drivers and OS used and the CPU and mem specs 
of the machine running it. I haven't tested it myself, but I think
a decent PC with a decent Gbit card should be able to capture a 
full Gbit/s load.

Anyone able to share some hardware specs and the performance that
can be seen with that hardware?

> 2: What are the reasons for wireshark to classify a packet as malformed?
> Occasionally there are packets in the dump that wireshark marks as
> "Malformed packets", however I now took a closer look at one of these
> packets and the LL, IP and TCP header look ok, the only things different
> from another packet not marked as malformed are sequence/ACK number and the
> checksum. Does wireshark interpret the contents of the TCP packet and mark
> them as malformed if there are special characters in it? I did my tests with
> files generated by dd'ing out of /dev/random, can this be the cause for this
> message? The receiver TCP/IP stacks ACKs the packets as it should so there
> seems to no big problem with this.

Each protocol has it's own routines for declaring a packet as malformed. 
But in short a malformed packet is a packet that does not follow the
specs for that protocol. One example, a SSL packet has a length field 
that tells you how many bytes the next record will have. If the value
of the length field is larger than the actual amount of bytes reported to
be on the wire, it will be marked as a malformed packet.

Using random data to create payload will certainly create some packets
that will be recognized as some protocol by the first bytes, but will then
have a really high chance of not following the specs of the protocol
generating malformed packets.

Hope this helps, Cheers,