Guy Harris wrote:
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.
As far as I can tell this is the case. My protocol is registered on the
TCP port, and all its registered routined does is is call
tcp_dissect_pdus, with appropriate function pointers passed in.
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
Ok, I can see that now. No IP options, and 20 bytes of IP header. 12
bytes of TCP options and 32 bytes of TCP header
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.
It's TRUE.
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
