["Greg Morris" <GMORRIS@xxxxxxxxxx>]

My 2 cents,

 

I have been working on dissectors for almost 2 years now. I have been asked by several Ethereal developers if there were docs that could easily be parsed to generate the dissector. And in most cases I have found that the things that I am working on required hours and hours of parsing through source code, design specs, etc.. to just get something that would work.

 

Maybe I am the exception and not the rule but currently Ethereal supports well over 400 protocols. I know that there are many more that could be added. But there are numerous contributions being made during each release. This includes enhancements to the existing code base as well as completely new code. There are many more things that Ethereal could do to make itself more user freindly then having the ability to "create your own dissector". I would expect we would be flooded with generic dissectors. These could cause other issues as well when adding certain dissectors cause crashes or a failure to build on certain OS's. Also more then likely they would be very lacking in their capabilities.

 

Sounds like a can of worms to me. I would rather see everyone focus on the current wish list and knock those all out. Then we could worry about a secondary utility or language to build simple dissectors.

 

Greg

>>> John McDermott <jjm@xxxxxxxxxx> 8/20/2003 3:42:09 PM >>>

So what is the goal?  A tool to create a good dissector for any protocol
or a tool to create a reasonable (a bit better than "quick and dirty")
dissector for lots of possible protocols.  I think the latter.  IMHO, the
primary use of the tool would be more to implement dissectors for local
or seldom-used protocols than to use it to try to build a new, say, H.323
dissector.

--john

Ed Warnicke wrote:
>
> On Wed, 20 Aug 2003, Andreas Sikkema wrote:
>
>
>>Ed Warnicke wrote:
>>
>>
>>>Most of these shouldn't be that hard to handle as generalized
>>>cases... but everytime I find myself saying that I think of
>>>DNS and DNS compression... there will always be oddballs...
>>
>>But those are not the kind f protocols the general ethereal user will
>>want to (quickly) add for themselves. And if they do I presume they
>>have the knowledge to add something to E
>
>
> That was roughly the point I was trying to make ( unfortunately
> not very clearly :).  Solving the general case is hard.  Solving
> a handleful of special cases that solve 90% of the problems is
> not so hard.
>
> Ed
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
>


--
John McDermott
Writer, Educator, Consultant
jjm@xxxxxxxxxx        http://www.jkintl.com
V +1 505/377-6293 F +1 505/377-6313

_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev