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@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
