cu doesn't connect properly to a serial console

[Koen Hendrix]

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)

[Koen Hendrix (koen-hendrix)]

$ cat STRACE_CU.3139
execve("/usr/bin/cu", ["cu", "-l", "/dev/ttyS0", "-s", "115200"], [/* 50 vars */]) = 0
brk(0) = 0x88ca000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7790000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=72636, ...}) = 0
mmap2(NULL, 72636, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb777e000
close(4) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\226\1\0004\0\0\0"..., 512) = 512
fstat64(4, {st_mode=S_IFREG|0755, st_size=1730024, ...}) = 0
mmap2(NULL, 1743580, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0xb75d4000
mprotect(0xb7777000, 4096, PROT_NONE) = 0
mmap2(0xb7778000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x1a3) = 0xb7778000
mmap2(0xb777b000, 10972, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb777b000
close(4) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb75d3000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb75d3900, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7778000, 8192, PROT_READ) = 0
mprotect(0x806e000, 4096, PROT_READ) = 0
mprotect(0xb77b3000, 4096, PROT_READ) = 0
munmap(0xb777e000, 72636) = 0
brk(0) = 0x88ca000
brk(0x88eb000) = 0x88eb000
open("/etc/uucp/config", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=461, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb778f000
read(4, "#\n# config\tThis is the configura"..., 4096) = 461
read(4, "", 4096) = 0
close(4) = 0
munmap(0xb778f000, 4096) = 0
open("/etc/uucp/Sysfiles", O_RDONLY) = -1 ENOENT (No such file or directory)
getpid() = 3139
getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=4*1024}) = 0
close(3) = 0
close(4) = -1 EBADF (Bad file descriptor)
close(5) = -1 EBADF (Bad file descriptor)
close(6) = -1 EBADF (Bad file descriptor)
close(7) = -1 EBADF (Bad file descriptor)
close(8) = -1 EBADF (Bad file descriptor)
close(9) = -1 EBADF (Bad file descriptor)
close(10) = -1 EBADF (Bad file descriptor)
close(11) = -1 EBADF (Bad file descriptor)
close(12) = -1 EBADF (Bad file descriptor)
close(13) = -1 EBADF (Bad file descriptor)
close(14) ...

[Koen Hendrix (koen-hendrix)]

$ 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) = ?

[Koen Hendrix (koen-hendrix)]

for what it's worth: to make sure this wasn't a polkit thing, i made an action definition for this, and dropped it in /etc/polkit-1/actions:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN""http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd">
<policyconfig>
<action id="org.freedesktop.policykit.exec">
    <defaults>
      <allow_active>yes</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/cu</annotate>
    <annotate key="org.freedesktop.policykit.exec.argv1">-l /dev/ttyS0 -s 115200</annotate>
    <annotate key="org.freedesktop.policykit.imply >true</annotate>
    <annotate key="org.freedesktop.policykit.owner>unix-user:ummelum</annotate>
  </action>
</policyconfig>

i ran it...
$ exec /usr/bin/pkexec --user ummelum /usr/bin/cu -l /dev/ttyS0 -s 115200
but alas...

according to /var/log/auth.log, the policy worked:
Dec 1 22:51:54 iugo polkitd(authority=local): Operator of unix-session:/org/freedesktop/ConsoleKit/Session1 successfully authenticated as unix-user:ummelum to gain ONE-SHOT authorization for action org.freedesktop.policykit.exec for unix-process:5798:3872562 [bash] (owned by unix-user:ummelum)
Dec 1 22:51:54 iugo pkexec: pam_unix(polkit-1:session): session opened for user root by ummelum(uid=1000)
Dec 1 22:51:54 iugo pkexec: pam_ck_connector(polkit-1:session): cannot determine display-device
Dec 1 22:51:54 iugo pkexec[6047]: ummelum: Executing command [USER=root] [TTY=/dev/pts/0] [CWD=/home/ummelum] [COMMAND=/usr/bin/cu -l /dev/ttyS0 -s 115200]

