Hi all, IMHO there are 3 issues discussed here: 1. Make up the data stream (conversation, reassembly) 2. Break up packet data in protocol fields (dissection) 3. Give an interpretation of the dissected fields (interpretation)
We already have some means of handling problem 1. We can probably just describe the data stream type (datagram/stream/...) and the appropriate reassembly scheme can be used. If required in issue 3, custom conversation and reassembly schemes may have to be provided. Although problem 2 is fairly simple to tackle by means of a simple description language, problem 3 is much more complex and almost inevitably leads to situation-specific code generation. Additionally, issue 2 and/or 3 may provide information for issue 1 of the encapsulated protocol. If we're able to split the 3 issues, then we're much closer to a solution. This approach may also help us to provide dissector generation without interpretation in an automatic way. The interpretation however still needs a programmer's (team) work. So I think the real question is how will/can/should/would we separate and then link together again automatically-generated dissection with hand-coded interpretation? Regards, Olivier -----Original Message----- From: Richard Urwin In my (very) humble opinion, an automatic generation method that just handled breaking out fields would be a huge help. It certainly beats not having a dissector at all. Some people, who could write a protocol description, can not write C. [snip snip]
