Re: PPP

[Roland McGrath]

> I set the speed of the serial line to 19200 by this:
> stty speed 19200 < /dev/com0

Why do you have to?  Doesn't ppp set this speed itself?

> I set up pfinet (after killing it with kill -9):
> settrans /servers/socket/2 /hurd/pfinet -i tun0

Does settrans -gf not work?  

> (you can add -i tun0 to your existing configuration to have ethernet and
> ppp).

Does it also work to add it with fsysopts to test before changing the
translator setting?  If that works you can do that to update the current
state and then use settrans -pk to change it for the next boot, without
ever killing pfinet.

> I can do some of the things Neal described in one of the posts here.
> For example, I can ftp to the other machine, and download a small file
> (smaller than 500 bytes).  But larger files are not retrieved.  On the Hurd
> side, "show hdlc" shows bad frame check sequence fields errors.
> On the GNU/Linux side ifconfig shows receive errors, too.

That sure sounds like serial port problems to me.  
Have you tried really low speeds?

> The main candidates for the problems are um-pppd (in particular the tty
> backend of it) and the term translator.  Neal and me tested ppp over ethernet
> (_not_ what you know as PPPoE), and it worked just fine.

You mean PPP over TCP or UDP, right?  (That might or might not actually be
over Ethernet.)  If you want to test the term code path, then try ptys.
You can e.g. run netcat on the master side of the pty to a remote pppd over
TCP, and run ppp on the slave side.  Or equivalently, telnet -E into the
hurd box and run ppp from that pty.  If you can make that work, then you
will isolate the pppd tty code and /hurd/term from the kernel serial driver
and the serial hardware.  The flip side of that is that you ought to do
some more exhaustive tests on just the serial tty, e.g. use kermit or sz/rz
or something to exercise /hurd/term and the serial ports without involving
pfinet.