NetBSD Problem Report #47877

From mlelstv@pepew.1st.de  Sun Jun  2 11:19:55 2013
Return-Path: <mlelstv@pepew.1st.de>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 1930A71977
	for <gnats-bugs@gnats.NetBSD.org>; Sun,  2 Jun 2013 11:19:55 +0000 (UTC)
Message-Id: <20130602111926.F1AED2CC2D@pepew.1st.de>
Date: Sun,  2 Jun 2013 13:19:26 +0200 (CEST)
From: mlelstv@serpens.de
Reply-To: mlelstv@serpens.de
To: gnats-bugs@gnats.NetBSD.org
Subject: tip(1) does not disable flow control
X-Send-Pr-Version: 3.95

>Number:         47877
>Category:       bin
>Synopsis:       tip(1) does not disable flow control
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jun 02 11:20:00 +0000 2013
>Closed-Date:    Thu Nov 20 20:59:16 +0000 2014
>Last-Modified:  Thu Nov 20 20:59:16 +0000 2014
>Originator:     Michael van Elst
>Release:        NetBSD 6.1_RC2
>Organization:
-- 
                                Michael van Elst
Internet: mlelstv@serpens.de
                                "A potential Snark may lurk in every tree."
>Environment:


System: NetBSD pepew 6.1_RC2 NetBSD 6.1_RC2 (PEPEW) #2: Sun Apr 21 11:10:25 CEST 2013 src@pepew:/home/build/obj/usr/src/sys/arch/i386/compile/PEPEW i386
Architecture: i386
Machine: i386
>Description:
The command tip(1) is used to communicate with a serial device
and supports the option -F to select between no handshake,
tandem mode (xon/xoff) and hardware handshake.

Selecting tandem mode however only configures the IXOFF flag,
leaving xon/xoff processing enabled for input.

If you look at more recent tip sources from Illumos, you can see that
it configures IXOFF and IXON flags together. I suggest to do the same.

>How-To-Repeat:

Use cu -F none to talk to a serial console of another NetBSD machine.
Our serial console doesn't support xon/xoff processing, however even
with -F none you see xon/xoff characters sent to it.

>Fix:

Index: usr.bin/tip/cmds.c
===================================================================
RCS file: /cvsroot/src/usr.bin/tip/cmds.c,v
retrieving revision 1.35
diff -u -r1.35 cmds.c
--- usr.bin/tip/cmds.c	24 Feb 2012 16:03:39 -0000	1.35
+++ usr.bin/tip/cmds.c	2 Jun 2013 11:17:00 -0000
@@ -792,11 +792,11 @@

 	(void)tcgetattr(FD, &rmtty);
 	if (strcmp(option, "on") == 0) {
-		rmtty.c_iflag |= IXOFF;
-		term.c_iflag |= IXOFF;
+		rmtty.c_iflag |= (IXOFF|IXON);
+		term.c_iflag |= (IXOFF|IXON);
 	} else {
-		rmtty.c_iflag &= ~IXOFF;
-		term.c_iflag &= ~IXOFF;
+		rmtty.c_iflag &= ~(IXOFF|IXON);
+		term.c_iflag &= ~(IXOFF|IXON);
 	}
 	(void)tcsetattr(FD, TCSADRAIN, &rmtty);
 	(void)tcsetattr(0, TCSADRAIN, &term);
Index: usr.bin/tip/tip.c
===================================================================
RCS file: /cvsroot/src/usr.bin/tip/tip.c,v
retrieving revision 1.51
diff -u -r1.51 tip.c
--- usr.bin/tip/tip.c	6 Sep 2011 18:33:01 -0000	1.51
+++ usr.bin/tip/tip.c	2 Jun 2013 11:17:00 -0000
@@ -496,7 +496,7 @@
 	cntrl.c_cc[VMIN] = 1;
 	cntrl.c_cc[VTIME] = 0;
 	if (boolean(value(TAND)))
-		cntrl.c_iflag |= IXOFF;
+		cntrl.c_iflag |= (IXOFF|IXON);
 	return tcsetattr(FD, TCSAFLUSH, &cntrl);
 }


>Release-Note:

>Audit-Trail:
From: "Christos Zoulas" <christos@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/47877 CVS commit: src/usr.bin/tip
Date: Sun, 2 Jun 2013 09:18:12 -0400

 Module Name:	src
 Committed By:	christos
 Date:		Sun Jun  2 13:18:12 UTC 2013

 Modified Files:
 	src/usr.bin/tip: cmds.c tip.c

 Log Message:
 PR/47877: Michael van Elst: Disable and enable software flow control properly


 To generate a diff of this commit:
 cvs rdiff -u -r1.35 -r1.36 src/usr.bin/tip/cmds.c
 cvs rdiff -u -r1.51 -r1.52 src/usr.bin/tip/tip.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/47877: tip(1) does not disable flow control
Date: Sun, 2 Jun 2013 17:55:23 +0000

 On Sun, Jun 02, 2013 at 11:20:00AM +0000, mlelstv@serpens.de wrote:
  > >Fix:
  > 
  > Index: usr.bin/tip/cmds.c

 ...why not just commit? :-)

 -- 
 David A. Holland
 dholland@netbsd.org

State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 07 Oct 2013 03:27:02 +0000
State-Changed-Why:
committed -- is this fixed? and does it need to be in -6?


From: Michael van Elst <mlelstv@serpens.de>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, dholland@NetBSD.org
Subject: Re: bin/47877 (tip(1) does not disable flow control)
Date: Mon, 7 Oct 2013 08:46:43 +0200

 On Mon, Oct 07, 2013 at 03:27:03AM +0000, dholland@NetBSD.org wrote:
 > Synopsis: tip(1) does not disable flow control
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: dholland@NetBSD.org
 > State-Changed-When: Mon, 07 Oct 2013 03:27:02 +0000
 > State-Changed-Why:
 > committed -- is this fixed? and does it need to be in -6?

 The problem is fixed. The change however also modifies the IXANY flag
 which is questionable.

 Greetings,
 -- 
                                 Michael van Elst
 Internet: mlelstv@serpens.de
                                 "A potential Snark may lurk in every tree."

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, mlelstv@serpens.de
Subject: Re: bin/47877 (tip(1) does not disable flow control)
Date: Mon, 7 Oct 2013 07:45:26 +0000

 On Mon, Oct 07, 2013 at 06:50:01AM +0000, Michael van Elst wrote:
  >  On Mon, Oct 07, 2013 at 03:27:03AM +0000, dholland@NetBSD.org wrote:
  >  > Synopsis: tip(1) does not disable flow control
  >  > 
  >  > State-Changed-From-To: open->feedback
  >  > State-Changed-By: dholland@NetBSD.org
  >  > State-Changed-When: Mon, 07 Oct 2013 03:27:02 +0000
  >  > State-Changed-Why:
  >  > committed -- is this fixed? and does it need to be in -6?
  >  
  >  The problem is fixed. The change however also modifies the IXANY flag
  >  which is questionable.

 That seems reasonable to me... it seems unlikely that anyone's going
 to be using tip(1) over a vintage modem where IXANY allows line noise
 to mess things up.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Michael van Elst <mlelstv@serpens.de>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: bin/47877 (tip(1) does not disable flow control)
Date: Mon, 7 Oct 2013 21:12:14 +0200

 On Mon, Oct 07, 2013 at 07:50:00AM +0000, David Holland wrote:
 >   >  The problem is fixed. The change however also modifies the IXANY flag
 >   >  which is questionable.
 >  
 >  That seems reasonable to me... it seems unlikely that anyone's going
 >  to be using tip(1) over a vintage modem where IXANY allows line noise
 >  to mess things up.

 It's not about line noise. When xon/xoff is used for flow control,
 any bidirectional protocol may prevent it from functioning and you
 have to rely on that protocol to recover from loss of input characters.

 Greetings,
 -- 
                                 Michael van Elst
 Internet: mlelstv@serpens.de
                                 "A potential Snark may lurk in every tree."

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/47877 (tip(1) does not disable flow control)
Date: Tue, 8 Oct 2013 06:04:00 +0000

 On Mon, Oct 07, 2013 at 07:15:01PM +0000, Michael van Elst wrote:
  >  On Mon, Oct 07, 2013 at 07:50:00AM +0000, David Holland wrote:
  > > >  The problem is fixed. The change however also modifies the IXANY flag
  > > >  which is questionable.
  > >  
  > >  That seems reasonable to me... it seems unlikely that anyone's going
  > >  to be using tip(1) over a vintage modem where IXANY allows line noise
  > >  to mess things up.
  >  
  >  It's not about line noise. When xon/xoff is used for flow control,
  >  any bidirectional protocol may prevent it from functioning and you
  >  have to rely on that protocol to recover from loss of input characters.

 I'm not sure I follow - most such protocols will also trigger xoff
 inadvertently and therefore you'd better disable xon/xoff before using
 them.

 also I'd hope in this day and age anyone doing stuff where this
 matters would be using a 7-wire cable.

 Anyway, if you think it's wrong or you have an application where it
 breaks, I'd just go ahead and change it, or maybe if feeling ambitious
 hack it so it switches off IXANY when spawning kermit/rz/whatever.
 Otherwise I'd leave it alone -- the biggest problem with xon/xoff in
 practice is that users trigger it by accident and don't know how to
 recover.

 -- 
 David A. Holland
 dholland@netbsd.org

State-Changed-From-To: feedback->closed
State-Changed-By: mlelstv@NetBSD.org
State-Changed-When: Thu, 20 Nov 2014 20:59:16 +0000
State-Changed-Why:
IXANY is no longer set. The issue is fixed.


>Unformatted:

Home	PR Database Search