From owner-freebsd-bugs Sun Dec 31 01:27:22 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA14670 for bugs-outgoing; Sun, 31 Dec 1995 01:27:22 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA14638 for ; Sun, 31 Dec 1995 01:27:11 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA07862; Sun, 31 Dec 1995 10:27:09 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA12625; Sun, 31 Dec 1995 10:27:08 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id JAA16764; Sun, 31 Dec 1995 09:52:54 +0100 (MET) From: J Wunsch Message-Id: <199512310852.JAA16764@uriah.heep.sax.de> Subject: Re: 2.1.0 PPP hassles... To: andymac@bullseye.apana.org.au (Andrew MacIntyre) Date: Sun, 31 Dec 1995 09:52:52 +0100 (MET) Cc: bugs@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <30e53d3f.bullseye@bullseye.apana.org.au> from "Andrew MacIntyre" at Dec 30, 95 11:23:09 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-bugs@freebsd.org Precedence: bulk As Andrew MacIntyre wrote: > > 1. The dial chat script behaviour appears to have changed, seemingly > requiring a terminating send string, whereas all the samples and the > working config from the above mentioned SNAP-950726 system don't > have/need it. I've used the string "\\c" to fill this for now. Hmm, i'm not claiming that this hasn't changed, but i) i haven't noticed any change myself, and ii) the only diff between 2.0.5 and 2.1's chat.c is: - LogPrintf(LOG_CHAT, "sending: %s\n", buff+2); + if (strstr(str, "\\P")) { /* Do not log the password itself. */ + LogPrintf(LOG_CHAT, "sending: %s\n", str); + } else { + LogPrintf(LOG_CHAT, "sending: %s\n", buff+2); + } > 2. Using the dial command, after the connect has been made, but before the > login has been executed, PPP core dumps with an "illegal instruction" error. > Upon restarting PPP, with the modem link still up, I can use "term" and > manually log in. That is very strange. The only know occasions for ``illegal instruction'' traps by now are broken CPUs. No normal code should ever be able to cause illegal instructions, since the compiler and assembler do not generate them. > 3. Using a manual login, after PPP reports "Packet mode.", it then > reports "SIOCAIFADDR: File exists" netstat -r shows that the link is > in place, but as far as the rest of the systems is concerned, the link is > down. This means that some of the routes PPP was going to install did still exist, perhaps from a previous crashed invocation of PPP. (The ``File exists'' must be translated into ``Route exists'' as far as the routing code is concerned.) Something is very weird with your machine, but since very many people are using iijppp, and nobody has ever reported anything resembling your description, i would first suspect hardware. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)