>Number:         33929
>Category:       kern
>Synopsis:       ucom fails to assert DTR
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jul 06 12:25:00 +0000 2006
>Originator:     Andreas Gustafsson
>Release:        NetBSD 3.99.21
>Organization:
>Environment:
System: NetBSD guru.araneus.fi 3.99.21 NetBSD 3.99.21 (GENERIC) #0: Tue Jul 4 08:49:35 EEST 2006 gson@guru.araneus.fi:/usr/build/1002/obj/sys/arch/i386/compile/GENERIC i386
Architecture: i386
Machine: i386
>Description:

I recently attempted to make a GPRS connection from a NetBSD-current
system using an Ericsson T39m GSM phone and Ericsson DCU-11 USB cable
(this is actually a USB-to-serial converter with a proprietary serial
connector that plugs into the phone; it is supported by the uplcom
driver).

I found I was unable to connect because the chat script invoked by
pppd got no response to the AT commands it sent to the phone's
built-in GPRS "modem".  It had worked the last time I tried it,
several OS upgrades ago, but I don't remember the exact NetBSD
version where it last worked.

I tried sending AT commands manually using "tip", and found that the
letters A and T at the beginning of the command were echoed by the
phone, but the remainder of the AT command was not, and there was no
"OK" or other response.  Despite the lack of a response, the phone did
act on the commands.

To further debug the problem, I plugged in an ATEN USB-to-serial
converter which is also supported by the uplcom driver but has a
standard 9-pin serial connector, and connected it to a serial tester.
When I opened the ttyU0 port using "tip", the tester indicated that
DTR was asserted, but RTS was not.

I also tried a third converter, a Belkin USB PDA adapter supported by
the umct driver, and found that it behaved similarly (unlike the ATEN,
it did assert DTR when first plugged in, but deasserted it as soon as
ttyU0 was opened).

Apparently the T39m is doing RTS/CTS flow control, and the output is
kept buffered while RTS is deasserted (though for some reason, the A
and T at the beginning of each AT command are still sent).

Setting the crtscts flags on the tty made no difference.  However,
running the following C program with standard input redirected from
/dev/ttyU0 fixed the problem:

   #include <sys/ttycom.h>

   int main(int argc, char **argv) {
       int i = TIOCM_RTS;
       ioctl(0, TIOCMBIS, &i);
   }

The attached patch also fixes the problem.

>How-To-Repeat:

Connect a DCU-11 and T39m, add the line

   ttyU0:dv=/dev/ttyU0:br#115200:pa=none:dc:

to /etc/remote, and type "tip ttyU0".  Attempt to issue AT commands
and notice the partial lack of echo, and the complete lack of
response.

Alternatively, connect a USB-to-serial converter and serial tester,
connect using tip as above, and notice the lack of DTR.

>Fix:

The following patch works for me.  Suggestions for better fixes are
welcome; otherwise I will commit this one.

Index: sys/dev/usb/ucom.c
===================================================================
RCS file: /cvsroot/src/sys/dev/usb/ucom.c,v
retrieving revision 1.63
diff -u -r1.63 ucom.c
--- sys/dev/usb/ucom.c	14 May 2006 21:47:00 -0000	1.63
+++ sys/dev/usb/ucom.c	6 Jul 2006 12:05:12 -0000
@@ -392,9 +392,10 @@
 		 * present, because otherwise we'd have to use TIOCSDTR
 		 * immediately after setting CLOCAL, which applications do not
 		 * expect.  We always assert DTR while the device is open
-		 * unless explicitly requested to deassert it.
+		 * unless explicitly requested to deassert it.  Ditto RTS.
 		 */
 		ucom_dtr(sc, 1);
+		ucom_rts(sc, 1);		
 
 		/* XXX CLR(sc->sc_rx_flags, RX_ANY_BLOCK);*/
 		ucom_hwiflow(sc);