Re: [9fans] ppp going

Re: [9fans] ppp going

[Russ Cox]

This explains your echoing problem too.
The echo was coming from the kernel thinking
the PPP modem was giving it commands to execute
on the console; the kernel was echoing them back.

If you were sitting on the console running con,
then that would turn off echo (con runs the
current /dev/cons in raw mode).

Russ

Re: [9fans] ppp going

[Ronald G Minnich]

Russ Cox wrote:
> This explains your echoing problem too.

I'm not totally convinced. Kernel is not trying to use serial as a
console, only 9load.

Also, if kernel were to echo, then if I told modem to echo, why wouldn't
I get double-echo? In fact, once modem started echoing, I should get a
nice infinite loop of echos as the kernel put a prompt to the modem, the
modem echo'ed the prompt, and so on. This is the normal problem that
crops up in this type of case. I'm not seeing that.

Another problem is that 9load is using serial as a console even though
menuconsole is not set to anything; I'll have to see why this is
happening. Oh, never mind, andrey is fixing it :)

ron

Re: [9fans] ppp going

[Russ Cox]

> I'm not totally convinced. Kernel is not trying to use serial as a
> console, only 9load.

Both 9load and the kernel use the line "console=0" in plan9.ini
to decide to run a serial console.  If 9load is doing it, so will
the kernel.

Perhaps there is a bug in 9load and it plays serial console
more often than it should, but we haven't touched that code
in years and you'd think someone would have noticed by now
(famous last words).

In any event I'll be interested to see what the eventual fix is.

Russ

Re: [9fans] ppp going

[Ronald G Minnich]

ok, fix was not to use a hacked 9load we had set up when jmk was here :-)

all is now well.

But I think I will, if I get a chance, modify pbs to just load a kernel
from blocks 16-<n> and just skip 9load. This is what linuxbios will do
anyway.

thanks

ron

Re: [9fans] ppp going

[Ronald G Minnich]

Ronald G Minnich wrote:

> The hardware is a lippert frontrunner with phoenix bios (not for long!
> Everytime I use a fuctory BIOS I remember why I hate them so much) and
> it is really glitchy. I think linuxbios will fix this, but right now I
> can't reliably boot the node -- it comes up and the keyboard controller
> or something is glitching so badly that 9load thinks I'm typing lots of
> garbage -- I can't type garbage that fast even when I CAN reach the
> keyboard!

oops, can't blame fuctory BIOS for this one. 9load was trying to use
serial console and keyboard --- and modem was sending back lots of
garbage in response to 9load's prompts.

Gotta tell 9load not to user serial console :-)

ron

[9fans] ppp going

[Ronald G Minnich]

well, there were a host of weird problems, it now works.

one thing I totally don't understand is what happens with 'con' when I
am cpu'ed into the node. I can't get reasonable behavior using /dev/eia0.

I do this after getting in. This is drawterm to the node, as rminnich,
and then cpu -h dsn2 -u bootes.

bind -a '#t' /dev
con -b 115200 -Rs /dev/eia0

If I send the ate0 command, to disable command echoing, all commands are
always echo'd. This should not happen. If I sit at the console, and do
the exact same sequence, this problem does not occur.

What's weird: characters are not echoed twice. They are just never 'not
echoed'. You would think if there is an extra echo going on, then
ate1
would get you two of everything, and
ate0
would get you one. Not so. You always get one -- you can't turn echo off.

This, it turns out, was one of the things that was screwing up ppp.
Everything ppp sent was echoed. ppp indicated there was a loop. Made
sense, the packet dump always showed that what was sent, was received.

The hardware is a lippert frontrunner with phoenix bios (not for long!
Everytime I use a fuctory BIOS I remember why I hate them so much) and
it is really glitchy. I think linuxbios will fix this, but right now I
can't reliably boot the node -- it comes up and the keyboard controller
or something is glitching so badly that 9load thinks I'm typing lots of
garbage -- I can't type garbage that fast even when I CAN reach the
keyboard!

The second problem was related to this. I could not use 'ppp -u' mode on
the cpu'ed in window, for some reason. So I was doing this:
con -Rs /dev/eia0
ATDT10.0.0.1
^\
q
ppp ....

Well, I was not thinking: when I exited 'con', DTR dropped, the modem
reset, and, well, ppp ended up talkng to a modem in 'AT' mode again.

So, I went to the console, and did this:
  ip/ppp -ddddd -f -p /dev/eia0  -x /net.alt -b 115200 -u -c -C

and all then worked. Almost. I did a
bind /net.alt /net
and pinged over the modem, and it sorta seems to work, but I can't
unplug the enet cable ... I think bits like dns etc. are still using the
old /net (obviously) so unplugging the cable gives them trouble; but I
don't see why I can't unplug the enet and do ip/ping 68.35.123.144.

next step is to make this modem (airlink.com raven) the ONLY ip
interface ... but that's tomorrow.

To whoever wrote ppp, nice work! It's very nice to have a user-mode
program for PPP, and the debug mode really makes figuring things out
pretty straightforward and fast.

ron