From sa@pc-siu.svznov.kuzbass.ru  Sat Jul  5 21:21:50 2003
Return-Path: <sa@pc-siu.svznov.kuzbass.ru>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 1574137B401
	for <FreeBSD-gnats-submit@freebsd.org>; Sat,  5 Jul 2003 21:21:50 -0700 (PDT)
Received: from pc-siu.svznov.kuzbass.ru (pc-siu.svznov.kemerovo.su [213.184.64.68])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 8244044022
	for <FreeBSD-gnats-submit@freebsd.org>; Sat,  5 Jul 2003 21:21:46 -0700 (PDT)
	(envelope-from sa@pc-siu.svznov.kuzbass.ru)
Received: from pc-siu.svznov.kuzbass.ru (smmsp@localhost [127.0.0.1])
	by pc-siu.svznov.kuzbass.ru (8.12.9/8.12.9) with ESMTP id h664LhU5024265
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 6 Jul 2003 12:21:43 +0800 (KRAST)
	(envelope-from sa@pc-siu.svznov.kuzbass.ru)
Received: (from root@localhost)
	by pc-siu.svznov.kuzbass.ru (8.12.9/8.12.9/Submit) id h664Lg8m024264;
	Sun, 6 Jul 2003 12:21:42 +0800 (KRAST)
Message-Id: <200307060421.h664Lg8m024264@pc-siu.svznov.kuzbass.ru>
Date: Sun, 6 Jul 2003 12:21:42 +0800 (KRAST)
From: Eugene Grosbein <eugen@grosbein.pp.ru>
Reply-To: eugen@grosbein.pp.ru
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: wrong behavour of cu(1)
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         54141
>Category:       bin
>Synopsis:       wrong behavour of cu(1)
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Jul 05 21:30:10 PDT 2003
>Closed-Date:    
>Last-Modified:  Fri Apr 30 13:00:35 PDT 2004
>Originator:     Eugene Grosbein
>Release:        FreeBSD 4.8-STABLE i386
>Organization:
Svyaz Service JSC
>Environment:
System: FreeBSD pc-siu.svznov.kuzbass.ru 4.8-STABLE FreeBSD 4.8-STABLE #4: Mon May 26 15:07:27 KRAST 2003 root@pc-siu2.svznov.kuzbass.ru:/usr/obj/usr/src/sys/PC-SIU i386

>Description:
	
	cu(1) does not work with some devices connected to serial ports.
	cu -l cuaa1 fails to send or receive a character while
	stock tip(1) or minicom from ports both work nice.

	cu(1) works nice with asyncronous analog modems but does not
	work with some other devices. I have access to couple of such, f.e:

	- Watson IV MSDSL modem and some other DSL modems with serial port
	  (9600, 8-N-1, XON/XOFF)
	- Ericsson MD110 PBX SIU board (2400, 8-N-1, XON/XOFF)

	Sometimes, when I leave cu(1) run connected to a port
	it succeedes to reteive several lines from port but only after
	long run. It seems there is flow control problem, cu(1)
	does not work with devices without hardware flow control.

	Note that tip(1) and minicom use theirs own serial port settins
	for things like parity/flow control while cu(1) relies
	on defaults that can be changed with stty(1).
	Also note that problem devices are low-speed (9600 and slower)
	and do not support flow control. I also have 38400/XON/XOFF devices
	that do not have problems with cu(1).