so this isn't a polkit thing.

[Koen Hendrix (koen-hendrix)]

for what it's worth: i suspected this is restricted by pam's capabilities.

so i added a line to /etc/security/group.conf:
cu;*;ummelum;Al0000-2400;dialout

and created /etc/pam.d/cu:
session optional pam_permit.so

i used a login-shell and tried my serial console, but alas...

if i try with pkexec, from a login-shell, i get the following in /var/log/auth.log:
Dec 1 23:49:02 iugo polkitd(authority=local): Unregistered Authentication Agent for unix-process:914:1133 (system bus name :1.73, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)

but, i don't think my pam-configuration is correct.

[Koen Hendrix (koen-hendrix)]

the following bug report might be relevant: Bug #1087519

[Koen Hendrix (koen-hendrix)]

for what it's worth:

$ ls /etc/uucp
config sys

$ cat /etc/uucp/config|grep -Ev '#'
(nothing)

$ cat sys|grep -Ev '#'
protocol gvG
protocol-parameter G packet-size 1024
protocol-parameter G short-packets

[Koen Hendrix (koen-hendrix)]

from the target machine (openbsd):
$ sudo stty -a -f /dev/tty00
speed 115200 baud; 0 rows; 0 columns;
lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl
        -echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin
        -nokerninfo -extproc -xcase
iflags: -istrip -icrnl -inlcr -igncr -iuclc -ixon -ixoff -ixany -imaxbel
        -ignbrk -brkint -inpck -ignpar -parmrk
oflags: -opost onlcr -ocrnl -onocr -onlret -olcuc oxtabs -onoeot
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
        eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
        min = 1; quit = ^\; reprint = ^R; start = ^Q; status = <undef>;
        stop = ^S; susp = ^Z; time = 0; werase = ^W;

from my problematic host (xubuntu):
$ sudo stty -a -F /dev/ttyS0
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 1;
-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

[Koen Hendrix (koen-hendrix)]

$ sudo setserial -av /dev/ttyS0
/dev/ttyS0, Line 0, UART: 16550A, Port: 0x03f8, IRQ: 4
 Baud_base: 115200, close_delay: 50, divisor: 0
 closing_wait: 3000
 Flags: spd_normal skip_test

[Dave Gilbert (ubuntu-treblig)]

Hi Koen,
  To try and nail down whether this is cu or a kernel serial problem, have you tried:
    1) Using a different serial program - e.g. minicom ?
    2) use something simple like echo Hello > /dev/ttyS0

Dave

[Koen Hendrix (koen-hendrix)]

thanks for the input!

i suspect it's the kernel; i don't see why cu would be at fault - it has been working fine for decades.
my apologies for attaching a bug report to 'cu', but it's the only way to get attention to this...

anyway, i tried minicom. didn't work as a normal user, didn't work with sudo. fiddled with line settings, but alas...

$ sudo minicom -b 115200 -t vt220 -D /dev/ttyS0
(cu starts, but apparently no connection; terminal is apparently a vt102)
(the bar below says 'offline'; i need to set local echo manually if i want a display of my input)

$ minicom -b 115200 -t vt220 -D /dev/ttyS0
(cu starts, but apparently no connection; terminal is apparently a vt102)
(the bar below says 'offline'; i need to set local echo manually if i want a display of my input)

one thing that comes to mind: the target host doesn't do utf8; can this be a problem?

[Koen Hendrix (koen-hendrix)]

on the problematic xubuntu host, i tried...
$ echo TEST>/dev/ttyS0
and
$ sudo echo TEST>/dev/ttyS0

both gave me prompt again

while on the target host, i had...
$ sudo cat /dev/tty00
and
$ sudo hexdump /dev/tty00
and
$ sudo less -f /dev/tty00
and
$ sudo od /dev/tty00

