Wireshark · Wireshark-dev: Re: [Wireshark-dev] tcp_dissect_pdus() & fixed_len issue

[Tobias Weiss <tweiss@xxxxxxxxxxxxxxx>]

Well, the packages are send in a strict
order: after the TCP connection is established, the server sends both "connection
frames" (2x 4 byte).

After that it's a usual request / response
protocol and all messages have either header [2] or [3]. And which one
is used is set in the configuration of the server and client.

So the client will always expect the
two "connection frames" in the beginning from the server. Afterwards
both applications know which header to use.

Tobi

Bill Meier <wmeier@xxxxxxxxxxx>
Sent by: wireshark-dev-bounces@xxxxxxxxxxxxx

04/26/2012 09:09 AM

Please respond to
Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>

To	Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
cc
Subject	Re: [Wireshark-dev] tcp_dissect_pdus() & fixed_len issue

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: ??





___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe