> 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 <br...@awfulhak.org> <br...@freebsd.org> <br...@openbsd.org>
<http://www.Awfulhak.org>
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
