I created a lua script to dissect DoIP messages. The header is pretty simple: A version byte, a byte with the bitwise invert of the version, the payload type as two bytes and the payload length as 4 bytes.
function get_doip_length(tvb, pinfo, offset)
-- Callback function to decide how long a PDU is, so that
-- Wireshark can reassemble it for us
local version = tvb(offset, 1):uint()
local inverse_version = tvb(offset+1, 1):uint()
if version == 0x02 and inverse_version == 0xFD then
local payload_length = tvb(offset+4, 4):uint()
return payload_length + 8 -- Payload length + header size
else
return 8 -- Unknown protocol, assume only header is to be reassembled
-- According to https://www.wireshark.org/lists/wireshark-dev/201610/msg00057.html
end
end
function doip.dissector(tvb, pinfo, tree)
dissect_tcp_pdus(tvb, tree, 8, get_doip_length, dissect_doip_pdu)
end
This works well when the trace is complete. I have payloads of about 16K, which is 12 TCP frames. The 11 first TCP frames are marked [TCP segment of a reassembled PDU]
and the last one contains the proper protocol name and all the data.
However, I sometimes trace also on a small device using tcpdump -s128
, because the throughtput is too low (over UART…) and it’s better for me to not have the full payload but not drop packets.
In this case, the dissector doesn’t work as expected. The first frame of the PDU is marked as the reassembly, and the length is indeed 16K. But all the 11 remaining frames are not taken into account. Rather, dissect_tcp_pdus
tries to match them to a new PDU. I would expect that dissect_tcp_pdus
could at least reassemble all the segments, even if the data is not captured (Tvb has indeed a :len()
and a :reported_len()
functions).
Is there someting I do wrong?
asked 16 May ‘17, 15:53
Cilyan
11●1●1●3
accept rate: 0%
OK, thanks. That's a bit sad, isn't it? :)
Yes. There are limits on how much reassembly etc. can be done in that case. With TCP, you have packets for protocols running atop TCP beginning at arbitrary points in the packet, with either length fields or some other delimiting mechanism. If, for example, you slice off the last part of a TCP segment that contains the beginning of a packet, and that's continued in the next TCP segment, it'd be impossible for the dissector to recognize the stuff in the next TCP segment as being a continuation of that packet, and to know when the next packet after that begins, unless it can search heuristically for the beginning of a packet.
There's some more stuff Wireshark could do, but the general problem of handling packets on a TCP stream if packet slicing is done is insoluble.