> 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. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd