Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Feb 1999 13:31:19 +0000
From:      Brian Somers <brian@Awfulhak.org>
To:        tom@tomqnx.com (Tom Torrance at home)
Cc:        brian@Awfulhak.org (Brian Somers), hackers@FreeBSD.ORG, current@FreeBSD.ORG
Subject:   Re: Missing files/directories 
Message-ID:  <199902251331.NAA39106@keep.lan.Awfulhak.org>
In-Reply-To: Your message of "Wed, 24 Feb 1999 23:37:55 EST." <m10FsYd-000I5dC@TomQNX.tomqnx.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> Hi Brian,
> 
> It was a good thought, but we can't put the blame on bad hardware.
> 
> These tests were done on the RELENG_3 system cvsup'd 
> as of Feb 22 @ 20:00 EST. All tests were run internal to the
> same machine. So that I don't remain the only guy in the world
> to see these test results, Control files are included so you 
> can test locally:-)

Your best test engine would be either -current or using the latest 
ppp from my web site.  The RELENG_3 version doesn't have a lot of 
recent changes.

> "ppp0 -direct" on localhost is started by port 6671.
> 
> I know (now) that setting up the test this way the ppp's were
> communicating via localhost rather than the tunnel, but this way
> was much cleaner as far as verifying exactly how close the results
> were to what I saw running the server under 2.2-stable. There were
> differences, but the main issues are demonstrated.

Hmm, not 100% - see below.

> You will recall our discussion about the server hanging around
> under 2.2-stable after the client is terminated? Required by the
> RFCs you said? Under RELENG_3 the server meekly goes away, which
> makes sense to me.
> 
> Two tests were done. The first involved "kill -KILL clientpid".
> The second was "kill -TERM clientpid".
> In the first test, the server illegally removed the default route.
> In the second test, the server did the same - neither ppp actioned
> the second command in the linkdown scripts.

If a kill -KILL results in your default route disappearing, then that 
conclusively proves that ppp is not to blame :-/  If find this a bit 
strange though - this certainly doesn't happen on my machines - I 
frequently instruct my machine to connect to the 'net and then tunnel 
into an internal machine with something like ``ssh realmachine ssh 
internalmachine ppp -direct in''.  In my setup, internalmachine is 
using realmachine as it's default gateway, and that default has never 
disappeared unexpectedly.

WRT the second command, it looks like you've hit a problem that's 
next on my list to fix - since the radius changes, the interface 
netmasks are a bit faulty, and it's likely that there were some 
not-quite-so-bad problems in RELENG_3 too.  Your commands should 
work ok if you change them to ``add 10.0.1.1/32 127.0.0.1'' and 
``add 10.0.1.2/32 127.0.0.1''.

> I was surprised that the first test ended immediately - I thought
> the LQR packets would cause the server to terminate after 1 minute.

When you specify the device as a tcp link or a program to execute, 
ppp can tell immediately when the peer goes away - the results are 
exactly the same as loosing carrier.  This is why testing via the tcp 
link doesn't always cover all angles (I've suffered from these 
problems myself).

The only problem is when we're using a device that's a character 
special that doesn't support CD (carrier)

> Files:
> test1.netstat0	shows routing after boot
> test1.netstat1	shows routing after "ppp -background testloop"
> test1.psaxl	show ps results for the executing processes.
> test1.netstat2	shows routing after killing the client.
> test1.tun0	ifconfig while active.
> test1.tun1	ifconfig while active.
> test2.netstat	routing tables after terminating the client.
> Logs are supplied for both tests.
> 
> I hope that this is very helpful to you. I really appreciate
> your efforts!!

And I yours - thanks.

> Cheers,
> Tom

-- 
Brian <brian@Awfulhak.org> <brian@FreeBSD.org> <brian@OpenBSD.org>
      <http://www.Awfulhak.org>;
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902251331.NAA39106>