On Fri, Jun 19, 2015 at 12:08:57AM +0200, Daniel Borkmann wrote: > On 06/18/2015 03:24 PM, Vadim Kochan wrote: > >On Thu, Jun 18, 2015 at 11:07:12AM +0200, Daniel Borkmann wrote: > >>On 06/18/2015 10:57 AM, Vadim Kochan wrote: > >>... > >>>Not yet, but I will try keep thinking about this, and will let know if I > >>>will have some real ideas regarding implementation. > >> > >>Sounds good! > > > >Some 1st though which I came up is may be to start extend current > >trafgen generation api set: > > > >{ > > eth > > { > > src(), > > dst(), > > proto(), > > } > > , > > ip > > { > > ver(), > > src(), > > dst(), > > opt(0x1, 20), > > opt(0x2, 30), > > }, > > tcp > > { > > dport(), > > sport(), > > flags(), > > }, > >} > > Can you elaborate on your idea, what would this config do? I.e. if src() > etc is empty. > > Thanks, > Daniel
Hi, 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. Regards, -- 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.