On 2015-06-30 at 12:00:55 +0200, Vadim Kochan <[email protected]> wrote:
> On Tue, Jun 30, 2015 at 11:41:04AM +0200, Daniel Borkmann 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.
> >
> > 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?
> So you mean to make command line & script parsing through the same
> flex/bison ?
Preferably, yes (from my point fo view, cannot speak for Daniel though
;) This will make it much more user friendly. Having to remember two
different ways to generate the same packet could be very cumbersome.
> > 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
> Also I was thinking in the future to use the following template for proto
> specifying in the script:
> {
> eth
> {
> }
> ip
> {
> }
> }
> > 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?
> I will think about unify command line & script syntaxes in the same
> flex/bison ...
>
> But again should we really support the same mz syntax ?
I wouldn't consider this necessary for the first implementation
prototype. We could still add an mz compatible grammar at a later point.
Feel free to propose your own solution or stick to mz syntax as you see
fit.
--
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.
