On Fri, Jun 19, 2015 at 11:16:54PM +0200, Daniel Borkmann wrote:
> On 06/19/2015 10:46 AM, Vadim Kochan wrote:
> ...
> >OK here is another (may be better) design.
> >
> >Here is an example of the cfg script:
> >
> >{
> > eth
> > {
> > dst: eth_addr(AA:BB:CC:DD:EE:FF)
> > proto: ipv4,
> > }
> > ip
> > {
> > src: ip_addr(192.168.1.1)
> > dst: ip_addr(192.168.1.2)
> > }
> > tcp
> > {
> > flags: syn | ack
> > }
> >}
> >
> >Needs some refactoring of trafgen code & existing cfg funcs which allows to
> >use & manipulate of
> >current packet offset variable.
> >
> >Each proto should be registered via struct proto_gen:
> >
> >struct proto_field {
> > int id;
> > uint32_t offset;
> > uint32_t len;
> >};
> >
> >struct proto_value {
> > void *value;
> > uint32_t len;
> >};
> >
> >struct proto_gen {
> > struct cfg_ctx *ctx;
> >
> > /* get field name info - id, len, offset */
> > struct proto_field *field_parse(struct proto_gen *prot, char *name);
> >
> > /* indicates that this field was filled */
> > void field_set(struct proto_gen *proto, struct proto_field *field);
> >
> > /* get info about some proto defined const value */
> > struct proto_value *value_get(struct proto_gen *proto, struct
> > proto_field *field, char *name);
> >
> > /* fill the rest unfilled fields */
> > void fill(struct proto_gen *prot, uint8_t *hdr);
> >
> > /* finish after whole packet was built */
> > void finish(struct proto_gen *prot, uint8_t *data, int len);
> >}
> >
> >Each proto hdr field can be filled by specifying field name separated by ':'
> >and
> >macro/func which will fill the bytes.The field may be filled with any
> >existing trafgen macro (const(), rnd() - the field len should be
> >considered). Also some additional macro/funcs should be added - ipv4_addr,
> >eth_addr, etc.
> >
> >The parser will lookup & keep struct proto_gen proto_ptr when the proto
> >section
> >was entered (when '#proto {' was parsed), and parser can call the
> >proto_ptr->field_parse to obtain the field information by name (id,
> >offset, len) then change the current packet offset & call the macro/func
> >which will fill the field. Then parser should call proto_ptr->field_set
> >to let know to the proto_gen which field was filled. At the end parser
> >will call proto_ptr->fill to fill the rest unfilled fields with some
> >default values & fill the csum fields if needed.
> >
> >While filling the default fields values the proto_gen should know some
> >trafgen's context info - interface id, and may be some other info which may
> >help to construct such unfilled fields like dst/src Ethernet addresses or
> >src/dst IP addresses.
> >
> >Also it is possible that each proto_gen may have some own defined values like
> >flag names which can be evaluated via proto_gen->value_get where field
> >pointer
> >may be specified. It might be useful if these values will be a part of
> >expressions
> >like: syn | ack.
> >
> >At the end the parser will walk over each proto from higher layer to do a
> >last call
> >proto_gen->finish where each proto may do some calculations and fill some
> >unfilled fields.
> >Meanwhile I am not sure if it will be needed.
> >
> >Well this is very conceptually and I will try to prepare better version which
> >would consider the existing trafgen code & cfg syntax parser.
>
> Ok, how would all of this tie together with flex and bison that we
> use for trafgen as parser generator? It looks on a first glance that
> this design would be outside of that scope?
You mean that this is out of scope of this thread which was related to
mz ? If so, then yes ... may be extend the trafgen's cfg script to
describe the protocols and then add the cmd line interface based on this
extension ? Or do you think that extending cfg script syntax is not good
or may be problematic ?
Well, I think may be I can do some "just for fun" implementation, just
for demonstration ...
Regards,
>
> Cheers,
> Daniel
--
You received this message because you are subscribed to the Google Groups
"netsniff-ng" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
