Wireshark-dev: Re: [Wireshark-dev] Use of tcp_dissect_pdus() with a protocol which has a variab
From: Peter Wu <peter@xxxxxxxxxxxxx>
Date: Fri, 20 Feb 2015 19:55:33 +0100
Hi, While looking at improving the Websocket dissector, I found the need to support variable length fields in tcp_dissect_pdus. Here is Bills original mail (which had no replies). On Fri, May 09, 2014 at 11:02:45AM -0400, Bill Meier wrote: > To: TCP re-assembly experts: > > > The MQTT protocol dissected by packet-mqtt.c runs over TCP. The field which > specifies the MQTT PDU length can be 1 to 4 bytes; the length of a complete > MQTT PDU can be less than 4 bytes. > > So: trying use tcp_dissect_pdus() won't work since the "fixed length" > needed to handle the maximum size of the "PDU length" field is larger than > the possible minimum PDU size. > > One approach is to assume that the complete length field will, with high > probability, always be in 1 TCP segment and thus available even if > specifying a 'fixed length' which includes only a 1 byte PDU length field. > (This is certainly not guaranteed). > > Or, obviously, the dissector could do reassembly as described in > README.dissector section 2.7.2 "Modifying the pinfo struct". > > However, digging a little deeper, I note that tcp_dissect_pdus() is doing > something related to "want_pdu_tracking" (which I've never delved into and > which is not mentioned in README.dissector). > > So it occurred to me that using a modified tcp_dissect_pdus() which allows > the get_pdu_len function to return DESEGMENT_ONE_MORE_SEGMENT might be a > workable approach. > > So: I added the following to tcp_dissect_pdus() and modified > the packet-mqtt.c get_pdu_len() function appropriately. > > (added code in tcp_dissect_pdus): > > plen = (*get_pdu_len)(pinfo, tvb, offset); > + > + /* Is "more data" being requested before the PDU length can be > determined ? > + * If so, request same. > + */ > + if (plen == DESEGMENT_ONE_MORE_SEGMENT) { > + if (!proto_desegment || !pinfo->can_desegment) { > + REPORT_DISSECTOR_BUG("DESEGMENT_ONE_MORE_SEGMENT not > allowed"); > + } > + pinfo->desegment_offset = offset; > + pinfo->desegment_len = DESEGMENT_ONE_MORE_SEGMENT; > + return; > + } > + > if (plen < fixed_len) { > > > My questions: > > 1. Is this a reasonable approach (it works AOK in my tests) ? This approach looks fine to me. I have taken the same approach (but replacing REPORT_DISSECTOR_BUG by DISSECTOR_ASSERT in https://code.wireshark.org/review/7279 > 2. If not, and packet-mqtt should do reassembly itself, does the reassembly > code also need to do the "want_pdu_tracking" stuff ? > > Bill Looking at the current implementation of tcp_dissect_pdus, it is not necessary to change want_pdu_tracking as the size of the new PDU is not yet known. Since this is an interesting API update, I thought that informing the list would be a good idea. Kind regards, Peter
- Prev by Date: Re: [Wireshark-dev] A suggestion to improve navigating in large captures
- Next by Date: [Wireshark-dev] Lua dissector & Protocol Hierarchy
- Previous by thread: Re: [Wireshark-dev] A suggestion to improve navigating in large captures
- Next by thread: [Wireshark-dev] Lua dissector & Protocol Hierarchy
- Index(es):