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.
