Thanks for your reply.
On 9/27/07, Sake Blok <sake@xxxxxxxxxx> wrote:
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.
The nw card in my PC is an Intel 82566 gigabit ethernet card, the CPU is Intel Core2 running at 2Ghz and I have 2GByte RAM. The hard disk is attached with SATA.
So it's not the worst computer. And the data rates were not as high as common in standard gigabit ethernet, we had data rates of about 50-150Mbit, sometimes better sometimes worse. But I would like to make sure that these "ACKed Lost Segment"'s really are a hw bug and not a case of wireshark missing some traffic.
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.
Hehe, it was really nasty, the first two bytes of the TCP payload were the start and the stop byte of the UCP protocol and wireshark reported "Malformed packet (UCP)". So this should be no hw problem.
Hope this helps, Cheers,
It really did, thanks, Cheers,
Matthias
Sake
_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users
