ktcp should provide ability to use hardware flow control on SLIP connections

[pawosm-arm]

According to https://github.com/jbruchon/elks/blob/master/Documentation/text/networking.txt in order to establish SLIP connection between ELKS and Linux one needs to type:

slattach -p slip -L -s 9600 /dev/ttyS1 &

The -L option means Enable 3 wire operation. The terminal is moved into CLOCAL mode, carrier watching is disabled.. I assume this is due to ktcp's inability to specify (and utilize?) hardware flow control. Lack of hardware flow control makes serial connection unusable.

[ghaerr]

I assume this is due to ktcp's inability to specify (and utilize?) hardware flow control.

Yes. ktcp can't utilize hardware flow control because the kernel doesn't support it. At this point, neither hardware flow control nor UART FIFO buffering is implemented. Both could be added, but we need to figure out some basic problems in the serial driver first. I plan on implementing FIFO buffering immediately after understanding exactly what the problem is in the current serial driver.

My latest push on the open serial port PR #535 will display errors (finally) by the UART on the console, including framing error (received data overrun), and interrupt signaled without receive data ready (QEMU seems buggy in this respect). I think we're making progress, but I can't personally test on real hardware, so thank you for your testing.

Lack of hardware flow control makes serial connection unusable.

I thought some users had been using serial TCP/IP already? Can you test it, or is this just a request that ELKS needs it?

This issue should likely be renamed "Provide serial port hardware flow control [enhancement]", as ktcp should default to using hardware flow control unless -L is specified.

[Mellvik]

Hi @pawosm-arm, @ghaerr,

Lack of hardware flow control makes serial connection unusable.

This is not the case - for a number of reasons. HW flow control is useful and increases effective bandwidth for obvious reasons, but SLIP will work fine with a reasonable amount of character loss (and subsequent packet retransmissions). Thus the option to turn off that requirement from the command line. In fact, as is today, SLIP will probably work fine in ELKS @ 9600 bps, where the character loss is minimal. Also remember that modern day serial lines hardly ever have any flow control at all, just TTL level RX, TX, GND - possibly augmented by a 232MAX chip to yank up the voltages to RS232 levels. The assumption seems to be that the hardware is fast enough to keep up with the 115200 bps speeds and higher anyway. Our vintage hardware is a different story, as indicated by Kermit, x/y/z-modem and the like. So HW flow control will be a very welcome addition to ELKS.

…

--Mellvik

[pawosm-arm]

Yes. ktcp can't utilize hardware flow control because the kernel doesn't support it.

Does it mean, miniterm started with -r -d behaves no different than when started without those flags?

This issue should likely be renamed "Provide serial port hardware flow control [enhancement]", as ktcp should default to using hardware flow control unless -L is specified.

but... ktcp does not specify neither it checks for -L option:

    if (argc > 1 && !strcmp("-b", argv[1])) {
        daemon = 1;
        argc--;
        argv++;
    }
    if (argc < 3) {
        printf("Usage: %s [-b] local_ip [interface] [gateway] [netmask]\n", progname);
        exit(3);
    }

I thought some users had been using serial TCP/IP already? Can you test it, or is this just a request that ELKS needs it?

I can do slattach/ifconfig on Linux then start ktcp and telnetd on ELKS. Then telnet connection can be established from Linux (at least the telnet client reports so), yet not for long. After a while things on ELKS side do crash in two possible ways:

