On 2016-01-29 at 09:05:24 +0100, Vadim Kochan <[email protected]> wrote:
> On Fri, Jan 29, 2016 at 08:48:59AM +0100, Tobias Klauser wrote:
> > On 2016-01-28 at 23:06:23 +0100, Vadim Kochan <[email protected]> wrote:
> > > Reworded commit message of 12-14 patches from series:
> > >
> > > "[PATCH v3 00/16] trafgen: Add proto header generation"
> > >
> > > 1) Added parameters & default values description.
> > > 2) Functionality was not changed.
> >
> > Perfect, thanks a lot! Series now applied. I also took the manpage patch
> > from your previous series and I'll directly fold in my few minor changes.
>
> BTW,
>
> 1) I think that few more protocol header functions might be added (VLAN
> & TCP) before release (btw when do you plan do make release ?).
IPv6 would also be nice. But I think they're now fairly easy to add with
the existing infrastructure.
As for the release. I'd like to give the current changes a few weeks to
get some testing by others. As I'll be offline for some days beginning
of and mid February, I'd like to target a release sometime around end of
February, which means the tree will close for new features ~2 weeks
before the release.
> 2) I just realized that currently protocol functions are used at packet
> compile time and checksum's will be not re-calculated if dynamic
> functions (dinc,drand) changed some of the header or payload bytes.
> So as future improvement it needs to add some runtime logic for
> protocol fuctions. It will be needed also if to extend protocol
> functions with dynamic values too, like:
>
> { ip(sa=192.168.1.0/24) }
> { udp(sp=2000...3000) }
>
> really I don't know yet how to implement such syntax but this is just
> for future thinking.
Yes, supporting recalculation of checksums would certainly be nice and
shouldn't be that hard to implement. Would be nice to get this in before
release...
As for the "dynamic values" you propose above. What is the expected
behavior of this? Would you generate multiple packets (255 and 1000 in
the above examples)? Do you see a use case for this or shouldn't this
better be done by preprocessing the trafgen config file with a hand
crafted script?
> 3) Also as I mentioned in '... Xenomai ...' thread, what about idea to
> extend trfagen for altering ingress packets via protocol functions ?
> So currently I see it that in ingress mode protocol functions will
> change only parameters which were specified, the default will be
> ignored. Again I am not sure how useful it might be.
How is this related to Xenomai?
Well, trafgen currently doesn't support ingress packets. Or did you mean
netsniff-ng? In any case, I think this will be quite hard to get right
without having to implement a lot of protocol parsing logic (which of
course could be partially reused from the dissectors). Also you could
only do it on a per-packet level instead of i.e. per flow. I'd like to
see a clear benefit over kernel-level forwarding/packet-mangling
facilites for this feature before attempting to add it.
--
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.
