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? 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 netsniff-ng+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
