How to prevent DTR on open for cdc_acm?

Question

I have an Arduino Uno attached over USB, using the cdc_acm driver. It is available at /dev/ttyACM0.

The convention for the Arduino's serial interface is for the DTR signal to be used for a reset signal—when using the integrated serial-to-USB adapter, the DTR/RTS/DSR/CTS signal; or, when using an RS-232 cable, pins 4 or 5 (and possibly 6 or 8) are wired to the RESET pin.

This reset avenue has the important advantage of being, if not truly out-of-band, at least very near-failsafe (due to being implemented via the always-out-of-band serial controller in conjunction with the not-normally-user-controllable watchdog circuit), and while it can be physically disabled (via wiring either a capacitor or a resistor, depending on the model, to the RESET pin), to do so completely ruins this important killswitch and all associated utility.

Unfortunately, it seems that, currently, Linux absolutely always sends this signal when any program attaches to an ACM device for any reason, and (unlike Windows,) provides no even-vaguely-known-reliable way to prevent this.

(Currently both -hupcl, "send a hangup signal when the last process closes the tty" and -clocal, "disable modem control signals" do not prevent this signal from being sent every time the device is opened.)

---

tl;dr: What do I need to do to access /dev/ttyACM0 without sending it a DTR/RTS/DSR/CTS signal (short of blocking the signal on the hardware level)?

Answer 1

When a userland process is opening a serial device like /dev/ttyS0 or /dev/ttyACM0, linux will raise the DTR/RTS lines by default, and will drop them when closing it.

It does that by calling a dtr_rts callback defined by the driver.

Unfortunately, there isn't yet any sysctl or similar which allows to disable this annoying behavior (of very little use nowadays), so the only thing that works is to remove that callback from the driver's tty_port_operations structure, and recompile the driver module.

You can do that for the cdc-acm driver by commenting out this line:

--- drivers/usb/class/cdc-acm.c~
+++ drivers/usb/class/cdc-acm.c
@@ -1063,7 +1063,7 @@
 }

 static const struct tty_port_operations acm_port_ops = {
-       .dtr_rts = acm_port_dtr_rts,
+       /* .dtr_rts = acm_port_dtr_rts, */
        .shutdown = acm_port_shutdown,
        .activate = acm_port_activate,
        .destruct = acm_port_destruct,

This will not prevent you from using the DTR/RTS lines via serial ioctls like TIOCMSET, TIOCMBIC, TIOCMBIS, which will be handled by the acm_tty_tiocmset(), etc callbacks from the acm_ops structure, as usual.

Similar hacks could be used with other drivers; I personally have used this with the PL2303 usb -> serial driver.

[The diff is informative; it will not apply directly because this site mangles tabs and whitespaces]

Answer 2

I think there is a nice workaround that solves the problem. Instead of reading data from the device /dev/ttyUSB0 or /dev/ttyACM0, it could be read from the named pipe, e.g. /tmp/arduino and the simple program (below) would be copying data from the device to pipe and holding the device open (thus avoiding setting DTR high). This also avoids dealing with all the difficulties of reading from the device. With the named pipe, tools like cat, less -f can be used or just any program with standard open + read without any need to issue ioctl commands to control tty. The program for copying the device to pipe would be running e.g. as upstart service and copying data from the device to the pipe (and perhaps producing some logs). The program has to take care of the SIGPIPE signal, to avoid being closed on closing any pipe reader process. The load on server would be negligible because of intentionally setting blocking on the input via fcntl. I have tested it and it seems to be working well. I am acutually trying to solve the same problem with interfacing Arduino. The nice side effect is that restart of Arduino can be done simply by restarting the upstart service whenever needed as it sets DTR high.

#include <unistd.h>
#include <string.h>
#include <signal.h>
#include <fcntl.h>

/* for simplicity, most error handling is ommited, make sure you add it before using in production code */
void ignore_signal(int sig)
{
        static struct sigaction _sigact;
        memset(&_sigact, 0, sizeof(_sigact));
        _sigact.sa_handler = SIG_IGN;
        sigaction(sig, &_sigact, NULL);
}

int main()
{
        ignore_signal(SIGPIPE);

        int flags;
        flags = fcntl(0, F_GETFL, 0) & ~O_NONBLOCK;
        fcntl(0, F_SETFL, flags);


        char c;
        int n;
        while(1)
        {
                n = read(0,&c,1);
                if(n!=1)
                {
                        sleep(1);
                }
                else
                {
                        write(1,&c,1); /* ignoring the case that return code = -1 and errno = EPIPE means that data from Arduino are lost whenever pipe is not read */
                        write(2,&c,1);
                }
        }
        return 0;
}

The shell script to start it would be (needs to be re-implemented as upstart service):

#!/bin/bash

DEV=/dev/ttyUSB0
PIPE=/tmp/arduino
LOG=/var/log/arduino.log

if test ! -p $PIPE
then
    rm -f $PIPE
    mkfifo $PIPE
fi

./my_dd <$DEV >$PIPE 2>>$LOG &
dd if=$PIPE of=/dev/null count=0 bs=1

I think logrotate file needs to use copytruncate, because the file is still open (I had no chance to test this):

/var/log/arduino.log {
  rotate 5
  daily
  compress
  missingok
  notifempty
  create 640 root root
  copytruncate
}

Additional note : Meanwhile I have realized that to avoid the broken pipe, it could probably be achieved with use of cat or dd in combination with trap command with parameter PIPE, that would be filtering the SIGPIPE signal too. The solution above works for me, so I was not experimenting with the trap command to achieve comparable results.