Date: Wed, 14 Jan 1998 00:23:01 +0000 From: Brian Somers <brian@Awfulhak.org> To: Eivind Eklund <eivind@yes.no> Cc: Brian Somers <brian@Awfulhak.org>, William Wong <wwong@wiley.csusb.edu>, freebsd-questions@FreeBSD.ORG, Eivind Eklund <perhaps@yes.no>, Charles Mott <cmott@srv.net> Subject: Re: PPP 1/11/98 Message-ID: <199801140023.AAA10954@awfulhak.org> In-Reply-To: Your message of "Wed, 14 Jan 1998 00:54:01 %2B0100." <19980114005401.04084@follo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 <brian@Awfulhak.org>, <brian@FreeBSD.org>, <brian@OpenBSD.org> > > > > <http://www.Awfulhak.org>; > > > > 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 <err.h> > > 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 <brian@Awfulhak.org>, <brian@FreeBSD.org>, <brian@OpenBSD.org> <http://www.Awfulhak.org>; Don't _EVER_ lose your sense of humour....
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801140023.AAA10954>