On Fri, Jan 29, 2016 at 10:17:51AM +0100, Tobias Klauser wrote:
> On 2016-01-29 at 09:05:24 +0100, Vadim Kochan <vadi...@gmail.com> 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 <vadi...@gmail.com> 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?
I suppose that "dynamic values" will behave similar like current dynamic
functions (dinc/ddec/drnd) - generate some new value on each packet sending
iteration.
>
> > 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?
I just posted this idea in email thread with subject '...Xenomai ...'.
Anyway, never mind.
>
> 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.
No I meant trafgen, I just imagined that how it would be useful to alter
ingress packets via trafgens script. But w/o parsing (I assume), so for
example lets take a look on following example:
{
ipv4(sa=1.1.1.1, dp=2.2.2.2)
}
Then we can easy apply to the each ingress packet ONLY specified fields
via the same protocol functions w/o some significant changes (I assume)
and send it out via specified output device, I see it like advanced
reply feature (like tcpreply). The ingress packets might be received from
device or
pcap file.
----- proposals continue -------
4) Also I think it would be good to think in direction of using dissectors
in trafgen (via -VV) to dump human readable packet, and also allow to do
not specify output device.
5) May be it make sense in the future to get rid of libnet from mz and
use protocol functions for it ...
Regards,
Vadim Kochan
--
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.
