From owner-freebsd-questions Tue Jan 13 19:05:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA27499 for questions-outgoing; Tue, 13 Jan 1998 19:05:37 -0800 (PST) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from awfulhak.org (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA12690 for ; Tue, 13 Jan 1998 17:20:01 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.org (8.8.7/8.8.7) with ESMTP id AAA10954; Wed, 14 Jan 1998 00:23:02 GMT (envelope-from brian@Awfulhak.org) Message-Id: <199801140023.AAA10954@awfulhak.org> X-Mailer: exmh version 2.0.1 12/23/97 To: Eivind Eklund cc: Brian Somers , William Wong , freebsd-questions@FreeBSD.ORG, Eivind Eklund , Charles Mott Subject: Re: PPP 1/11/98 In-reply-to: Your message of "Wed, 14 Jan 1998 00:54:01 +0100." <19980114005401.04084@follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jan 1998 00:23:01 +0000 From: Brian Somers 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? Yep. That'd be good - thanks. I've looked more closely at the code, and I can't see any real problems (I jumped a bit when I saw the err() call). > Eivind. Cheers. -- Brian , , Don't _EVER_ lose your sense of humour....