>How-To-Repeat:
	
	Get FreeBSD 4.8 or later (it seems this problem was introduced
	beenween 4.7 and 4.8, but I'm not sure). Get one of mentioned
	devices or try other slow xon/xoff-controlled devices.

>Fix:

	Unknown for me.
	As workaround, I use tip(1) or minicom that work nice
	with all devices I have.

>Release-Note:
>Audit-Trail:

From: Eugene Grosbein <eugen@kuzbass.ru>
To: freebsd-gnats-submit@FreeBSD.org
Cc: stable@FreeBSD.org
Subject: Re: bin/54141: wrong behavour of cu(1)
Date: Fri, 14 Nov 2003 10:38:55 +0700

 Hi!
 
 There is a strange workaroung for this problem: start "cu -l cuaa0"
 then switch to another terminal, do "stty -crtscts </dev/cuaa0"
 and cu starts to work as expected (for this run only).
 
 It seems that cu(1) does not respect prior command 
 "stty -crtscts </dev/cuaia0" anymore. Or it might be a kernel bug
 as preliminary "stty -crtscts </dev/cuala0" does not help too.
 
 Eugene Grosbein

From: Valentin Nechayev <netch@netch.kiev.ua>
To: bug-followup@freebsd.org
Cc:  
Subject: Re: bin/54141: wrong behavour of cu(1)
Date: Fri, 30 Apr 2004 09:25:17 +0300

 >  There is a strange workaroung for this problem: start "cu -l cuaa0"
 >  then switch to another terminal, do "stty -crtscts </dev/cuaa0"
 >  and cu starts to work as expected (for this run only).
 
 cu sets hardflow by itself.
 
 >  It seems that cu(1) does not respect prior command 
 >  "stty -crtscts </dev/cuaia0" anymore. Or it might be a kernel bug
 >  as preliminary "stty -crtscts </dev/cuala0" does not help too.
 
 To lock a capability, set it in locking device, not unset.

From: Valentin Nechayev <netch@netch.kiev.ua>
To: bug-followup@freebsd.org
Cc:  
Subject: Re: bin/54141: wrong behavour of cu(1)
Date: Fri, 30 Apr 2004 22:52:48 +0300

 Well, results of digging uucp:
 
 fsdirect_open() contains call of set/unset hardware flow control
 _always_:
 
   /* Always turn on hardware flow control for a direct port when it is
      opened.  There is no other sensible time to turn it on.  */
   return fsserial_hardflow (qconn, qd->uuconf_fhardflow);
 
 Whether it will be set or unset, depends on qd->uuconf_fhardflow.
 qd->uuconf_fhardflow is sport.uuconf_u.uuconf_sdirect.uuconf_fhardflow,
 where `sport' is automatic variable of main() in cu/cu.c. This variable:
 1) has no predefined initial value (i.e. contains garbage on start),
 2) is rewritten in cycle around uuconf_find_port(), if /etc/uucp/port
 (case of Taylor configs) exists and port is similar to one wanted
 (e.g. has type=direct).
 
 So, whether cu would set or unset crtscts in case of no ports defined,
 depends on uninitialized data on stack.
 The source of turned on crtscts in FreeBSD >= 4.7 may be depended on gcc
 version, binutils version, libc start stub version, CFLAGS in make.conf, etc.
 The following patch fixed it for me in case with no ports defined:
 
 === cut ===
 --- cu.c.orig	Fri Apr 30 22:38:44 2004
 +++ cu.c	Fri Apr 30 22:46:57 2004
 @@ -598,6 +598,7 @@
  	      sport.uuconf_palloc = NULL;
  	      sport.uuconf_u.uuconf_sdirect.uuconf_zdevice = NULL;
  	      sport.uuconf_u.uuconf_sdirect.uuconf_ibaud = ibaud;
 +	      sport.uuconf_u.uuconf_sdirect.uuconf_fhardflow = 0;
  
  	      if (! fconn_init (&sport, &sconn, UUCONF_PORTTYPE_UNKNOWN))
  		ucuabort ();
 === end cut ===
 
 If you have any direct port defined, and want cu to turn off crtscts without
 the patch show above, define a dummy port with `hardflow no' and put it
 last in port file.
 
 I can't provide any suggestion whether it should be fixed in 4.*
 or in ports/net/freebsd-uucp. To give applicable patch, this should
 at least add command-line switch to select whether crtscts should be set.
 
 
 -netch-
>Unformatted:
