Re: tcp_dissect_pdus() & fixed_len issue

[Tobias Weiss <tweiss () ra rockwell com>]

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 () newsguy com> 
Sent by: wireshark-dev-bounces () wireshark org
04/26/2012 09:09 AM
Please respond to
Developer support list for Wireshark <wireshark-dev () wireshark org>


To
Developer support list for Wireshark <wireshark-dev () wireshark org>
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 () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             
mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

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