On Tue, Jun 30, 2015 at 09:38:23PM +0200, Tobias Klauser wrote: > On 2015-06-30 at 11:41:04 +0200, Daniel Borkmann <borkm...@iogearbox.net> > wrote: > > On 06/29/2015 02:58 AM, Vadim Kochan wrote: > > >Hi, > > > > > >This is the 1-st "try" version of how I see the protocol generation API > > >for the > > >trafgen util as mz replacement (at least for better performance). > > > > > >I am sending this just because to get your feedback about conceptual idea, > > >and as soon as I got some basic working version I decided to share the > > >code just to get know if I am moving in the right direction. > > > > > >Added high-level command line protocol packet building intreface, > > >which allows to specify protocol parameters to build the header and > > >payload. > > > > > >Each protocol is represented by proto_gen struct which is responsible > > >only for providing field info (size, data) by name to trafgen's > > >low level packet generation layer. > > > > > >All packet generation routine is performed by the generic code in > > >trafgen.c which parses the command line, obtains proto name, param=value > > >list and calls the specific protocol handler to get protocol field info > > >by name, so the TX routine remains the same. > > > > > >The command line syntax looks like: > > > > > > trafgen/trafgen --dev lo eth da = AA:BB:CC:DD:EE:FF > > > sa=11:22:33:44:55:66, arp op=rep tip=192.168.1.1 -n 1 > > > > > >so the first is proto name and after there are param value pairs which > > >are separated by space, in case if there are multiple protocols > > >specified - their should be separated by "," after last param value of > > >the previous protocol. > > > > > >I think the picture will be more clear after adding IP protocol with > > >checksum > > >handling. > > > > First of all, thanks for working on this, Vadim! I like seeing something > > like > > this integrated after we've resolved all outstanding issues. I'll certainly > > make trafgen also easier to use. > > I can only second that. Very nice to see work in this direction, much > appreciated! Thanks Vadim. > > > Before digging into the very details, I have a couple of high-level > > comments/ > > thoughts. All the manual string parsing you are doing, isn't it easier to > > just > > extend the flex/bison files with the related protocol information? > > > > I.e. I was thinking of 1) make the current configuration syntax also > > available > > for the direct command line interface, and after that 2) extend the > > flex/bison > > parser with L2, L3, etc information in a similar syntax as you did above > > (e.g. > > multiple packets could also here be defined with separator { ... }, if no > > separator > > is provided, we assume a single packet). This would give the flexibility of > > having > > a mz-like cmdline syntax and at the same time one could also use it in the > > config file. Do you see any major obstacles with that? > > > > Regarding the default values, f.e. if we've specified only L3 information > > (e.g. > > IPv4), but no L2 information, we should look up src/dst mac based on the > > output > > interface resp. the neighbor cache. We should be careful with broadcasts, > > i.e. > > if no other information is available for determining a dst, only then we > > should > > use broadcast (f.e. if only L2 was specified w/o a dst mac, etc); in all > > other > > cases we should try hard to resolve all needed information from the kernel. > > > > Anything I've missed, Tobias? :) > > I've only had time for a rough review so far. Essentially my review > comments also boil down to the remarks Daniel made above :) > > - Extending the current configuration syntax/grammar to allow for > additional protocol information. > - No manual string parsing (as in patch 08/10), but use the parser > generated from the extended flex/bison grammar. > - I generally dislike the idea of giving default values to non-specified > protocol fields (e.g. using broadcast as default eth dst field). This > holds potential for a lot of unexpected behavior. IMO we should - as > Daniel suggested - try to get the information base on output interface > etc. or even more extreme treat this as an error (at least for > mandatory fields). > > Detailled comments will follow as replies to the individual patches or > to your replies. > > Again, thanks a lot for taking the time to work on this. > > Tobias
I will look how to use existing (and probably extend it) grammar for protocol building from command line & from script conf. I will send some syntax examples how it would look for different protocols. IMHO command line API should be simple enough. 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.