didn't display anything...

one time, i got the following wit hexdump:
0000000 0000 0000 0000 0000 0000 0000 0000 0000
but i could not repeat this.

[Koen Hendrix (koen-hendrix)]

note: while i tried the above, the target host still had a getty on that port

[Dave Gilbert (ubuntu-treblig)]

Hi Koen,
  It would probably be worth retrying the things without the getty (might be worth checking there wasn't one on the xubuntu host as well!).

  Hmm odd; the echo is about the simplest thing to try. if retrying without the getty doesn't help; have you got a
serial breakout box, or a lead with pins 2/3 connected as a loopback? My normal first test to see if I can get serial going is with
something like minicom and just start typing, and put a loopback lead in, if I get the echo with the loopback lead but not without it then I know at least that end is working. I'd also normally do that test with all forms of handshaking etc disabled.

Dave

[Koen Hendrix (koen-hendrix)]

on the target host (openbsd), i disabled the getty:
$ sudo cat /etc/ttys|grep tty00
tty00 none unknown off
#tty00 "/usr/libexec/getty std.115200" vt220 on secure

on the xubuntu host, there was no getty on any ttyS:
$ sudo pstree -ac|grep getty
  |-getty -8 38400 tty4
  |-getty -8 38400 tty5
  |-getty -8 38400 tty2
  |-getty -8 38400 tty3
  |-getty -8 38400 tty6
  |-getty -8 38400 tty1
  | | |-grep --color=auto getty

on the target host, i have:
$ sudo od -t x1 /dev/tty00

on the xubuntu host, i'm trying to send:
$ sudo echo -n '1234567890'>/dev/ttyS0

i usually get nothing, except "0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00" followed by "*"; this only happens if i freshly started 'od' on the target host, and i try to send something twice. after that, the line stays dead. i can not provoke this in any other way, than starting 'od' and sending something.

i don't have a breakout box and i suck at soldering, but i will ask around.

thanks for your time!

[Koen Hendrix (koen-hendrix)]

the following might have been relevant: Bug #255200

[Koen Hendrix (koen-hendrix)]

to rule out anything related to permissions, i did:

$ sudo ls -al /dev/ttyS0
crw-rw---- 1 root dialout 4, 64 Dec 31 09:21 /dev/ttyS0
$ sudo chmod 0666 /dev/ttyS0
$ sudo chown koen:dialout /dev/ttyS0
$ sudo ls -al /dev/ttyS0
crw-rw-rw- 1 koen dialout 4, 64 Dec 31 10:15 /dev/ttyS0

which shouldn't make any difference, and didn't make any difference...

[Koen Hendrix (koen-hendrix)]

the differences in terminal setting between a working configuration (openbsd) and a non-working configuration (xubuntu) on the same hardware; only the differences are shown, similar flags are left out:

# openbsd
cchars: discard = ^O; dsusp = ^Y; status = <undef>; time = 0
cflags: -crtscts -mdmbuf
oflags: opost oxtabs -onoeot
lflags: icanon isig iexten echo echoe -altwerase -flusho -pendin -nokerninfo -extproc
iflags: -istrip icrnl ixon ixany imaxbel brkint

# xubuntu
cchars: line = 0; swtch = <undef>; flush = ^O; time = 1
cflags: crtscts
oflags: -opost -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
lflags: -isig -icanon -iexten -echo -echoe
iflags: -brkint istrip -icrnl -ixon -ixany -imaxbel -iutf8

[Koen Hendrix (koen-hendrix)]

so...
rts/cts flow control is different, and flow control is not based on a carrier detect;
we're missing a dsusp control character.
we don't strip to 7 bits; we map carriage return to newline on input: we enable start/stop output control; we allow any character to restart outut; we impose a limit on the characters in the input queue; we signal intr on break.
we post-process output; we expand tabs to spaces on output; we don't discard EOF's on output.
we're processing input in canonical mode, with a time of 0; we check against special control characters; we do extened control characters if possible; we echo input; an erase character visually deletes the former character; we don't do alternative word erase; we don't discard output; we don't pend input after switching modes; we assume the hardware is not processing terminal data.

[Koen Hendrix (koen-hendrix)]

so, i did...
$ sudo stty -F /dev/ttyS0 speed 115200
115200
$ sudo stty -F /dev/ttyS0 icanon
$ sudo stty -F /dev/ttyS0 isig
$ sudo stty -F /dev/ttyS0 iexten
$ sudo stty -F /dev/ttyS0 echo
$ sudo stty -F /dev/ttyS0 echoe
$ sudo stty -F /dev/ttyS0 -altwerase
stty: when specifying an output style, modes may not be set
$ sudo stty -F /dev/ttyS0 -pendin
stty: invalid argument `-pendin'
Try `stty --help' for more information.
$ sudo stty -F /dev/ttyS0 -istrip
$ sudo stty -F /dev/ttyS0 icrnl
$ sudo stty -F /dev/ttyS0 ixon
$ sudo stty -F /dev/ttyS0 ixany
$ sudo stty -F /dev/ttyS0 imaxbel
$ sudo stty -F /dev/ttyS0 brkint
$ sudo stty -F /dev/ttyS0 opost
$ sudo stty -F /dev/ttyS0 oxtabs
stty: invalid argument `oxtabs'
Try `stty --help' for more information.
$ sudo stty -F /dev/ttyS0 -onoeot
stty: invalid argument `-onoeot'
Try `stty --help' for more information.
$ sudo stty -F /dev/ttyS0 -crtscts
$ sudo stty -F /dev/ttyS0 -mdmbuf
stty: invalid argument `-mdmbuf'
Try `stty --help' for more information.
$ sudo stty -a -F /dev/ttyS0
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 1;
-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

[Koen Hendrix (koen-hendrix)]

why aren't any settings actually set by stty?! ?

let's try this without sudo...
$ stty -F /dev/ttyS0 speed 115200
115200
$ stty -F /dev/ttyS0 icanon
$ stty -F /dev/ttyS0 isig
$ stty -F /dev/ttyS0 iexten
$ stty -F /dev/ttyS0 echo
$ stty -F /dev/ttyS0 echoe
$ stty -F /dev/ttyS0 -istrip
$ stty -F /dev/ttyS0 icrnl
$ stty -F /dev/ttyS0 ixon
$ stty -F /dev/ttyS0 ixany
$ stty -F /dev/ttyS0 imaxbel
$ stty -F /dev/ttyS0 brkint
$ stty -F /dev/ttyS0 opost
$ stty -F /dev/ttyS0 -crtscts
$ stty -a -F /dev/ttyS0
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 1;
-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

that looks better!

[Koen Hendrix (koen-hendrix)]

but it still won't connect...

$ cu -l /dev/ttyS0 -s 115200 --nostop
Connected.
~.
Disconnected.
$ cu -l /dev/ttyS0 -s 115200 --nostop -e
Connected.
~.
Disconnected.
$ cu -l /dev/ttyS0 -s 115200 --nostop -o
Connected.
~.
Disconnected.
$ cu -l /dev/ttyS0 -s 115200 --nostop -eo
Connected.
~.
Disconnected.
$ cu -l /dev/ttyS0 -s 115200
Connected.
~.
Disconnected.
$ cu -l /dev/ttyS0 -s 115200 -e
Connected.
~.
Disconnected.
$ cu -l /dev/ttyS0 -s 115200 -o
Connected.
~.
Disconnected.
$ cu -l /dev/ttyS0 -s 115200 -eo
Connected.
~.
Disconnected.

[Koen Hendrix (koen-hendrix)]

spot the difference!

# while booted in openbsd, on the same hardware, this always works
speed 115200 baud; 0 rows; 0 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
 -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
 -extproc -xcase
iflags: -istrip icrnl -inlcr -igncr -iuclc ixon -ixoff ixany imaxbel
 -ignbrk brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl -onocr -onlret -olcuc oxtabs -onoeot
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
 eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
 min = 1; quit = ^\; reprint = ^R; start = ^Q; status = <undef>;
 stop = ^S; susp = ^Z; time = 0; werase = ^W;

# while booted in xubuntu, on the same hardware, this never works
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 1;
-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

now, i could try setting a whole bunch of flags manually while trying to connect with cu, but i'm getting fed up with this... maybe later.

[Koen Hendrix (koen-hendrix)]

after reading Bug #577433, i booted with acpi=off and tried, but it didn't make any difference...

[Koen Hendrix (koen-hendrix)]

for what it's worth: the cable is a standard 9-pin crossover serial (DB-9)...

[Dave Gilbert (ubuntu-treblig)]

Hmm.
Well we still don't know if the problem is cu or anything else. I doubt it's anything complex with acpi etc.

For perms just do a simple chmod a+rw /dev/ttyS* (as long as you are happy with that and to fix it later and it's a single user system of course!).

OK, 1st question - are you sure you're on the right serial port? Is it really /dev/ttyS0?
If it is,
Then minicom -D /dev/ttyS0

then ctrl-a O and go to serial port setup, check the device, and make sure it's at 115k2 8n1, disable both hardware and software flow control

From the BSD box I'd then do a simple echo hello > /dev/ttyWHATEVER (whatever bsd calls it) and see if the minicom sees it.
If that fials I'd try enabling the getty on the BSD box and see if you see anything on the lInux box.

[Koen Hendrix (koen-hendrix)]

minicom sees the incoming hello...

[Koen Hendrix (koen-hendrix)]

so this works in minicom, if i disable hardware and software flow control...

i put everything back as it should be: permissions are back to normal, target host has a getty...
i try setting correct parameters (speed, no software flow control, no hardware flow control):

$ stty -a -F /dev/ttyS0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; 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
$ stty -F /dev/ttyS0 -crtscts
$ stty -F /dev/ttyS0 -ixon
$ stty -F /dev/ttyS0 speed 115200
9600
$ stty -F /dev/ttyS0 speed 115200
115200
$ cu -l /dev/ttyS0 -s 115200 --nostop --parity=none
Connected.
~.
^C^C^C
Disconnected.
$ stty -a -F /dev/ttyS0
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 1;
-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

apparently the flag for hardware flow control is back...

$ stty -F /dev/ttyS0 -crtscts
$ stty -F /dev/ttyS0 -ixon
$ stty -F /dev/ttyS0 speed 115200
115200
$ stty -a -F /dev/ttyS0
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 1;
-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

apparently they were set, so cu changes these?

anyway, enough for tonight :)

thanks for the pointers & happy new year's eve!

[Koen Hendrix (koen-hendrix)]

to be clear: my serial line works fine in minicom (i can access the remote host, everything works as it should), but not with cu...

[Koen Hendrix (koen-hendrix)]

and this seems to be a very well known problem, that goes back a decade:
http://www.google.be/search?hl=en&as_q=%22cu%22+%22crtscts

[Koen Hendrix (koen-hendrix)]

as far as i am concerned, this bugreport can be closed; apparently this was already a bug in 1995, and it has never been fixed (http://web.archiveorange.com/archive/v/iBpRaJf4WODgPva7sywW)

[Koen Hendrix (koen-hendrix)]

from the manual of cu:

"BUGS
       This program does not work very well."

:)

i would love to know a workaround though; setting the flag manually with stty, while cu has a connection, is apparently not possible...

[Dave Gilbert (ubuntu-treblig)]

Hi Koen,
  Nicely found; I think the bug should stay open - I don't see a fix for it!

Can you try (the apparently unrelated) fix at:
https://bugs.launchpad.net/ubuntu/+source/uucp/+bug/584787

it's just creating a config file, so it should be easy to try. Ah, and I've found an
ancient debian bug that's the same thing. I can link those together.

[Dave Gilbert (ubuntu-treblig)]

Triaged: Seems to be the same as the debian bug filed in '05, and looks possible the patch linked to from NetBSD in '01 might fix it?!

[Koen Hendrix (koen-hendrix)]

https://bugs.launchpad.net/ubuntu/+source/uucp/+bug/584787 : this actually works...

$ ls /etc/uucp
total 28
drwxr-xr-x 2 root root 4096 Dec 31 23:27 .
drwxr-xr-x 147 root root 12288 Dec 31 22:19 ..
-rw-r--r-- 1 root uucp 461 Oct 9 01:24 config
-rw-r--r-- 1 root root 86 Dec 31 23:27 port
-rw-r--r-- 1 root uucp 1436 Oct 9 01:24 sys

$ cat /etc/uucp/port
#
# Description for the TCP port - pretty trivial. DON'T DELETE.
#
port TCP
type tcp

$ stty -F /dev/ttyS0 -crtscts
$ stty -F /dev/ttyS0 -ixon
$ stty -F /dev/ttyS0 speed 115200
115200
$ cu -l /dev/ttyS0 -s 115200 --nostop --parity=none
Connected.

OpenBSD/i386 (x.x.xx) (tty00)

login:

[Koen Hendrix (koen-hendrix)]

thank you!

[Dave Gilbert (ubuntu-treblig)]

Huh ok, I don't quite see the relation between 584787's fix and what you're seeing; but hohum!

[Koen Hendrix (koen-hendrix)]

me neither, but if i rename the /etc/uucp/port file, it doesn't work anymore.

do you want an strace of a working example?

[Dave Gilbert (ubuntu-treblig)]

No, that's ok; I've added a comment to the debian bug, and I probably won't do anything else with it; I've marked the bug
as triaged and added comemnts to the others - I suspect the right thing is to add both fixes, although it probably needs someone with some time to grope around the cu code and try some experiements to find out the real underlying cause.

[Koen Hendrix (koen-hendrix)]

i've glanced at the code: in case of TCP, hardware flow control is not set explicitely (in other cases, it is set).

[Michal Suchanek (hramrach)]

patch http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;filename=flow.patch;att=1;bug=336996

[Gumuiyul (gumuiyul)]

i have hard time of the issue.
i tried with many way including which figured out above.
after the patch but cu tells following,
./cu: mkdir (/usr/spool): Permission denied
./cu: /dev/ttyS0: Line in use

for the patch, i download uucp 1.07 source from http://airs.com/ian/uucp.html
and fixed sources pointed and compiled successfully.
i have tried on many way such as changing owner or group with uucp, dialout or root.
but same result.

It works good with using usb to serial converter.
but not for the serial cable on serial card(for me, System base single port PCI card).
I have the success only under windows Teraterm program.

I desire to work with cu on linux as soon as.

[Michal Suchanek (hramrach)]

There are two issues here:

cu randomly identifies the serial connection as dialin (nortscts) ot dialout (rtscts). I don't care about that distinction being broken. I fix that with the patch.

The other problem is 'line in use' which is caused by running cu as root. The permission issues are discussed above. You need to add yourself to whatever group cu is owned by and run as non-root user and/or change the permissions to make the device nodes owned by whatever is cu suid to.

[Conor O'Gorman (7-i-g)]

This used to work fine. I thought it was a bug in the pl2303 driver, but it's definitly this issue. Look at stty output while cu running, shows rtscts enabled. After adding /etc/uucp/port file, with tcp options, cu works fine, rtscts disabled.

[Koen Hendrix (koen-hendrix)]

neat confirmation - it's 2015, and this bug is from 1995. Seemingly no-one has had a need for a serial line in the last two decades :)