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 _______________________________________________ Wireshark-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
