Accessing serial port via USB adapter

balanga

Daemon

Thanks: 95
Messages: 2,339

#1
I have a USB/RS232 adapter which lsusb recognises as an HL-340 USB-Serial adapter.

How do I find out the name of the port for access?

When I insert the adapter /dev/cuaU0 appears, so I guess that must the port to use, but when I run minicom and setup /dev/cuaU0 as the serial device, I get a msg saying 'Cannot open /dev/cuaU0'.

Can anyone explain why?
 

SirDice

Administrator
Staff member
Administrator
Moderator

Thanks: 6,618
Messages: 28,160

#2
The simplest way to figure this out is to unplug the device, run tail -f /var/log/messages and plug it in. You should see new messages appearing detecting (or not) the device.
 

Lamia

Active Member

Thanks: 29
Messages: 173

#3
The simplest way to figure this out is to unplug the device, run tail -f /var/log/messages and plug it in. You should see new messages appearing detecting (or not) the device.
Another way is for you to plug in the adapter and run "ls -la /dev/". You should then unplug the adapter and rerun the command. All things being equal, the correct representation of the adapter will be the omitted value on comparing the results of the command.

For my minicom, it has always been "/dev/ttyUSB0".
 

p3rj

Member

Thanks: 24
Messages: 44

#4
Have you tried to use sudo? I cannot run cu without. (There's probably a better way, but for the few occasions where I need the adapter, using sudo seemed sufficient to me.)
 

aragats

Aspiring Daemon

Thanks: 372
Messages: 942

#5
For my minicom, it has always been "/dev/ttyUSB0".
That is Linux naming, not FreeBSD.

In FreeBSD you will have the following device nodes:
Code:
$ ll /dev/*U0*
crw-rw----  1 uucp  dialer     0xbc Mar  1 09:54 /dev/cuaU0
crw-rw----  1 uucp  dialer     0xc5 Mar  1 09:54 /dev/cuaU0.init
crw-rw----  1 uucp  dialer     0xc6 Mar  1 09:54 /dev/cuaU0.lock
crw-rw----  1 root  operator   0xb9 Mar  1 09:54 /dev/ttyU0
crw-rw----  1 root  operator   0xba Mar  1 09:54 /dev/ttyU0.init
crw-rw----  1 root  operator   0xbb Mar  1 09:54 /dev/ttyU0.lock
I use /dev/ttyUx with screen(1). I guess, nowadays there is no principal difference between cuaX and ttyX nodes, you can use either one for serial console.
 

ralphbsz

Daemon

Thanks: 769
Messages: 1,299

#6
... a msg saying 'Cannot open /dev/cuaU0'.
Very likely permission problem. Try the same operation as root. If it works, check the ownership and permissions of /dev/cuaUxx. If it is wrong, then it gets gnarly. As a quick hack, you could just do a chmod a+rw /dev/cuaU*. Two problems with this approach: First, it is insecure, now everyone logged into the machine can use this device. But if you know that you are the only person to ever log in, this may not matter. Slightly better variant is to change the ownership of the device to a different user or different group, but that requires more thinking and typing. Second, the /dev/cuaUxx device will vanish if you unplug the USB device, and be recreated when you plug it back in, and the new device (which will have the same name!) will have forgotten that you changed the permissions (or ownership).

There is a clean solution: Somewhere there is a config file that specifies the desired ownership and permissions when new devices are created. I think in FreeBSD this is handled separately for USB devices, but I'm not sure, and I don't have time this morning to do the hunting and gathering to find out. I had to do this a few months ago on Linux with systemd for work, and there it worked well and quickly, because the required config file was easy to find. Please do some google searches, and search this forum and the FreeBSD handbook, and you'll probably find it pretty quickly yourself.

EDIT: See aragats' post below, with the correct answer.
 

aragats

Aspiring Daemon

Thanks: 372
Messages: 942

#7
Somewhere there is a config file that specifies the desired ownership and permissions when new devices are created. I think in FreeBSD this is handled separately for USB devices, but I'm not sure, and I don't have time this morning to do the hunting and gathering to find out.
I have in /etc/devfs.conf:
Code:
....
perm    'ttyU*' 0660
and in /etc/devfs.rules:
Code:
[localrules=5]
....
add path 'ttyU*' mode 0660 group operator
So, you can do similar things for cuaU*.

EDIT: I guess, the first one (in /etc/devfs.conf) is not needed, it's in the rules anyway.
 
Top