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 <[email protected]> Sent by: [email protected] 04/26/2012 09:09 AM Please respond to Developer support list for Wireshark <[email protected]> To Developer support list for Wireshark <[email protected]> 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 <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
