5

I have multiple USB-to-serial converters. I need to access one of them in particular. I'm using a udev rule to give it a special name. I have rebooted since I last modified it.

SUBSYSTEM=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", NAME="serial", MODE="0666"

That vendor/product combination is unique among all of my usb devices.

$ ls -l /dev/serial
crw-rw-rw-. 1 root root 189, 133 Feb  8 23:57 /dev/serial
$ ls -l /dev/ttyUSB0
crw-rw----. 1 root dialout 188, 0 Feb  8 23:58 /dev/ttyUSB0

I'm using PuTTY to read them, and it works on /dev/ttyUSB0, but not on /dev/serial . The error still appears when I am running PuTTY as root.

The error message I receive

Unable to open connection to :
Unable to configure serial port

In case it matters, I'm running CentOS 6.

uname -a
Linux xxxxxx 2.6.32-279.22.1.el6.x86_64 #1 SMP Wed Feb 6 03:10:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

EDIT: WORKING

The following udev rule was what finally worked:

SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="COM1", MODE="0666"

Note that SUBSYSTEM is tty, not usb, NAME has been changed to SYMLINK+, and serial has been changed to COM1 (to not interfere with /dev/serial, as a commenter pointed out.)

Thanks for your help, guys!

10
  • Does the /dev/serial device get created? PuTTY is a userland application, it should just use whatever devices are available.
    – vonbrand
    Feb 9, 2013 at 14:51
  • I'm not sure what you mean. I posted an ls -l of /dev/serial. Is there some other command I should run to determine whether it got created?
    – Nick ODell
    Feb 9, 2013 at 19:52
  • 2
    Your /dev/serial is a different device than /dev/ttyUSB0... My udev man page here tells me that NAME is applicable only to network interfaces, other devices only get symlinks made to them (with the SYMLINK key). Perhaps you should change NAME for SYMLINK
    – vonbrand
    Feb 9, 2013 at 21:00
  • I initially had it as SYMLINK+="serial", but that didn't work so I changed it.
    – Nick ODell
    Feb 9, 2013 at 22:43
  • 1
    @Keith Couldn't get minicom to work. PuTTY worked without hassle. I really don't care how 'traditional' the tools I use are, as long as they work.
    – Nick ODell
    Feb 13, 2013 at 0:05

5 Answers 5

6
+50

You want your rule to pay attention to the tty subsystem, not the usb one.

SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="serial"

A USB device generates several udev events when you plug it in as the kernel recognizes more things about it. Since it's a USB device, it first engages the usb subsystem, which I think will create a raw USB device, which PuTTY can't use. A few steps later it will load the device's specific driver, and since this is a serial device, it will engage the tty subsystem, which creates a device file that PuTTY can use.

This rule will create a symlink to whichever /dev/ttyUSB* happens to be assigned to your device. Tested successfully with PuTTY on my own serial dongle.

Incidentally, for diagnostics I sometimes run the following rule, to get an idea of what the udev scripts are seeing:

RUN+="/home/me/bin/udev-diag .$kernel .$number .$devpath .$id .$parent .$root .$tempnode"

where udev-diag is essentially:

env >>/tmp/udev-events
echo "$@" >>/tmp/udev-events

For more general use, the udevmonitor program is also handy.

2
  • 1
    On a Debian-based system, the existing udev rules may already create a /dev/serial/* tree, which can conflict with this one. You can avoid this by choosing a different name for the symlink. I'm not sure if this is an issue on a CentOS system.
    – Jander
    Feb 11, 2013 at 22:19
  • Jander, you are correct. As soon as I rebooted with the new rule, I found that /dev/serial contained a directory, so I was stomping over that with my symlink.
    – Nick ODell
    Feb 11, 2013 at 22:37
0

Using Jander's rule, I was able to access my USB serial adapter... but only if running PuTTY as root.

Modifying the rule to specify different permissions allowed me to access it by any user.

I.E.

SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", MODE="0666", SYMLINK+="serial"
1
  • I'm using MODE 666 too. See the question.
    – Nick ODell
    Sep 30, 2014 at 2:49
0

The following udev rule was what finally worked:

SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="COM1", MODE="0666"

Note that SUBSYSTEM is tty, not usb, NAME has been changed to SYMLINK+, and serial has been changed to COM1 (to not interfere with /dev/serial, as a commenter pointed out.)

2
  • In the future, please just post an answer and improve it when necessary. Leaving old irrelevant stuff around in everybody face is just a time waster. If we need to, we can use the edit history to see what changed.
    – Anthon
    May 8, 2015 at 10:17
  • Im so sorry. I didn't update it. Thanks Anthon. Feb 12, 2017 at 22:58
0

For some reason, I never posted an answer to this, even after I got this working.

The following udev rule was what finally worked:

SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="COM1", MODE="0666"

Note that SUBSYSTEM is tty, not usb, NAME has been changed to SYMLINK+, and serial has been changed to COM1 (to not interfere with /dev/serial, as a commenter pointed out.)

Thanks for your help, guys!

0

Notice that the device is group-writable, by the group dialout.

$ ls -l /dev/ttyUSB0
**crw-rw----** 1 root **dialout** 188, 0 Feb  8 23:58 /dev/ttyUSB0

To fix this permissions issue, add yourself to the dialout group:

$ sudo adduser <username> dialout

Then restart the session

2
  • You can edit your posts.
    – phk
    Jan 24, 2017 at 21:07
  • Welcome to Unix.stackexchange! I recommend you take the tour. Jan 24, 2017 at 21:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.