Date: Thu, 18 Feb 1999 01:12:17 +0000 From: Brian Somers <brian@Awfulhak.org> To: tom@tomqnx.com (Tom Torrance at home) Cc: brian@Awfulhak.org (Brian Somers), hackers@freebsd.org Subject: Re: PPP Problem Message-ID: <199902180112.BAA03944@keep.lan.Awfulhak.org> In-Reply-To: Your message of "Wed, 17 Feb 1999 13:40:12 EST." <m10DBtM-000I33C@TomQNX.tomqnx.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 <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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902180112.BAA03944>