On 4/26/2012 8:55 AM, Tobias Weiss wrote:
Hi everyone,
I'm currently developing a dissector for a quite old TCP protocol. Most
of the stuff is straight forward and not a real problem. But right now
I'm facing an issue and need some help.
In my main dissector function I'm calling tcp_dissect_pdus(), but there
are 3 cases or let's say headers which could be within the stream:
[1] a fixed 4 byte "connection frame" with 2 possible value and no payload
[2] a 7 byte header with a fixed flag at the end (1 byte) and a length
field for the rest of the message
[3] a 33 byte header with a fixed flag at the beginning (2 bytes) and a
length field for the rest of the message.
Unfortunately one of the two possible values of the connection frame [1]
is a valid beginning of the header [2]. So I'm wondering what I should
pass as fixed_len to tcp_dissect_pdus()?! If I set fixed_len to 4 byte
(length of connection frame [1]), I'm not able to figure out the length
of packages of type [2] or [3] and I'm not able to distinguish [1] and
[2]. If I pass the header width of either [2] or [3] and there is a
connection frame in the beginning, it will be discarded by
tcp_dissect_pdus() as it is smaller than the fixed_len parameter.
So how do I handle such a situation? Any suggestion? Is it possible to
call tcp_dissect_pdus() twice? And yes, I know that this is a weird
protocol design but changing it is not an option.
My (possibly naive) question:
How would an application be programmed to handle this ?
Is there additional context which allows an application to know which
header to expect ?
or: does an application make the assumption that the header will be
received in one frame ?
or: ??
