Subject: kern/6502: com driver fails to ignore serial input when CD is low
To: None <>
From: Andreas Gustafsson <>
List: netbsd-bugs
Date: 11/27/1998 18:21:22
>Number:         6502
>Category:       kern
>Synopsis:       com driver fails to ignore serial input when CD is low
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Nov 27 08:35:00 1998
>Originator:     Andreas Gustafsson
Araneus Information Systems Oy
>Release:        1.3.2

System: NetBSD 1.3.2 NetBSD 1.3.2 (GUAVA) #0: Fri Nov 27 15:21:37 EET 1998 i386


When NetBSD's "com" driver is being opened in blocking mode and
waiting in open() for the CD signal to be asserted, it should ignore
any serial input.  What it in fact does is to set the port to the
default speed of 9600 bps and echo (!) any serial input back to the
serial line at that speed.

This means that if the line is in dial-in modem use and the modem
announces an incoming ring with a RING status message, the RING
message will be echoed back to the modem's AT command interpreter.
This confuses some modems to the point that they refuse to answer the
incoming call despite being configured to do so.

Note that this is different from the well-known problem of getty
getting into an infinite login dialog with a modem that has command
echo enabled.  In the case described here, getty never even finishes
opening the tty.

This bug also exists in -current (as of some weeks ago).


Configure a NetBSD 1.2/i386 machine as a dial-in server with a modem
attached to a com port and getty running at 19600 bps, with modem
settings ATE0, ATQ0, ATS0=4.  Upgrade from NetBSD 1.2 to 1.3.2 and 
find that the modem no longer answers incoming calls.

Alternatively, attach a terminal to a com port on a NetBSD 1.3.2 or
-current system with a null modem cable.  Start a getty at 9600 bps.
Cut the CD line on the PC side of the null modem using a break-out box
or equivalent.  Note how everything typed on the terminal keyboard is
now echoed back on the screen, even though getty is blocked in open()
waiting for carrier.  Repeat experiment with getty and the terminal
both set to 19200 bps and find that terminal input gets echoed as


Apply the following patch.

*** src/sys/dev/ic/com.c.pre-echo-fix	Fri Nov 27 14:35:39 1998
--- src/sys/dev/ic/com.c	Fri Nov 27 14:43:38 1998
*** 1367,1372 ****
--- 1367,1374 ----
  	while (cc) {
+ 	        if (!ISSET(tp->t_state, TS_ISOPEN))
+ 		       goto ignore;
  		code = get[0];
  		lsr = get[1];
  		if (ISSET(lsr, LSR_OE | LSR_BI | LSR_FE | LSR_PE)) {
*** 1408,1413 ****
--- 1410,1416 ----
+         ignore:
  		get += 2;
  		if (get >= end)
  			get = sc->sc_rbuf;