Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Jan 96 20:22:54 +1000
From:      Andrew MacIntyre <andymac@bullseye.apana.org.au>
To:        joerg_wunsch@uriah.heep.sax.de
Cc:        bugs@freebsd.org
Subject:   Re: 2.1.0 PPP hassles...
Message-ID:  <30e9077f.bullseye@bullseye.apana.org.au>
In-Reply-To: <199512310852.JAA16764@uriah.heep.sax.de> from "J Wunsch" at Dec 31 95 9:52 am

next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for your reply.

> > 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:

{...}

This is a puzzler.  If I don't have that "null" send string, it succeeds
in hanging up the modem - as near as I can figure by sending \n before 
the text following the CONNECT is completely received.

> > 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.)

CPU is an AMD - not quite sure of vintage.

I went back to scratch with the network configuration, and have got 
past #3, and even got the dial to work - only abt 3-5 mins later PPP 
crashed with a signal 4 (illegal inst) while I was ftping a file :-(
This time, the tunnel driver was left open, so a reboot was required to 
try again...

> 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.

I think you're right to suspect hardware.  I vaguely recall a few 
years ago there being known problems with UMC chipsets and Unix systems 
(in particular Linux).  I have a replacement SIS471 chipset motherboard 
(my SNAP-950726 system is running very nicely on a slightly different 
SIS471 mb) for this system which I've held off installing for lack of 
RAM (current mb is 30pin, new mb is 72pin).

Crazy thing is, I spent hours online with ppp installing 2.1 without 
any sign of this, although as neither the NE2000 nic or Sony CDU31A 
CD-ROM were found by the boot floppy kernel, maybe something is a 
little uncomfortable now that they're active.

I did try booting the GENERIC kernel but had the same problems as with 
my custom kernel.

I'll be getting the 2.1 CD-ROM in the very near future, so may attempt 
a re-install.

-- 
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andrew.macintyre@aba.gov.au    (work) | Snail: PO Box 370
        andymac@bullseye.apana.org.au  (play) |        Belconnen  ACT  2616
Fido:   Andrew MacIntyre, 3:620/243.18        |        Australia



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?30e9077f.bullseye>