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]
