[PATCH nfsim] tcpsession: implement the RESET command

[PATCH nfsim] tcpsession: implement the RESET command

[Max Kellermann]

[-- Attachment #1: Type: text/plain, Size: 119 bytes --]

Hi,

I implemented a RESET command for the tcpsession command.  It can be
used to quickly purge TCP connections.

Max


[-- Attachment #2: nfsim-tcpsession_reset.patch --]
[-- Type: text/plain, Size: 1206 bytes --]

Thu Sep 15 00:06:48 CEST 2005  max@duempel.org
  * implemented tcpsession RESET
diff -rN -u old-nfsim-0/tools/tcpsession.c new-nfsim-0/tools/tcpsession.c
--- old-nfsim-0/tools/tcpsession.c	2005-09-22 10:25:35.000000000 +0200
+++ new-nfsim-0/tools/tcpsession.c	2005-09-22 10:11:23.000000000 +0200
@@ -248,6 +248,15 @@
 	return true;
 }
 
+static bool reset_session(struct tcp_endpoint *in, struct tcp_endpoint *out)
+{
+	if (!tcp_send(in, out, 0, "RST", NULL, 0, NULL))
+		return false;
+	talloc_free(curr);
+	curr = NULL;
+	return true;
+}
+
 static bool tcpsession(int argc, char *argv[])
 {
 	if (argc < 2) {
@@ -314,6 +323,20 @@
 		if (streq(argv[2], "reply"))
 			return close_session(&curr->reply, &curr->original);
 	}
+	if (streq(argv[1], "RESET")) {
+		if (!curr) {
+			nfsim_log(LOG_ALWAYS, "Session not open!");
+			return false;
+		}
+		if (argc != 3) {
+			tcpsession_help(argc, argv);
+			return false;
+		}
+		if (streq(argv[2], "original"))
+			return reset_session(&curr->original, &curr->reply);
+		if (streq(argv[2], "reply"))
+			return reset_session(&curr->reply, &curr->original);
+	}
 	if (streq(argv[1], "ABANDON")) {
 		if (!curr) {
 			nfsim_log(LOG_ALWAYS, "Session not open!");

Re: [PATCH nfsim] tcpsession: implement the RESET command

[Rusty Russell]

On Thu, 2005-09-22 at 10:24 +0200, Max Kellermann wrote:
> Hi,
> 
> I implemented a RESET command for the tcpsession command.  It can be
> used to quickly purge TCP connections.

Hi Max!

	I applied this and your other tcpsession patch, working on 2.6.14
support now based on your initial patch now.

Thanks!
Rusty.
PS.  Please cc me directly on nfsim patches, so I don't miss them....
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman

Re: [PATCH nfsim] tcpsession: implement the RESET command

[Rusty Russell]

On Sat, 2005-10-08 at 11:06 +0200, Max Kellermann wrote:
> Hi Rusty,
> 
> I have already reworked the 2.6.14 patch, because the old one was not
> fully working.  I havn't sent them to the list yet, but I have
> published them on my nfsim page:
> 
>  http://max.kellermann.name/projects/netfilter/nfsim.html
> 
> I'm not at home currently, next week I'll rewrite the patchset to
> apply on the current nfsim trunk (unless you have dealt with them
> already in their current form).

OK, I've merged them all, with a fair bit of rewriting to do with the
backtick code (yeah, I gave in).  The main change (other than cleaning
up the allocations using talloc and using popen) is that extensions must
be in $NFSIM_EXTPATH.  This defaults to tools/extensions/ if we're in
the build dir, or /usr/lib/nfsim/ otherwise.  Does this make sense to
you?

I haven't tested it, though 8(.

At Harald's suggestion, I'm trying for an actual nfsim release, but I
want to make two big changes before then:

(1) Use VPATH rather than actually copying the files from the source
dir, and use the Makefile in the netfilter/ dir in >=2.6.14.
(2) netlink support.

Feedback welcome!
Rusty.
PS.  If you want to send your utils and h323 tests for inclusion, please
do!
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman

Re: [PATCH nfsim] tcpsession: implement the RESET command

[Max Kellermann]

On 2005/10/10 12:37, Rusty Russell <rusty@rustcorp.com.au> wrote:
> OK, I've merged them all, with a fair bit of rewriting to do with the
> backtick code (yeah, I gave in).  The main change (other than cleaning
> up the allocations using talloc and using popen) is that extensions must
> be in $NFSIM_EXTPATH.  This defaults to tools/extensions/ if we're in
> the build dir, or /usr/lib/nfsim/ otherwise.  Does this make sense to
> you?

That assumes that nfsim provides the extensions, or that extensions
have to be installed in one of those paths.  IMHO, the extensions may
be shipped along with a test.  e.g. my h323 tests ship their own
tools.  To make testing easy, it should be possible to use extensions
without installing them (i.e. without root access?).

It also assumes that you _only_ use programs in /usr/lib/nfsim/ - what
if someone wants to call a program in /usr/bin/?  This lockout gives
us no advantage.

I'd prefer to just prepend ".:/usr/lib/nfsim:" to $PATH and let the shell
search, instead of manually prepending extension_path+"/" to the
command.

I'd also rename the default path to /usr/lib/nfsim/extensions, to make
room for more nfsim related files in the future.

> PS.  If you want to send your utils and h323 tests for inclusion,
> please do!

Sure.

Max

Re: [PATCH nfsim] tcpsession: implement the RESET command

[Rusty Russell]

On Mon, 2005-10-10 at 13:51 +0200, Max Kellermann wrote:
> On 2005/10/10 12:37, Rusty Russell <rusty@rustcorp.com.au> wrote:
> > OK, I've merged them all, with a fair bit of rewriting to do with the
> > backtick code (yeah, I gave in).  The main change (other than cleaning
> > up the allocations using talloc and using popen) is that extensions must
> > be in $NFSIM_EXTPATH.  This defaults to tools/extensions/ if we're in
> > the build dir, or /usr/lib/nfsim/ otherwise.  Does this make sense to
> > you?
> 
> That assumes that nfsim provides the extensions, or that extensions
> have to be installed in one of those paths.  IMHO, the extensions may
> be shipped along with a test.  e.g. my h323 tests ship their own
> tools.  To make testing easy, it should be possible to use extensions
> without installing them (i.e. without root access?).

I assumed you would want to merge your tests into nfsim-testsuite...

> It also assumes that you _only_ use programs in /usr/lib/nfsim/ - what
> if someone wants to call a program in /usr/bin/?  This lockout gives
> us no advantage.
> 
> I'd prefer to just prepend ".:/usr/lib/nfsim:" to $PATH and let the shell
> search, instead of manually prepending extension_path+"/" to the
> command.
> 
> I'd also rename the default path to /usr/lib/nfsim/extensions, to make
> room for more nfsim related files in the future.

OK, how about this:
(1) Use $NFSIM_EXTPATH if set, else
(1) Use ".:tools/extensions:$PATH" if we're in the nfsim dir, else
(2) Use ".:/usr/lib/nfsim/extensions:$PATH" if we're not.

I'll patch it now...
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman

Re: [PATCH nfsim] tcpsession: implement the RESET command

[Max Kellermann]

On 2005/10/10 15:03, Rusty Russell <rusty@rustcorp.com.au> wrote:
> > That assumes that nfsim provides the extensions, or that extensions
> > have to be installed in one of those paths.  IMHO, the extensions may
> > be shipped along with a test.  e.g. my h323 tests ship their own
> > tools.  To make testing easy, it should be possible to use extensions
> > without installing them (i.e. without root access?).
> 
> I assumed you would want to merge your tests into nfsim-testsuite...

I do want that.  But there is a reason nfsim-testsuite is separate
from nfsim itself, and the extensions (like my generate-h225-packet
tool) are co-developed with the tests using it, not with nfsim itself.

> OK, how about this:
> (1) Use $NFSIM_EXTPATH if set, else
> (1) Use ".:tools/extensions:$PATH" if we're in the nfsim dir, else
> (2) Use ".:/usr/lib/nfsim/extensions:$PATH" if we're not.

Why don't you add all of them to $PATH (if set and present)?  I
believe the following order would be best:

 1. "." (or better `dirname $testfile.sim`)
 2. $NFSIM_EXTPATH
 3. $srcdir/tools/extensions
 4. $pkglibdir

It is perfectly possible for a test suite to use extensions included
in nfsim _and_ extensions the test suite itself shipped.

This also makes the code simpler.

Max

Re: [PATCH nfsim] tcpsession: implement the RESET command

[Rusty Russell]

On Mon, 2005-10-10 at 15:14 +0200, Max Kellermann wrote:
> On 2005/10/10 15:03, Rusty Russell <rusty@rustcorp.com.au> wrote:
> > > That assumes that nfsim provides the extensions, or that extensions
> > > have to be installed in one of those paths.  IMHO, the extensions may
> > > be shipped along with a test.  e.g. my h323 tests ship their own
> > > tools.  To make testing easy, it should be possible to use extensions
> > > without installing them (i.e. without root access?).
> > 
> > I assumed you would want to merge your tests into nfsim-testsuite...
> 
> I do want that.  But there is a reason nfsim-testsuite is separate
> from nfsim itself, and the extensions (like my generate-h225-packet
> tool) are co-developed with the tests using it, not with nfsim itself.

Sure, but if they are generic enough they belong in nfsim, I think.
nfsim is more than the basis for the testsuite: it also allows people to
test their particular configurations.  So I would argue that your tools
belong in nfsim.

> > OK, how about this:
> > (1) Use $NFSIM_EXTPATH if set, else
> > (1) Use ".:tools/extensions:$PATH" if we're in the nfsim dir, else
> > (2) Use ".:/usr/lib/nfsim/extensions:$PATH" if we're not.
> 
> Why don't you add all of them to $PATH (if set and present)?  I
> believe the following order would be best:
> 
>  1. "." (or better `dirname $testfile.sim`)
>  2. $NFSIM_EXTPATH
>  3. $srcdir/tools/extensions
>  4. $pkglibdir
> 
> It is perfectly possible for a test suite to use extensions included
> in nfsim _and_ extensions the test suite itself shipped.

No.  NFSIM_EXTPATH should override: the user can create the above logic
if they want.  I certainly don't want to run random programs which
happen to be in the path.

Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman