Yes, one comment. I think this is the right approach, I would suggest
taking it one step farther though. If you build the parser into
ethereal, then no recompiles would be needed for adding a new
protocol. This is how Etherpeek on Windows works.
> Hi,
>
> I wanted to discuss my progress as far as generating code for decode
> modules is concerned, and seek some input and discussion.
>
> At present, I have a Perl program that can parse a description file of the
> following sort:
>
> SMB open_andx {
> andx; # An andx SMB
> request {
> UCHAR Word Count (WCT) = 15;
> UCHAR AndXCommand;
> UCHAR AndXReserved;
> USHORT AndXOffset;
> BITFIELD 16 Flags = {
> 0x01 = { "Return Additional Info" , "Dont Return Additional Info" };
> 0x02 = { "Exclusive OpLock Requested" , "Exclusive OpLock not
> Requested" };
> 0x04 = { "Batch OpLock Requested" , "Batch OpLock not Requested" };
> };
> USHORT Desired Access;
> USHORT Search Attributes;
> USHORT File Attributes;
> USHORT Creation Time | fcall dissect_smb_time; # Call dissect_smb_time
> USHORT Creation Date | fcall dissect_smb_date; # Call dissect_smb_date
> USHORT Open Function;
> ULONG Allocated Size;
> ULONG Reserved1;
> ULONG Reserved2;
> USHORT Byte Count;
> UCHAR Buffer Format;
> STRING File Name;
> }
> response {
> UCHAR Word Count (WCT) = 15;
> UCHAR AndXCommand;
> UCHAR AndXReserved;
> USHORT AndXOffset;
> USHORT FID;
> USHORT Attributed;
> USHORT Last Write Time | fcall dissect_dos_time;
> USHORT Last Write Date | fcall dissect_dos_date;
> ULONG Data Size;
> USHORT Granted Access;
> USHORT File Type;
> USHORT Device State;
> USHORT Action;
> ULONG Server FID;
> USHORT Reserved;
> USHORT Byte Count;
> }
> }
>
> I can handle structured protocols and can associate calls to helper
> routines in Ethereal with fields, as well as fields that depend on other
> fields in simple ways (ie, length of F2 is F1).
>
> Now, my parser is very fragile, and the language is ugly, and I do not
> handle all possible constructs, so I am thinking of rewriting the whole
> thing, and I thought, why not try to handle more protocols?
>
> It seems like there are three different protocol types:
>
> 1. Highly structured, like SMB, which are easy to do using the above approach
>
> 2. Less structured, like FTP, which, none-the-less could be done with the
> above approach,
>
> 3. Unstructured, like Telnet, which appear hard, but might be describable.
>
> My goal would be a protocol decode builder package, that can build all the
> dissect routines and can plug things into the correct place to add a new
> protocol.
>
> Are there any comments?
>
>
> Regards
> -------
> Richard Sharpe, sharpe@xxxxxxxxxx, NS Computer Software and Services P/L,
> Samba (Team member www.samba.org), Ethereal (Team member www.zing.org)
> Co-author, SAMS Teach Yourself Samba in 24 Hours
>
