So, I went poking around at /dev/ttyS0 and /dev/ttyUSB0, trying to get some ham radio accessories working, and broke it. ttyS0 controls the radio transmission, and if I run cat /dev/ttyS0 as the normal user, the radio transmits.

However, if I run the modem software (FLdigi), which previously worked with the radio using ttys0, it doesn't work. When starting the program, there is a message in the log saying "failed serial port test." I'm in both "dialout" and "uucp" groups, so I think it should be working.

One thing I remember running is sudo chmod 777 /dev/ttyS0. I'm not sure what I should set that back to. Any ideas on why I can access it while the software I run can't, even though it's both from the same user?

  • (1) Are you sure the error message failed serial port test indicates inability to use the serial port? My guess is that is actually indicates that the software failed to interact with the radio using some bidirectional communication protocol.
    – Celada
    Commented Jan 16, 2016 at 21:03
  • 1
    (2) You make references in your question to both /dev/ttyS0 and to /dev/ttys0. Almost certainly, only the former is actually correct, and if you are using /dev/ttys0 instead of /dev/ttyS0 then that could obviously be the source of the problem.
    – Celada
    Commented Jan 16, 2016 at 21:04
  • The software uses t/dev/ttyS0. I fired up a different program that utilizes the same port, and it no longer works either. So it looks like something I changed regarding the port made it inaccessible for some reason. Commented Jan 16, 2016 at 22:21

1 Answer 1

  • Check whether no applications have the port open when you want to use it.

  • Check whether there are no messages in the kernel log (use dmesg).

  • Check what exactly is happening in your application - run it under strace which will report syscalls that the application makes. You probably want tu use something like:

    $ strace -f -s 512 -o /path/to/application.log.strace application ...

which will also strace children processes, log strings ap to their 512th byte and all that will end up in /path/to/application.log.strace, the ellipsis stands for possible arguments for application. You can also tell strace to attach to a running process identified by PID (-p argument). See the strace(1) man page for more information. Rather towards the end of the log you should be able to find a write() call that prints the error message. Chances are that relatively shortly before that will be an open() or write() (on the device file) that returned -1. That might give you some idea of what is the reason of the error.

As a side note regarding permissions: you don't want to use chmod 777, since that makes the file executable and that is never a good idea with anything else then executables and directories. For device files (depending on their nature) reasonable values are 0640 or 0660 which allows full access for root and either read or read-write access for group (of which the user in question should be a member to gain the permissions - in your case that is likely the dialout group you mention).

In most cases you also want to prepend a zero (e.g. chmod 0664 since that removes any suid bits, which usually is a good idea).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .