[SOLVED] Why CTRL+C won't work when using RS-232 on Linux?

Issue

First of all, I don't know if this should stay in SO or go to SU: you tell me. The solution might have to do with programming.

I am executing Linux on an embedded device and communicating with it using RS-232 @ 9600 bauds. Everything works fine using PuTTY on Windows: I have a shell and can type and execute commands.

The problem is: when I launch a command, I cannot CTRL+C. For example, when pinging some machine, ping goes into an infinite loop and I cannot stop it using CTRL+C. When at the Bash prompt, though, CTRL+C works and goes to the next line (so it is transmitted). I also noticed the terminal is showing ^C when I do CTRL+C while running a command. When connecting through Telnet, CTRL+C works fine anywhere.

I tried using PuTTY's "special command" break, but it doesn't work. I also tried different terminal emulators, same problem.

So I guess the problem is somehow kernel-related. Is there anything I could look into regarding this?

Edit: I am running BusyBox v1.13.2. The output of stty -a (RS-232) is:

speed 9600 baud; rows 24; columns 80;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <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
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

The output of stty -a (Telnet) is:

speed 38400 baud; rows 24; columns 80;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <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
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab3 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

I just noticed that if I do ls -la /bin, which is a long command to execute since the list is long, I cannot break by just issuing CTRL+C, but I can when keeping the keys down. It breaks after about one second. This doesn't work with ping, however.

In fact, if I do seq 1 1000 and then press CTRL+C, it seems like it skips many lines at one shot at some point:

93
94
95
^C6
897
898
899

Same thing happens with ls -la /bin:

lrwxrwxrwx    1 10042    2223            7 May  6  2012 dmesg -> busybox
lrwxrwxrwx    1 10042    2223            7 May  6  2012 dos2unix -> busybox
lrwxrwxrwx    1 10042    2223            7^C          7 May  6  2012 ipcrm -> busybox
lrwxrwxrwx    1 10042    2223            7 May  6  2012 ipcs -> busybox
lrwxrwxrwx    1 10042    2223            7 May  6  2012 iplink -> busybox

Solution

The serial port settings on the embedded device are likely either ignoring break characters, or not causing an interrupt on receipt of a break. You can change this by running the stty program from the device's shell (or startup scripts), or by writing a program using various ioctl() paramaters.

http://linux.die.net/man/1/stty

stty sane 

Might be the best bet. This sets up a bunch of "usual" settings. In constrast, if you do

stty raw 

In a shell window of a desktop linux, you will likely get the kind of ctrl-C prints-but-does-nothing behavior you are seeing on your embedded device.

Running stty without arguments may print out the current settings, which could be interesting - especially comparing the result on the serial vs telnet sessions.

---

Update: A web search on busybox and BRKINT found something likely relevant:

Date: Thu, 31 Jan 2002 13:34:34 -0800
From: Scott Anderson <scott_anderson at [removed]>
Cc: linuxppc-dev at lists.linuxppc.org
Subject: Re: why is tty->pgrp set to -1 for console?

>   What is the correct procedure to follow to get around this problem
> and get ctrl-c working on console?

It looks like everyone is taking a swing at this one, so I think I'll
join in.  First off, the easiest way I've found to track down why
ctrl-c doesn't work is to just run "ps -j".  For ctrl-c to work, you
need a controlling terminal (the TTY column) and a process group.  If
you have a '?' in the TTY column, ctrl-c won't work.  In the past I
have seen this happen because of this code in drivers/char/tty_io.c:
        if (device == SYSCONS_DEV) {
                struct console *c = console_drivers;
                while(c && !c->device)
                        c = c->next;
                if (!c)
                        return -ENODEV;
                device = c->device(c);
                filp->f_flags |= O_NONBLOCK; /* Don't let /dev/console block */
                noctty = 1;
        }
Note that O_NOCTTY (no controlling terminal) is forced on whenever
/dev/console is opened (noctty = 1).  Possible workarounds:
  1) Run getty on something other than /dev/console.  For example,
     if you console is on the first serial port, run getty on /dev/ttyS0.
     I believe this is the "correct" answer.
  2) You could also change getty to do a TIOCSCTTY ioctl explicitly after
     it has opened the terminal.
  3) You could remove the forcing of noctty on from tty_io.c

Answered By - Chris Stratton

Answer Checked By - Marilyn (WPSolving Volunteer)