NetBSD Problem Report #15251
Received: (qmail 21117 invoked from network); 15 Jan 2002 07:24:45 -0000
Message-Id: <20020115072440.678ADB5@proven.weird.com>
Date: Tue, 15 Jan 2002 02:24:40 -0500 (EST)
From: woods@weird.com (Greg A. Woods)
Reply-To: woods@planix.com (Greg A. Woods)
To: gnats-bugs@gnats.netbsd.org
Subject: /dev/dty?? devices, using puc driver, do not work properly with 'cu'
X-Send-Pr-Version: 3.95
>Number: 15251
>Category: bin
>Synopsis: /dev/dty?? devices, using puc driver, do not work properly with 'cu'
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bin-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Jan 15 07:25:00 +0000 2002
>Closed-Date:
>Last-Modified: Sun Oct 29 20:25:00 +0000 2006
>Originator: Greg A. Woods
>Release: 2001/06/24
>Organization:
Planix, Inc.; Toronto, Ontario; Canada
>Environment:
System: NetBSD 1.5W
Architecture: i386
Machine: i386
>Description:
/dev/dty?? devices, via puc, do not work properly with 'cu'
We've installed a Lava Computers DSerial PCI serial ports card
for use with a modem for UUCP. Since this system is new enough
to support /dev/dty?? dial-out devices, I tried them but found
the change of carrier when the CONNECT message was issued
triggered a SIGHUP! (I.e. presumably with a transition of DCD
from off to on!)
puc0 at pci0 dev 8 function 0: Lava Computers serial port (com)
com3 at puc0 port 0: interrupting at irq 9
com3: ns16550a, working fifo
puc1 at pci0 dev 8 function 1: Lava Computers serial port (com)
com4 at puc1 port 0: interrupting at irq 9
com4: ns16550a, working fifo
I'm guessing this is a bug in 'cu', though I mention the kernel
and driver information in case it's relevant. (Should SIGHUP
really be sent on trasition of DCD from off to on!?!?!?)
>How-To-Repeat:
# ### configure /etc/uucp/*
# ### edit /etc/uucp/Devices to use "ACU dty03 - 38400 hayes \T"
# ### note phone number has been obscured....
# cu -dddd --parity=none weirdo
/usr/bin/cu: fconn_open: Opening port ACU (speed 38400)
/usr/bin/cu: fconn_set: Changing setting to 1, 2, 2
/usr/bin/cu: fcsend: Writing sleep "A" pause "TE1V1X1Q0S2=255S12=255\r"
/usr/bin/cu: icexpect: Looking for 3 "OK\r"
/usr/bin/cu: icexpect: Got "ATE1V1X1Q0S2=255S12=255\r\r\nOK\r" (found it)
/usr/bin/cu: fcsend: Writing echo-check-on "ATDT/usr/bin/cu: fconn_read: Read 1 "A"
/usr/bin/cu: fconn_read: Read 1 "T"
/usr/bin/cu: fconn_read: Read 1 "D"
/usr/bin/cu: fconn_read: Read 1 "T"
" \T "4165551212/usr/bin/cu: fconn_read: Read 1 "4"
/usr/bin/cu: fconn_read: Read 1 "1"
/usr/bin/cu: fconn_read: Read 1 "6"
/usr/bin/cu: fconn_read: Read 1 "5"
/usr/bin/cu: fconn_read: Read 1 "5"
/usr/bin/cu: fconn_read: Read 1 "5"
/usr/bin/cu: fconn_read: Read 1 "1"
/usr/bin/cu: fconn_read: Read 1 "2"
/usr/bin/cu: fconn_read: Read 1 "1"
/usr/bin/cu: fconn_read: Read 1 "2"
\r/usr/bin/cu: fconn_read: Read 1 "\r"
"
/usr/bin/cu: icexpect: Looking for 7 "CONNECT"
/usr/bin/cu: icexpect: Got "\r\nCONNECT" (found it)
Connected.
28800/RQ/V34/L/usr/bin/cu: Got hangup signal
/usr/bin/cu: Exit status 0
/usr/bin/cu: fconn_close: Closing connection
Disconnected.
# ### edit /etc/uucp/Devices to use "ACU tty03 - 38400 hayes \T"
$ cu -ddd --parity=none weirdo
/usr/bin/cu: fconn_open: Opening port ACU (speed 38400)
/usr/bin/cu: fconn_set: Changing setting to 1, 2, 2
/usr/bin/cu: fcsend: Writing sleep "A" pause "TE1V1X1Q0S2=255S12=255\r"
/usr/bin/cu: icexpect: Looking for 3 "OK\r"
/usr/bin/cu: icexpect: Got "ATE1V1X1Q0S2=255S12=255\r\r\nOK\r" (found it)
/usr/bin/cu: fcsend: Writing echo-check-on "ATDT/usr/bin/cu: fconn_read: Read 1 "A"
/usr/bin/cu: fconn_read: Read 1 "T"
/usr/bin/cu: fconn_read: Read 1 "D"
/usr/bin/cu: fconn_read: Read 1 "T"
" \T "4165551212/usr/bin/cu: fconn_read: Read 1 "4"
/usr/bin/cu: fconn_read: Read 1 "1"
/usr/bin/cu: fconn_read: Read 1 "6"
/usr/bin/cu: fconn_read: Read 1 "5"
/usr/bin/cu: fconn_read: Read 1 "5"
/usr/bin/cu: fconn_read: Read 1 "5"
/usr/bin/cu: fconn_read: Read 1 "1"
/usr/bin/cu: fconn_read: Read 1 "2"
/usr/bin/cu: fconn_read: Read 1 "1"
/usr/bin/cu: fconn_read: Read 1 "2"
\r/usr/bin/cu: fconn_read: Read 1 "\r"
"
/usr/bin/cu: icexpect: Looking for 7 "CONNECT"
/usr/bin/cu: icexpect: Got "\r\nCONNECT" (found it)
Connected.
28800/RQ/V34/LAPM/V42BIS
BSD (weird.com) (tty03)
login: /usr/bin/cu: fconn_write: Writing 1 "\004"
/usr/bin/cu: Got hangup signal
/usr/bin/cu: Exit status 0
/usr/bin/cu: fconn_close: Closing connection
Disconnected.
>Fix:
unknown
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed
State-Changed-By: elad@netbsd.org
State-Changed-When: Sat, 07 Oct 2006 18:18:28 +0000
State-Changed-Why:
cu was recently replaced with tip
From: "Greg A. Woods" <woods@weird.com>
To: gnats-bugs@NetBSD.org
Cc: elad@netbsd.org
Subject: Re: bin/15251 (/dev/dty?? devices, using puc driver, do not work properly with 'cu')
Date: Wed, 11 Oct 2006 16:38:32 -0400
--pgp-sign-Multipart_Wed_Oct_11_16:38:09_2006-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
At Sat, 7 Oct 2006 18:18:29 +0000 (UTC),
elad@netbsd.org wrote:
>=20
> Synopsis: /dev/dty?? devices, using puc driver, do not work properly with=
'cu'
>=20
> State-Changed-From-To: open->closed
> State-Changed-By: elad@netbsd.org
> State-Changed-When: Sat, 07 Oct 2006 18:18:28 +0000
> State-Changed-Why:
> cu was recently replaced with tip
cu(1) is still included in supported versions of NetBSD. It would be
still be very nice if it worked properly.
Furthermore you can't really just replace cu(1) with tip(1) -- they have
quite different uses and tip(1) is severely deficient in several
important ways.
--=20
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Secrets of the Weird <woods@weird.com>
--pgp-sign-Multipart_Wed_Oct_11_16:38:09_2006-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: I837CWpZE2BP1uBH0K7kGg6J2g6sUkUB
iQA/AwUBRS1WSGJ7XxTCWceFEQJjgACg2qloDwITMpnKyS4Ol5ZUBaaLMWYAoNse
FnIYDbcrYl7qurIG3lxV4F4K
=hYRR
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Wed_Oct_11_16:38:09_2006-1--
State-Changed-From-To: closed->open
State-Changed-By: jnemeth@netbsd.org
State-Changed-When: Sun, 29 Oct 2006 20:18:43 +0000
State-Changed-Why:
problem still exists in supported versions of NetBSD
From: John Nemeth <jnemeth@victoria.tc.ca>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, woods@planix.com
Subject: Re: bin/15251 (/dev/dty?? devices, using puc driver, do not work properly with 'cu')
Date: Sun, 29 Oct 2006 12:22:17 -0800 (PST)
From: "Greg A. Woods" <woods@weird.com>
Date: Wed, 11 Oct 2006 20:40:02 +0000 (UTC)
The following reply was made to PR bin/15251; it has been noted by GNATS.
From: "Greg A. Woods" <woods@weird.com>
To: gnats-bugs@NetBSD.org
Cc: elad@netbsd.org
Date: Wed, 11 Oct 2006 16:38:32 -0400
At Sat, 7 Oct 2006 18:18:29 +0000 (UTC),
elad@netbsd.org wrote:
>
> Synopsis: /dev/dty?? devices, using puc driver, do not work properly with 'cu'
>
> State-Changed-From-To: open->closed
> State-Changed-By: elad@netbsd.org
> State-Changed-When: Sat, 07 Oct 2006 18:18:28 +0000
> State-Changed-Why:
> cu was recently replaced with tip
cu(1) is still included in supported versions of NetBSD. It would be
still be very nice if it worked properly.
I have re-opened the PR, since you are right that PRs can be
filed against any supported version.
Furthermore you can't really just replace cu(1) with tip(1) -- they have
quite different uses and tip(1) is severely deficient in several
important ways.
tip(1) in -current has been upgraded to have all the features of
cu(1). Are you aware of any that might be missing?
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.