linux-kernel - serial flow control appears broken

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <46A7FE6A.4030309@howardsilvan.com>
Date:	Wed, 25 Jul 2007 18:52:42 -0700
From:	Lee Howard <faxguy@...ardsilvan.com>
To:	linux-serial@...r.kernel.org, tytso@....edu, rmk@....linux.org.uk,
	linux-kernel@...r.kernel.org
Subject: serial flow control appears broken

Hello.

I have fax modems that will, in their proper behavior with certain 
features, send up to 64 kilobytes of data to the host DTE all at once.  
(So, the fax modem handles an incoming fax and periodically will send 
between 256 bytes and 64 kilobytes of data in bursts.)

When the DCE-DTE (modem-to-host) communication rate is established at 
115200 bps data loss occurs systems using at least Linux kernels 2.6.5 
and 2.6.18 (and probably everything in-beween and then some more).  This 
is because the modem overflows the host's buffer.  This is evidenced in 
kernel logging:

Jul 23 14:01:30 gollum kernel: ttyS1: 1 input overrun(s)
Jul 23 17:09:45 gollum kernel: ttyS1: 1 input overrun(s)

Normally I would blame the modem itself for not honoring the host's flow 
control signals.  However, I have worked with the modem manufacturer 
closely on this matter for over three months now.  In that process they 
have improved the responsiveness of the modem and have fixed other 
problems, but the end result is that it truly does appear that the 
serial tty driver is not using flow control.  Whether software flow 
control (XON/XOFF) or hardware flow control (RTS/CTS) is used the result 
is the same.

This is evidenced in hardware flow control by a little LED labeled "RTS" 
that is on the external modem.  This LED lights up when pin 7 of the DB9 
serial connection is given +12Vdc current (signalling "RTS" is on - that 
the host can accept data).  The LED goes dark when the current is 
removed (signalling that the host cannot accept data).  This "RTS" LED 
never flickers at all, as it should, when receiving these bursts of data 
- the LED stays lit as long as the serial cable is connected to the 
host... and yet I will see those "input overrun" messages.  Thus, it 
seems quite clear that the Linux serial tty driver is not deasserting 
RTS as it should in hardware flow control.  (And probably the analogous 
problem exists in software flow control, too.)

Please tell me what I can do to help you resove and/or remedy this 
matter.  Also, please let me know if I have contacted the wrong people.  
(I have cross-posted to linux-kernel as a catch-all.  I am not 
subscribed to either linux-serial or linux-kernel mailing lists.  So 
please CC me in any list responses.)

If it is of any value to know (perhaps they have common code?), the same 
error occurs on FreeBSD 6.2 as well.   The problem does not occur on 
Windows.  The problem does not occur on RedHat 6.0 (kernel 2.2.5).

Thanks,

Lee.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/