Hi!
I noticed some weird behavior when I was analyzing a 300 MB dump of a
single TCP connection. Wireshark was very unresponsive, I couldn't
build the IO graph, and CPU usage was 100% permanent. First, I thought
that it was some kind of heuristic that eats up the CPU or some bad
dissector tries to parse one of the packets which contains its magic
signature, so I turned off everything except TCP, IPv4 and SLL. But
the problem remains.
I've debugged the Wireshark process and found out that most of the
time it scans the list:
wmem_list_find_custom(tcpd->fwd->ooo_segments, fd, compare_ooo_segment_item)
which is called in the desegment_tcp() function.
Indeed this dump has a number of lost packets. AFAIU after the TCP
dissector meets a lost packet it puts the following packets into some
kind of desegmentation queue in the hope of retransmission which never
happens as it was a capture miss. As more packets are getting
dissected the retransmission queue grows and every next packet makes
the queue longer and the search within it longer.
After I turned the out-of-order reassembling off, everything just works fine.
My question is: wouldn't it be reasonable to have some configurable
threshold of gap between the lost sequence number and maximum sequence
number currently seen by the dissector, so that after this threshold
is passed the dissector gives up to reassemble the stream and feeds
the upper level dissector next packets after the lost one?
--
With best regards
Maksim Dmitrichenko