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 ?
>
> 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 ?
>
> 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.
Sure I was thinking about using neigh cache info and default route if
higher proto is specified w/o L2 dst info.
>
> Anything I've missed, Tobias? :)
>
> Thanks again,
> Daniel
OK the main points which are clear to me are:
1) Make avialable conf script to be accessed from command line
2) Extend conf script syntax to use protocol info extension.
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.
