From owner-freebsd-questions Tue Jan 13 16:57:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA04927 for questions-outgoing; Tue, 13 Jan 1998 16:42:48 -0800 (PST) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA03161 for ; Tue, 13 Jan 1998 16:34:18 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id XAA27918; Tue, 13 Jan 1998 23:54:02 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id AAA01207; Wed, 14 Jan 1998 00:54:01 +0100 (MET) Message-ID: <19980114005401.04084@follo.net> Date: Wed, 14 Jan 1998 00:54:01 +0100 From: Eivind Eklund To: Brian Somers Cc: William Wong , freebsd-questions@freebsd.org, Eivind Eklund , Charles Mott Subject: Re: PPP 1/11/98 References: <199801130511.VAA09570@wiley.csusb.edu> <199801132331.XAA10405@awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <199801132331.XAA10405@awfulhak.org>; from Brian Somers on Tue, Jan 13, 1998 at 11:31:58PM +0000 Sender: owner-freebsd-questions@freebsd.org Precedence: bulk On Tue, Jan 13, 1998 at 11:31:58PM +0000, Brian Somers wrote: > > > > > > > I just upgraded to the latest version of ppp, and it doesn't like to > > > > stay running. I'm using 2.2.5-RELEASE, and after I launch it in daemon > > > > mode, it just quits with no error. I could be using pppctl to talk to > > > > the uipc socket, and it will just die on me. I figure it's quitting > > > > with a SIGKILL because the socket is left, and no core dump or kernel > > > > message is given. It is, for all intents and purposes, unuseable. > > > > > > I've noticed this too, but I can't reproduce it reliably :-( There's > > > no record of any sort of signal being sent to it :-/ > > > > > > I'm looking into it. > > > > > > > Joe Clarke > > > > > > > > > > -- > > > Brian , , > > > > > > Don't _EVER_ lose your sense of humour.... > > > > > > > > > > > > > > > > This was happening to me as well... until I upgraded to the 1/08/98 > > version of ppp and changed my IP address to one of the 192.168.x.x > > numbers. I don't know if this was all I did but the ppp stuff > > is working now. This was using ppp interactively through term. > > Yes. The problem here, as far as I can tell *must* be the recent > upgrade of libalias to version 1.5 (cmott & eivind cc'd). > > dev:/usr/src/lib/libalias $ fgrep -w err *.c > alias_db.c: int err; > alias_db.c: err = bind(sock, > alias_db.c: if (err == 0) > alias_db.c:#include > alias_db.c: err(1, "alias punch inbound(1) setsockopt(IP_FW_ADD)"); > alias_db.c: err(1, "alias punch inbound(2) setsockopt(IP_FW_ADD)"); That code is not called unless you enable the firewall code through setting a special mode bit, _and_ your system is configured without a firewall. I'll look at denying the mode change for this case. (I'm sorry - I didn't think of that when I originally wrote the code as it was planned to run in a very special-cased environment, where a setsockopt() error was something that could never happen. The above erros can still theoretically happen even with the mode denial - through kernel errors of some kind.) But I don't think this can be the case here - as far as I know, you (Brian) never added the possibility of using this mode of libalias. Or am I wrong here? > I'll leave it up to Eivind & Charles to sort this out. > FWIW, IMO library routines should never use such high level routines. It only does because the routines that this came from have no way of communicating failure. I can (if necessary) upgrade the interface so all routines can report failure, but that will mean I'll have to kill backwards compatibility. There are two other events I can see in the relatively near future (<3 months) that will kill backwards compatibility, so I'd rather not. > Ppp doesn't use descriptor 2 for stderr, so the above messages are > probably going to find there way to some very uninteresting place. Urgh. Do you think that denying the mode change if the firewall is not present is enough for the time being? Eivind.