Wireshark mailing list archives
Re: tcp_dissect_pdus() & fixed_len issue
From: Tobias Weiss <tweiss () ra rockwell com>
Date: Thu, 26 Apr 2012 10:40:50 -0400
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
Current thread:
- tcp_dissect_pdus() & fixed_len issue Tobias Weiss (Apr 26)
- Re: tcp_dissect_pdus() & fixed_len issue Bill Meier (Apr 26)
- Re: tcp_dissect_pdus() & fixed_len issue Tobias Weiss (Apr 26)
- Re: tcp_dissect_pdus() & fixed_len issue Stephen Fisher (Apr 26)
- Re: tcp_dissect_pdus() & fixed_len issue Tobias Weiss (Apr 26)
- Re: tcp_dissect_pdus() & fixed_len issue Bill Meier (Apr 26)