The Linux kernel can be asked to do CTS/RTS flow control using the r option on the console= parameter. For example, a serial link at 9600bps with 8 data bits, no parity and CTS/RTS flow control is configured as shown in Figure A-1.
Because the Linux kernel only ever sends data, CTS/RTS flow control is implemented by checking that Clear to Send is not asserted. The code which does is found in /usr/src/linux/drivers/char/serial.c, the relevant portion can be seen in Figure A-2.
Figure A-2. Kernel source code for console CTS/RTS flow control
static inline void wait_for_xmitr(struct async_struct *info)
{
…
/* Wait for flow control if necessary */
if (info->flags & ASYNC_CONS_FLOW) {
tmout = 1000000;
while (--tmout &&
((serial_in(info, UART_MSR) & UART_MSR_CTS) == 0));
}
} |
The loop driven by the tmout value of
1000000 results in a wait of about one second for the
CTS line to become asserted.
This code ignores the status of the RS-232 Data Set Ready and Data Carrier Detect status lines. This has a number of consequences.
If the RS-232 cable is unplugged or the terminal server port is idle then the code waits for CTS to be asserted for about one second for every character written to the console. So the huge number of characters written to the console when booting a machine can result in a very long wait for a reboot.
Clear to Send is only validly asserted if Data Carrier Detect and Data Set Ready are asserted. The code should allow for an unpowered device which allows CTS to float.
After looping one million times, if Clear to Send is not assrted then the character is sent in any case. Thus the kernel cannot be used on multidrop RS-232 lines. The character should be dropped instead.
The character is sent even if Data Carrier Detect is not asserted. Thus the attached modem may be in command mode. This results in a security flaw if an attacker can get arbitrary text placed in a console messages. As many console messages contain error text derived from user events, it would not be too difficult to place AT&F in a console message and unprogram the modem's auto-answer configuration.
As a result of these bugs this HOWTO no longer recommends the use of kernel-level flow control. The author has a kernel patch which fixes all current-reported bugs and is attempting to get that patch integrated into the mainline kernel. Once the kernel bugs are corrected this HOWTO will once again recommend kernel-level flow control.