From owner-freebsd-hackers Wed Feb 17 17:13: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from awfulhak.org (awfulhak.force9.co.uk [195.166.136.63]) by hub.freebsd.org (Postfix) with ESMTP id 05D6011053 for ; Wed, 17 Feb 1999 17:12:36 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (keep.lan.Awfulhak.org [172.16.0.8]) by awfulhak.org (8.8.8/8.8.8) with ESMTP id BAA11516; Thu, 18 Feb 1999 01:12:31 GMT (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (localhost [127.0.0.1]) by keep.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id BAA03944; Thu, 18 Feb 1999 01:12:17 GMT (envelope-from brian@keep.lan.Awfulhak.org) Message-Id: <199902180112.BAA03944@keep.lan.Awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: tom@tomqnx.com (Tom Torrance at home) Cc: brian@Awfulhak.org (Brian Somers), hackers@freebsd.org Subject: Re: PPP Problem In-reply-to: Your message of "Wed, 17 Feb 1999 13:40:12 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Feb 1999 01:12:17 +0000 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I have not been able to duplicate the behaviour- perhaps that is true. > > BUT there are several things I find do not work properly when using > ppp over TCP. Perhaps you could set me straight, but... > > 1) I would expect that with enable lqr and accept lqr, if the > other side disappears (no response to 5 polls) I would expect the > tunX connection to be torn down, and ppp.linkdown processed, and the > ppp job to terminate. NONE of this seems to happen. Hmm, have you enabled lcp & lqm logging ? Are they confirming that you're sending a sixth un-replied-to ECHO ? > 2) "ppp -direct loop-in" ignores a "kill -TERM xxx". This does > not seem correct. How can ppp.linkdown ever be processed? Is ppp logging the fact that it sees the signal ? Once ppp receives a TERM, it starts sending terminate requests to the peer. > 3) Granted that you can compensate in the routing table, the > netmask configuration for the tunnel device seems incorrect. It is > always set to the default for the IP. I would expect that if a > netmask is supplied in the "set ifaddr" command, that would be used > in setting up the tunnel configuration. This is a bug I recently introduced. It's in my TODO list and should be fixed fairly soon. > 4) After a connection is set up, the named running on the > client starts to cough: > named: bind(dfd=24, [10.0.1.1].53): Permission denied > named: deleting interface [10.0.1.1].53 > This seems to be a harmless peculiarity of the new bind (The old > one on the server doesn't do it) that I could eliminate by defining > the IPs in my zone (or live with it). This is because you've got named in a ``sandbox'' - running as user `bind' probably. It hasn't got permission to bind port 53 to newly configured interfaces. > 5) Pinging the host side of the tunnel takes 5 times as long > as when I ping an ethernet interface. Setting up a route for that IP > to 127.0.0.1 fixes this. Would it not be a good idea for ppp to > set this up automatically? Not really. If people want a loopback, they should configure one (POLA). Besides, it's quite common for people to use the same local interface address on their tun interface as their LAN - making routing a lot easier. Creating a loopback here would disturb quite a few people. > Would you be kind enough to set me straight where required on the above? > The docs are full of helpful hints/examples, but a tad short on > specification as to how it "should" work:-) If you can supply more detail about 1 & 2, I can look into any problems. > Regards, > Tom Cheers. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message