ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Why am I getting a BoundsError?

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 26 Oct 2006 03:39:41 -0700
Andrew Schweitzer wrote:
Maybe I don't understand tcp_dissect_pdus.

If a user message overruns an ethernet frame, tcp_dissect_pdus is supposed to allocate enough space to hold the entire user message, and only call the user's dissector when the entire message has been received... right?

If by "the user's dissector" you mean the dissector routine passed as an argument to tcp_dissect_pdus(), yes.

The dissector that *calls* tcp_dissect_pdus() has to be called for each TCP segment, obviously.

So if we get a frame with user packet lengths
	1056	--> parsed here, since frame has 1448 TCP bytes (right?)

Only if you have 26 bytes worth of IPv4 and/or TCP options, or are running on something other than Ethernet, or the Ethernet packet is shorter than 1514 bytes. Ethernet header = 14 bytes, IPv4 header with no options = 20 bytes, TCP header with no options = 20 bytes, and 1514-(14+20+20) = 1460. (An IPv6 header is 40 bytes, and 1514-(40+20+14) = 1440, so even with no IPv6 extension headers or TCP options, you don't have enough room for 1448 TCP bytes.)

	112	--> "", total now 1168
	1868	--> Parsed later. total size would be 3036

I.e., you have a single frame - presumably a single TCP segment with 14 bytes of Ethernet header (I'm assuming from the 1514 in your other message that this is over Ethernet), 20 bytes of IPv4 header (with no options), 20 bytes of TCP header (with no options), and with:

	1) a 1056-byte user packet, which fits entirely in the TCP segment;

	2) a 112-byte user packet, which fits entirely in the TCP segment;

3) the beginning part of an 1868-byte user packet, with the full packet being continued in later segments?

when wireshark gets third packet, it should allocate a buffer big enough to handle it (right?), then wait for enough data to arrive before doing so, right?

In fact, 2 more frames would be requires since in first frame only 280 of 1868 bytes are parsed, leaving 1608 bytes, requiring two more frames?

Yes.

This presumes that the "proto_desegment" argument to tcp_dissect_pdus() is TRUE. If it's FALSE, no desegmentation is done.