$ cat STRACE_CU.3140
close(4) = 0
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR) = 0
rt_sigaction(SIGUSR1, {0x8051460, [], SA_INTERRUPT}, NULL, 8) = 0
rt_sigaction(SIGUSR2, {0x8051460, [], SA_INTERRUPT}, NULL, 8) = 0
rt_sigaction(SIGINT, {SIG_IGN, [], SA_INTERRUPT}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_INTERRUPT}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {SIG_DFL, [], SA_INTERRUPT}, NULL, 8) = 0
rt_sigaction(SIGTERM, {0x8051460, [], SA_INTERRUPT}, NULL, 8) = 0
read(3, 0xbfd1be0c, 1024) = ? ERESTARTSYS (To be restarted)
--- SIGTERM (Terminated) @ 0 (0) ---
sigreturn() = ? (mask now [])
exit_group(0) = ?
** Description changed:
almost entirely default install of xubuntu 12.10; note that i'm running
a 3.7 kernel (because of Bug #1085115), but the problem is the same with
the default kernel. if i boot this box in openbsd or netbsd, cu will
connect just fine.
i need to access a terminal on another host, which is directly connected
with a serial cable.
$ sudo uname -a
- [CODE]Linux iugo 3.7.0-4-generic #12~lp1085115v1 SMP Fri Nov 30 20:57:19 UTC
2012 i686 i686 i686 GNU/Linux[/CODE]
+ Linux iugo 3.7.0-4-generic #12~lp1085115v1 SMP Fri Nov 30 20:57:19 UTC 2012
i686 i686 i686 GNU/Linux
$ sudo dmesg|grep tty
- [CODE][ 0.000000] console [tty0] enabled
+ [ 0.000000] console [tty0] enabled
[ 0.663436] 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
- [ 0.683785] 00:07: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A[/CODE]
+ [ 0.683785] 00:07: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
i am assuming a standard 16550 uart buffer is handled by the main
kernel, and hardware support is not at issue here.
$ sudo ls -al /dev/ttyS?
- [CODE]crw-rw---- 1 root dialout 4, 64 Dec 8 10:05 /dev/ttyS0
+ crw-rw---- 1 root dialout 4, 64 Dec 8 10:05 /dev/ttyS0
crw-rw---- 1 root dialout 4, 65 Dec 8 10:05 /dev/ttyS1
crw-rw---- 1 root dialout 4, 66 Dec 8 10:05 /dev/ttyS2
crw-rw---- 1 root dialout 4, 67 Dec 8 10:05 /dev/ttyS3
crw-rw---- 1 root dialout 4, 68 Dec 8 10:05 /dev/ttyS4
crw-rw---- 1 root dialout 4, 69 Dec 8 10:05 /dev/ttyS5
crw-rw---- 1 root dialout 4, 70 Dec 8 10:05 /dev/ttyS6
crw-rw---- 1 root dialout 4, 71 Dec 8 10:05 /dev/ttyS7
crw-rw---- 1 root dialout 4, 72 Dec 8 10:05 /dev/ttyS8
- crw-rw---- 1 root dialout 4, 73 Dec 8 10:05 /dev/ttyS9[/CODE]
+ crw-rw---- 1 root dialout 4, 73 Dec 8 10:05 /dev/ttyS9
$ sudo cat /proc/tty/driver/serial
- [CODE]serinfo:1.0 driver revision:
+ serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:0 rx:0 DSR
- 1: uart:16550A port:000002F8 irq:3 tx:0 rx:0[/CODE]
+ 1: uart:16550A port:000002F8 irq:3 tx:0 rx:0
$ sudo cat /etc/group|grep koen
- [CODE]adm:x:4:koen
+ adm:x:4:koen
tty:x:5:koen,root
uucp:x:10:koen,root
dialout:x:20:koen,root
cdrom:x:24:koen
sudo:x:27:koen
audio:x:29:pulse,koen
dip:x:30:koen
video:x:44:koen
plugdev:x:46:koen
fuse:x:104:koen
lpadmin:x:107:koen
scanner:x:116:koen
- koen:x:1000:[/CODE]
+ koen:x:1000:
$ sudo which cu
- [CODE]/usr/bin/cu[/CODE]
+ /usr/bin/cu
$ cu -l /dev/ttyS0 -s 115200
- [CODE]Connected.[/CODE]
- note that cu always says "Connected.", this doesn't mean anything; also note
that the baudrate, parity, et cetera... are correct; the cable is healthy and
connected to the right serial port.
+ Connected.
+
+ note that cu always says "Connected.", this doesn't mean anything; also
+ note that the baudrate, parity, et cetera... are correct; the cable is
+ healthy and connected to the right serial port.
$ sudo cu -l /dev/ttyS0 -s 115200
- [CODE]/usr/bin/cu: open (/dev/ttyS0): Permission denied
- /usr/bin/cu: /dev/ttyS0: Line in use[/CODE]
+ /usr/bin/cu: open (/dev/ttyS0): Permission denied
+ /usr/bin/cu: /dev/ttyS0: Line in use
$ sudo su -
# cu -l /dev/ttyS0 -s 115200
- [CODE]/usr/bin/cu: open (/dev/ttyS1): Permission denied
- /usr/bin/cu: /dev/ttyS1: Line in use[/CODE]
+ /usr/bin/cu: open (/dev/ttyS1): Permission denied
+ /usr/bin/cu: /dev/ttyS1: Line in use
if i make user 'root' part of the mandatory group 'dialout', it doesn't
make any difference anymore whether i try this with an uid of 0 or not.
to rule things out, i made a polkit action definition for this. logs
confirmed the action definition worked. i tried the above scenarios with
polkit's pkexec. it didn't make any difference.
to rule things out, i tried making a pam exception for this
(capabilities), by adding some lines to /etc/security/group.conf and
creating /etc/pam.d/cu. it didn't make any difference, but i'm not sure
my pam configuration was entirely correct.
to rule things out, i started fiddling with /bin/stty (which shouldn't
be needed). it didn't make any difference. for the record:
$ sudo stty -a
- [CODE]speed 38400 baud; rows 43; columns 124; line = 0;
+ speed 38400 baud; rows 43; columns 124; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 =
M-^?; swtch = M-^?; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc ixany imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
ff0
- isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke[/CODE]
+ isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke
$ sudo stty -g
-
[CODE]6d02:5:4bf:8a3b:3:1c:7f:15:4:0:1:ff:11:13:1a:ff:12:f:17:16:ff:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0[/CODE]
+
6d02:5:4bf:8a3b:3:1c:7f:15:4:0:1:ff:11:13:1a:ff:12:f:17:16:ff:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
$ sudo stty -F /dev/ttyS0 speed
- [CODE]115200[/CODE]
+ 115200
+
apparently baudrate was set by cu.
$ strace -f -ff -o STRACE_CU cu -l /dev/ttyS0 -s 115200
- [CODE]Connected.
+ Connected.
~.
- Disconnected.[/CODE]
+ Disconnected.
+
i was able to abort the terminal normally, with "~."...
$ ls STRACE_CU.*
- [CODE]STRACE_CU.3139
- STRACE_CU.3140[/CODE]
+ STRACE_CU.3139
+ STRACE_CU.3140
$ cat STRACE_CU.*|grep EPERM
- [CODE]ioctl(3, TIOCSCTTY) = -1 EPERM (Operation not
permitted)[/CODE]
+ ioctl(3, TIOCSCTTY) = -1 EPERM (Operation not permitted)
- full traces attached as files!
+ full traces below...
$ cu -l /dev/ttyS0 -s 115200 --debug all
- [CODE]cu: fconn_open: Opening port /dev/ttyS0 (speed 115200)
+ cu: fconn_open: Opening port /dev/ttyS0 (speed 115200)
cu: fconn_set: Changing setting to 0, 0, 2
Connected.
~.cu: Exit status 0
- cu: fconn_close: Closing connection[/CODE]
+ cu: fconn_close: Closing connection
+
+
+
ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: cu 1.07-20build2
ProcVersionSignature: Ubuntu 3.7.0-4.12~lp1085115v1-generic 3.7.0-rc7
Uname: Linux 3.7.0-4-generic i686
ApportVersion: 2.6.1-0ubuntu9
Architecture: i386
Date: Fri Dec 28 15:05:24 2012
InstallationDate: Installed on 2012-11-29 (28 days ago)
InstallationMedia: Xubuntu 12.10 "Quantal Quetzal" - Release i386 (20121017.1)
MarkForUpload: True
SourcePackage: uucp
UpgradeStatus: No upgrade log present (probably fresh install)
** Description changed:
almost entirely default install of xubuntu 12.10; note that i'm running
a 3.7 kernel (because of Bug #1085115), but the problem is the same with
the default kernel. if i boot this box in openbsd or netbsd, cu will
connect just fine.
i need to access a terminal on another host, which is directly connected
with a serial cable.
$ sudo uname -a
Linux iugo 3.7.0-4-generic #12~lp1085115v1 SMP Fri Nov 30 20:57:19 UTC 2012
i686 i686 i686 GNU/Linux
$ sudo dmesg|grep tty
[ 0.000000] console [tty0] enabled
[ 0.663436] 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 0.683785] 00:07: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
i am assuming a standard 16550 uart buffer is handled by the main
- kernel, and hardware support is not at issue here.
+ kernel, and hardware support is not an issue here.
$ sudo ls -al /dev/ttyS?
crw-rw---- 1 root dialout 4, 64 Dec 8 10:05 /dev/ttyS0
crw-rw---- 1 root dialout 4, 65 Dec 8 10:05 /dev/ttyS1
crw-rw---- 1 root dialout 4, 66 Dec 8 10:05 /dev/ttyS2
crw-rw---- 1 root dialout 4, 67 Dec 8 10:05 /dev/ttyS3
crw-rw---- 1 root dialout 4, 68 Dec 8 10:05 /dev/ttyS4
crw-rw---- 1 root dialout 4, 69 Dec 8 10:05 /dev/ttyS5
crw-rw---- 1 root dialout 4, 70 Dec 8 10:05 /dev/ttyS6
crw-rw---- 1 root dialout 4, 71 Dec 8 10:05 /dev/ttyS7
crw-rw---- 1 root dialout 4, 72 Dec 8 10:05 /dev/ttyS8
crw-rw---- 1 root dialout 4, 73 Dec 8 10:05 /dev/ttyS9
$ sudo cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:0 rx:0 DSR
1: uart:16550A port:000002F8 irq:3 tx:0 rx:0
$ sudo cat /etc/group|grep koen
adm:x:4:koen
tty:x:5:koen,root
uucp:x:10:koen,root
dialout:x:20:koen,root
cdrom:x:24:koen
sudo:x:27:koen
audio:x:29:pulse,koen
dip:x:30:koen
video:x:44:koen
plugdev:x:46:koen
fuse:x:104:koen
lpadmin:x:107:koen
scanner:x:116:koen
koen:x:1000:
$ sudo which cu
/usr/bin/cu
$ cu -l /dev/ttyS0 -s 115200
Connected.
note that cu always says "Connected.", this doesn't mean anything; also
note that the baudrate, parity, et cetera... are correct; the cable is
healthy and connected to the right serial port.
$ sudo cu -l /dev/ttyS0 -s 115200
/usr/bin/cu: open (/dev/ttyS0): Permission denied
/usr/bin/cu: /dev/ttyS0: Line in use
$ sudo su -
# cu -l /dev/ttyS0 -s 115200
/usr/bin/cu: open (/dev/ttyS1): Permission denied
/usr/bin/cu: /dev/ttyS1: Line in use
if i make user 'root' part of the mandatory group 'dialout', it doesn't
make any difference anymore whether i try this with an uid of 0 or not.
to rule things out, i made a polkit action definition for this. logs
confirmed the action definition worked. i tried the above scenarios with
polkit's pkexec. it didn't make any difference.
to rule things out, i tried making a pam exception for this
(capabilities), by adding some lines to /etc/security/group.conf and
creating /etc/pam.d/cu. it didn't make any difference, but i'm not sure
my pam configuration was entirely correct.
to rule things out, i started fiddling with /bin/stty (which shouldn't
be needed). it didn't make any difference. for the record:
$ sudo stty -a
speed 38400 baud; rows 43; columns 124; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 =
M-^?; swtch = M-^?; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc ixany imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke
$ sudo stty -g
6d02:5:4bf:8a3b:3:1c:7f:15:4:0:1:ff:11:13:1a:ff:12:f:17:16:ff:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
$ sudo stty -F /dev/ttyS0 speed
115200
apparently baudrate was set by cu.
$ strace -f -ff -o STRACE_CU cu -l /dev/ttyS0 -s 115200
Connected.
~.
Disconnected.
i was able to abort the terminal normally, with "~."...
$ ls STRACE_CU.*
STRACE_CU.3139
STRACE_CU.3140
$ cat STRACE_CU.*|grep EPERM
ioctl(3, TIOCSCTTY) = -1 EPERM (Operation not permitted)
full traces below...
$ cu -l /dev/ttyS0 -s 115200 --debug all
cu: fconn_open: Opening port /dev/ttyS0 (speed 115200)
cu: fconn_set: Changing setting to 0, 0, 2
Connected.
~.cu: Exit status 0
cu: fconn_close: Closing connection
-
-
-
ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: cu 1.07-20build2
ProcVersionSignature: Ubuntu 3.7.0-4.12~lp1085115v1-generic 3.7.0-rc7
Uname: Linux 3.7.0-4-generic i686
ApportVersion: 2.6.1-0ubuntu9
Architecture: i386
Date: Fri Dec 28 15:05:24 2012
InstallationDate: Installed on 2012-11-29 (28 days ago)
InstallationMedia: Xubuntu 12.10 "Quantal Quetzal" - Release i386 (20121017.1)
MarkForUpload: True
SourcePackage: uucp
UpgradeStatus: No upgrade log present (probably fresh install)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1094278
Title:
cu doesn't connect properly to a serial console
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/uucp/+bug/1094278/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
