| 2012-12-28 14:30:24 |
Koen Hendrix |
bug |
|
|
added bug |
| 2012-12-28 14:35:14 |
Koen Hendrix |
description |
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]
$ sudo dmesg|grep tty
[CODE][ 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]
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, 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]
$ sudo cat /proc/tty/driver/serial
[CODE]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]
$ sudo cat /etc/group|grep koen
[CODE]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]
$ sudo which cu
[CODE]/usr/bin/cu[/CODE]
$ 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.
$ 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]
$ 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]
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;
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]
$ 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]
$ sudo stty -F /dev/ttyS0 speed
[CODE]115200[/CODE]
apparently baudrate was set by cu.
$ strace -f -ff -o STRACE_CU cu -l /dev/ttyS0 -s 115200
[CODE]Connected.
~.
Disconnected.[/CODE]
i was able to abort the terminal normally, with "~."...
$ ls STRACE_CU.*
[CODE]STRACE_CU.3139
STRACE_CU.3140[/CODE]
$ cat STRACE_CU.*|grep EPERM
[CODE]ioctl(3, TIOCSCTTY) = -1 EPERM (Operation not permitted)[/CODE]
full traces attached as files!
$ cu -l /dev/ttyS0 -s 115200 --debug all
[CODE]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]
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) |
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.
$ 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) |
|
| 2012-12-28 14:35:49 |
Koen Hendrix |
description |
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.
$ 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) |
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 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) |
|
| 2012-12-28 18:14:38 |
Koen Hendrix |
bug |
|
|
added subscriber Kees Schoenmakers |
| 2012-12-29 21:49:21 |
Dave Gilbert |
bug |
|
|
added subscriber Dave Gilbert |
| 2012-12-31 22:06:08 |
Dave Gilbert |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336996 |
|
| 2012-12-31 22:06:08 |
Dave Gilbert |
bug task added |
|
uucp (Debian) |
|
| 2012-12-31 22:08:14 |
Dave Gilbert |
uucp (Ubuntu): importance |
Undecided |
Medium |
|
| 2012-12-31 22:08:14 |
Dave Gilbert |
uucp (Ubuntu): status |
New |
Triaged |
|
| 2012-12-31 22:16:29 |
Bug Watch Updater |
uucp (Debian): status |
Unknown |
New |
|
| 2012-12-31 22:49:30 |
Koen Hendrix |
removed subscriber Kees Schoenmakers |
|
|
|
| 2013-12-04 20:30:49 |
Michal Suchanek |
bug |
|
|
added subscriber Michal Suchanek |
| 2013-12-06 19:59:46 |
Michal Suchanek |
tags |
apport-bug i386 quantal |
apport-bug i386 patch quantal |
|
| 2017-09-28 11:30:16 |
Bug Watch Updater |
uucp (Debian): status |
New |
Fix Released |
|
