lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101216172800.GA8404@spritelink.se>
Date:	Thu, 16 Dec 2010 18:28:00 +0100
From:	Kristian Larsson <kristian@...itelink.net>
To:	"David S. Miller" <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: pktgen IP address stepping

Hello David (and list)!

First of all, I'm hoping I'm sending this to the right person / list,
I've never submitted nor written a patch for the Linux kernel before,
so please bare with me.


This patch adds the ability to set the step rate at which the source
or destination IP address is increased when src_min / src_max or
dst_min / dst_max is used with pktgen.

Usage is simple, two new parameters:
  src_step X
  dst_step X
where X is a positive integer (or actually an unsigned long long).

This is useful for network testing when you want to send packets to
large parts of the Internet.

In addition to adding stepping support, I've changed the init value of
current source / destination address in the code to the max. The
current kernel sets it to the min value, but before the first packet
is sent out, the value is increased. By setting it to max, and we try
to increase it, it will wrap and thus actually start at the min value.
I find this more intuitive and to follow the principle of least
astonishement - I'd actually go as far as say the old behaviour is a
bug. Anyway, there are also some formatting changes and editorial
nitpicks.  Of course, src / dst step has been added to the output of
the proc interface.


My tests involved performance measurements of routers, specifically in
the area of convergence times. Most larger routers implement their FIB
in a TCAM, SRAM or something similarly fast and deterministic. While
reads, ie lookups are often very fast, updates are often quite slow.
My testing show some platforms rewriting some 2000 prefixes per
seconds. So basically, what I wanted to test was just how routers
rewrite their FIB and so I needed to send a packet to every prefix they
have stored in FIB and receive it on one of two output interfaces - the
first if the reroute has not yet happened and on the second interface
if it has. Since I'm dealing with Internet core routers that means I
have a full BGP table (ie some 330k prefix as of late 2010) and I thus
want to send one packet, or 330k packets per second, to each and every
prefix. In addition, it would require to me to input a list of
prefixes to pktgen somehow as the prefixes certainly aren't evenly
spread out (ie, not evenly sized). Instead of implementing that, I
went for an approximation, sending a packet to every Nth address,
which in my case is 65535, or every /16. This gives a pretty good
approximate of the entire routing table, at least good enough for my
tests.

Tests will be posted on http://labs.spritelink.net for those
interested. It will probably be until the beginning of next year
before anything is posted since most of the testing is performed at my
employer, Tele2, and we need to wrap it all up first.

The changes included in this patch was developed during my own (and
not my employers) time and I give permission to place it under whatever
license needed for inclusion in the Linux kernel. pktgen.c appeared to
include some list of changes at the top so I added myself, if this is
too small a change or whatever, that can of course be removed.

Looking forward to any feedback and / or suggestions.

Kind regards,
   Kristian.

-- 
Kristian Larsson                                        KLL-RIPE
+46 704 264511			              kll@...itelink.net

View attachment "linux-pktgen-step.patch" of type "text/x-diff" (4300 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