From owner-freebsd-hackers Wed Feb 17 10:42:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from TomQNX.tomqnx.com (cpu2745.adsl.bellglobal.com [207.236.55.214]) by hub.freebsd.org (Postfix) with ESMTP id B91B311324 for ; Wed, 17 Feb 1999 10:42:47 -0800 (PST) (envelope-from tom@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m10DBtM-000I33C; Wed, 17 Feb 1999 13:40:12 -0500 (EST) Message-Id: From: tom@tomqnx.com (Tom Torrance at home) Subject: Re: PPP Problem In-Reply-To: <199902170743.HAA37802@keep.lan.Awfulhak.org> from Brian Somers at "Feb 17, 1999 7:43:38 am" To: brian@Awfulhak.org (Brian Somers) Date: Wed, 17 Feb 1999 13:40:12 -0500 (EST) Cc: tom@tomqnx.com, hackers@freebsd.org, brian@awfulhak.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM919276812-541-0_ Content-Transfer-Encoding: 7bit Content-Length: 4660 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --ELM919276812-541-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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. 2) "ppp -direct loop-in" ignores a "kill -TERM xxx". This does not seem correct. How can ppp.linkdown ever be processed? 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. 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). 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? 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:-) Regards, Tom > You must have a ``delete 0'' (same as ``delete 0.0.0.0'' or ``delete > default'') somewhere. > > > Running 2.2-stable with user-ppp. > > > > I set up a test PPP link, tunneling PPP over TCP. > > I do not run routed or gated. The PPP server (-direct) is located > > on my LAN gateway machine, which has my ISPs router > > defined as its gateway. There are no definitions in > > ppp.conf, ppp.linkup or ppp.linkdown that refer in any > > way to the 0.0.0.0/0 default definition. > > > > The client machine does have 0.0.0.0 as the 4th parameter to > > its set ifaddr command, which may contribute to the symptoms > > in some way. I'll try removing that next... > > > > Shortly after or when the link is made, the ppp program removes > > the default definition from the server's routing tables. So far > > I tried removing all references to HISADDR, MYADDR and disabling > > sroutes - nothing helped. > > > > Regards, > > Tom > > -- > Brian > > Don't _EVER_ lose your sense of humour ! > > > --ELM919276812-541-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=ppp.conf Content-Description: ppp.conf Content-Transfer-Encoding: base64 ZGVmYXVsdDoNCglzZXQgdGltZW91dCAwDQoJc2V0IGxxcnBlcmlvZCAxMA0KCXNldCBsb2cgUGhh c2UgQ2hhdCBDb25uZWN0IExDUCBJUENQIENvbW1hbmQNCglkaXNhYmxlIHNyb3V0ZXMNCgllbmFi bGUgbHFyDQoJYWNjZXB0IGxxcg0KDQpsb29wOg0KCXNldCBkZXZpY2UgbWFpbHg6cHBwbG9vcA0K CXNldCBkaWFsDQoJc2V0IGxvZ2luDQoJc2V0IGF1dGhuYW1lIHh4eHgNCglzZXQgYXV0aGtleSB5 eXl5eQ0KCXNldCBpZmFkZHIgMTAuMC4xLjEvMjQgMTAuMC4xLjIvMjQgMjU1LjI1NS4yNTUuMCAw LjAuMC4wDQoNCmxvb3AtaW46DQoJZW5hYmxlIGNoYXANCglhbGxvdyBtb2RlIGRpcmVjdA0KCXNl dCBpZmFkZHIgMTAuMC4xLjIgMTAuMC4xLjEgMjU1LjI1NS4yNTUuMCANCglzZXQgc2VydmVyIC92 YXIvdG1wL3BhdGJzZCAiIiAwMTc3DQoNCmRpYWwtaW46DQoJZW5hYmxlIGNoYXANCglhbGxvdyBt b2RlIGRpcmVjdA0KCXNldCBpZmFkZHIgMTAuMC4yLjIgMTAuMC4yLjEgMjU1LjI1NS4yNTUuMA0K CXNldCBzZXJ2ZXIgL3Zhci90bXAvZGlhbHBwcCAiIiAwMTc3DQoNCnNsb29wOg0KCWxvYWQgbG9v cA0KCXNldCBkZXZpY2UgIS9ldGMvcHBwL3NlY3VyZQ0KDQoNCg0K --ELM919276812-541-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=ppp.linkup Content-Description: ppp.linkup Content-Transfer-Encoding: 7bit 10.0.1.1: add 10.0.1.0/24 10.0.1.2 # add 205.150.43.0/24 10.0.1.2 10.0.1.2: add 10.0.1.0/24 10.0.1.1 add 159.249.0.0/16 10.0.1.1 10.0.2.1: add 10.0.2.0/24 10.0.2.2 add 205.150.43.0/24 10.0.2.2 10.0.2.2: add 10.0.2.0/24 10.0.2.1 --ELM919276812-541-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=ppp.linkdown Content-Description: ppp.linkdown Content-Transfer-Encoding: 7bit 10.0.2.1: # delete 205.150.43.0/24 10.0.1.2: delete 10.0.1.0/24 delete 159.249.0.0/16 10.0.2.1: delete 10.0.2.0/24 # delete 205.150.43.0/24 10.0.2.2: delete 10.0.2.0/24 --ELM919276812-541-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message