1. telnetd crashes complaining about sbrk (I guess it's memory allocation issue)
2. the system just hangs (with no messages on console) and needs manual power down.

Similarly, pinging ELKS from Linux can occasionally cause ELKS's crash.

Also, I think ELKS should have ping command so I could ping the other way round.

[ghaerr]

Hi @pawosm-arm, thanks for your inspection of miniterm and testing of TCP/IP!

Does it mean, miniterm started with -r -d behaves no different than when started without those flags?

I just checked and all those options are parsed and passed to the not-implemented (yet) TIOMCSET ioctl for the serial driver. These are the same ioctl's that I just commented out in my last commit due to their returning an error and causing miniterm to exit.

but... ktcp does not specify neither it checks for -L option:

It seems that ktcp doesn't try to specify either hardware or software flow control to the kernel. I haven't looked to see whether the it's slip driver tries to implement its own software flow control (using ^S/^Q).

I can do slattach/ifconfig on Linux then start ktcp and telnetd on ELKS. Then telnet connection can be established from Linux (at least the telnet client reports so), yet not for long. After a while things on ELKS side do crash in two possible ways:

Thanks for this testing. I haven't yet tried connecting to another system with TCP/IP.

1. telnetd crashes complaining about sbrk (I guess it's memory allocation issue)

Very likely. I'll add a -mout-chmem= to its build for you.

2. the system just hangs (with no messages on console) and needs manual power down.
   Similarly, pinging ELKS from Linux can occasionally cause ELKS's crash.

Bad news. I thought SLIP TCP/IP was working on ELKS for some people. I'm not sure what the SLIP packet size is, I haven't dove into any of the TCP/IP code at this point.

Perhaps there are others that have successfully run SLIP TCP/IP on ELKS? Comments?

Also, I think ELKS should have ping command so I could ping the other way round.

Noted.

[Mellvik]

@ghaerr, @pawosm-arm - the compete hang situation may be serial related. When testing heavily on serial over the past couple of days, I have experienced complete system hang at a couple of occasions. Not in the middle of a transfer, but suddenly all dead. So I suggest we await a stable and dependable serial.c before debugging slip further. —Mellvik

…

12. apr. 2020 kl. 18:00 skrev Gregory Haerr ***@***.***>: Hi @pawosm-arm <https://github.com/pawosm-arm>, thanks for your inspection of miniterm and testing of TCP/IP! Does it mean, miniterm started with -r -d behaves no different than when started without those flags? I just checked and all those options are parsed and passed to the not-implemented (yet) TIOMCSET ioctl for the serial driver. These are the same ioctl's that I just commented out in my last commit due to their returning an error and causing miniterm to exit. but... ktcp does not specify neither it checks for -L option: It seems that ktcp doesn't try to specify either hardware or software flow control to the kernel. I haven't looked to see whether the it's slip driver tries to implement its own software flow control (using ^S/^Q). I can do slattach/ifconfig on Linux then start ktcp and telnetd on ELKS. Then telnet connection can be established from Linux (at least the telnet client reports so), yet not for long. After a while things on ELKS side do crash in two possible ways: Thanks for this testing. I haven't yet tried connecting to another system with TCP/IP. telnetd crashes complaining about sbrk (I guess it's memory allocation issue) Very likely. I'll add a -mout-chmem= to its build for you. the system just hangs (with no messages on console) and needs manual power down. Similarly, pinging ELKS from Linux can occasionally cause ELKS's crash. Bad news. I thought SLIP TCP/IP was working on ELKS for some people. I'm not sure what the SLIP packet size is, I haven't dove into any of the TCP/IP code at this point. Perhaps there are others that have successfully run SLIP TCP/IP on ELKS? Comments? Also, I think ELKS should have ping command so I could ping the other way round. Noted. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#539 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA3WGOG7DSWQ2ADRFBP4WP3RMHQSDANCNFSM4MGEVAQA>.

[ghaerr]

the compete hang situation may be serial related. When testing heavily on serial over the past couple of days, I have experienced complete system hang at a couple of occasions. Not in the middle of a transfer, but suddenly all dead.

Please give more detail! What exactly was the hang, and was there any serial I/O going on?
We definitely need more details on this. Also, perhaps you could attach a mouse to your serial port and run mouse and report whether your results are the same as @pawosm-arm's.

[Mellvik]

Sorry, I just had to mention this. There aren't much detail yet. I've had elks running for days and weeks on physical, idle - just a few occasional commands. Elks is stable. Then today, after a lot of banging on serial, I cameback and the system was frozen. No messages, just hard hung (requiring power off). More beating to come. Mouse? None in sight - unfortunately. - Mellvik

…

12. apr. 2020 kl. 20:49 skrev Gregory Haerr ***@***.***>:  the compete hang situation may be serial related. When testing heavily on serial over the past couple of days, I have experienced complete system hang at a couple of occasions. Not in the middle of a transfer, but suddenly all dead. Please give more detail! What exactly was the hang, and was there any serial I/O going on? We definitely need more details on this. Also, perhaps you could attach a mouse to your serial port and run mouse and report whether your results are the same as @pawosm-arm's. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[Mellvik]

Correction, @ghaerr: I may actually have a serial mouse coming in with a vintage machine whenever the postal package service (from australia) starts working again. Another opportunity for real hw testing.

…

--M

12. apr. 2020 kl. 21:12 skrev Helge Skrivervik ***@***.***>: Sorry, I just had to mention this. There aren't much detail yet. I've had elks running for days and weeks on physical, idle - just a few occasional commands. Elks is stable. Then today, after a lot of banging on serial, I cameback and the system was frozen. No messages, just hard hung (requiring power off). More beating to come. Mouse? None in sight - unfortunately. - Mellvik >> 12. apr. 2020 kl. 20:49 skrev Gregory Haerr ***@***.***>: >> >  > the compete hang situation may be serial related. When testing heavily on serial over the past couple of days, I have experienced complete system hang at a couple of occasions. Not in the middle of a transfer, but suddenly all dead. > > Please give more detail! What exactly was the hang, and was there any serial I/O going on? > We definitely need more details on this. Also, perhaps you could attach a mouse to your serial port and run mouse and report whether your results are the same as @pawosm-arm's. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub, or unsubscribe.

[pawosm-arm]

One more thing ktcp lacks. Similarly to slattach it should have ability to specify baud rate. Two steps procedure (stty first, then ktcp) has proven error prone.

[ghaerr]

Hello @pawosm-arm,

PR #664 allows high speed serial communication, which may allow networking without having to have hardware flow control, depending on the speed of your system, the SLIP MTU length, and the ELKS serial ring buffer size.

The ability pass a baud rate to ktcp has been added, and a net shell script in /bin, along with an slattach.sh script for Linux, should greatly help setting up and getting networking working. Also, all basic issues with using telnet into or out of ELKS have been worked on, and now work both directions with ELKS over SLIP. There are still a number of TCP issues remaining outside of SLIP, but the system now handles "ls -lR /" comfortably at 57600 baud without hanging.

Currently the serial ring buffer is set to 1024. I plan on enhancing ktcp to lower the current SLIP MTU from 1200 or so to below 1024, so as to allow working at short-spurt high baud rates of 57600 on slower systems, when combined with the fast serial driver. On my Linux system, it thinks the ELKS SLIP MTU is 296 for some reason so things are working well. I think the SLIP MTU should also be added as a ktcp startup option for testing, which I'll do in an upcoming PR.