usb id & cu id

What is the link between a USB device id such as /dev/ugen1.3 and the cu device id such /dev/cuaU0.2 which you can use to connect to it?

I can see a number of @ugen's in /dev which correspond to the output of lsusb(). I can also see cuaU2 cuaU2.init cuaU2.lock in dev but can't figure out how to communicate.

cu -l /dev/cuaU2* just says
/devcuaU2.0: No such file or directory
link down

The '*' is for the different combinations I've tried.

I have loaded the u3g(4) driver.
 
So you are getting this by pluggin in a USB to serial device, yes?
Unplug it, then do ls -ltr /dev | grep cuaU and see what is there. If nothing is plugged in you should see nothing.
Then plug it in and repeat the ls command. You should see one.
I'm not sure if there is any specify correlation between USB address (the ugen info) and specific unit number on the cuaU
device; devd configuration could probably set that up, but by default may not.
A quick test after plugging the adapter in, is do to something like "tip ucom1" Look at /etc/remote to see mapping between "ucom" and specific /dev/cuaU###. You may also need to be aware of baud rate (so tip ucom1 -115200 connects at 115200 instead of 9600).
There may also permissions on the /dev devices so do the tip command as root.

I've had "fun" with trying to get cu to work in the past, tip is quicker and easier for me.
 
Actually the serial device is a modem plugged into the motherboard so it's not that easily accessible.

Strangely ls -ltr /dev | grep cuaU didn't find anything
but ls -ltr /dev | grep cuau (lower case u) showed cuau2 cuau2.lock cuau2.init
 
Managed to run cu -l /dev/cuau2 and got:-
Connected
... but no further response '~.' doesn't get me out of the session...
 
Ok, that's a little different. I'm assuming BIOS shows the device available, enabled and dmesg also shows
something about uart### or cuau###?

You could still try the "tip" command, but use uart2 instead of ucom1.

I've used minicom or putty in the past to talk with modems.
I don't recall my Hayes AT command set, but make sure the modem is powered on and use tip uart1 to connect, then type in AT and hit return and see if you get anything.

Maybe some hints here:
 
Cu is quite hard to use if you don't have a US keyboard mapping. Minicom and Putty will be easier then.
 
Ok, that's a little different. I'm assuming BIOS shows the device available, enabled and dmesg also shows
something about uart### or cuau###?

Code:
uart2: <Intel AMT - KT Controller> port 0x50e0-0x50e7 mem 0xf252b000-0xf252bfff irq 19 at device 22.3 on pci0
uart2: Using 1 MSI message
 
  • Like
Reactions: mer
Actually the serial device is a modem plugged into the motherboard so it's not that easily accessible.

Strangely ls -ltr /dev | grep cuaU didn't find anything
but ls -ltr /dev | grep cuau (lower case u) showed cuau2 cuau2.lock cuau2.init
cuau{number} are uart's on your motherboard. cuaU{number} are used by umodem>ucom or uch>ucom drivers (which are USB ports).

So, if this is a USB device, then uppercase U devices should appear in the device directory.
 
So if there is no cuaU* does that mean I can't access the modem?

When booting it is identified as
Code:
ugen1.3: <Sierra Wireless Inc Sierra Wireless MC8355 - Gobi 3000(TM) Module> at usbus1

lsusb shows
Code:
Bus /dev/usb Device /dev/ugen1.3: ID 1199:9013 Sierra Wireless, Inc. Sierra Wireless Gobi 3000 Modem device (MC8355)
Bus /dev/usb Device /dev/ugen0.3: ID 04f2:b221 Chicony Electronics Co., Ltd integrated camera
Bus /dev/usb Device /dev/ugen0.2: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus /dev/usb Device /dev/ugen1.2: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus /dev/usb Device /dev/ugen1.1: ID 0000:0000
Bus /dev/usb Device /dev/ugen0.1: ID 0000:0000
 
Nope, cuaU is the device name for "USB to Serial Converters".
Your's is on the motherboard, so cuau is correct.
It could be something as simple as FreeBSD doesn't support the device, so maybe you need to try a different brand card.
 
What mark_j says is correct, see man ucom. However, when I plug in my USB-to-serial connector /dev/cuaU is missing too, whereas a ttyU0 shows up. This adapter used to work in the past. In /var/log/messages I also see webcamd is trying to get involved. Do we have a problem there?
 
If you don't have a camera on the system or plan on plugging in a USB one, "service webcamd stop" and see if that makes a difference.
ttyU0 should also work as the "device" in programs.
 
If you don't have a camera on the system or plan on plugging in a USB one, "service webcamd stop" and see if that makes a difference.
ttyU0 should also work as the "device" in programs.
I just did that. Stopped webcamd and plugged in the adapter:

May 9 12:39:38 garfield kernel: ugen0.5: <Prolific Technology Inc. USB-Serial Controller> at usbus0
May 9 12:39:38 garfield kernel: uplcom0 on uhub2
May 9 12:39:38 garfield kernel: uplcom0: <Prolific Technology Inc. USB-Serial Controller, class 0/0, rev 1.10/3.00, addr 5> on usbus0
May 9 12:39:38 garfield webcamd[96466]: webcamd: Cannot find USB device

Once plugged in, I have /dev/ttyU0, but no /dev/cuaUn. Webcamd still shows up, probably because of its devd rules. When I unplug the adapter /dev/ttyU0 disappears.

Strange. In the past I used this adapter to control a connected tape recorder. I know for sure it used to give me both /dev/cuaUn and /dev/ttyUn.
 
What mark_j says is correct, see man ucom. However, when I plug in my USB-to-serial connector /dev/cuaU is missing too, whereas a ttyU0 shows up. This adapter used to work in the past. In /var/log/messages I also see webcamd is trying to get involved. Do we have a problem there?
If you look down the bottom of ucom(4), you will note:
Code:
FILES
     /dev/ttyU*          for callin ports
     /dev/ttyU*.init
     /dev/ttyU*.lock  corresponding callin initial-state and lock-state    de-
              vices

     /dev/cuaU*          for callout ports
     /dev/cuaU*.init
     /dev/cuaU*.lock  corresponding callout initial-state and lock-state de-
              vices

The use of callin/callout ports is a historical kickback to the beginnings of UNIX.
So, basically, your device is being treated by the system as a modem awaiting a call. There's likely a match to something in /etc/ttys. Comment it out and unplug/plug the device.

Can you cat < /dev/ttyU0 and watch data come in from the device?
You probably want to post the dmesg. Also, what's your kldtstat output? Do you have some u3g device module active?
 
Nope, cuaU is the device name for "USB to Serial Converters".
Your's is on the motherboard, so cuau is correct.
It could be something as simple as FreeBSD doesn't support the device, so maybe you need to try a different brand card.
I did try another card, a Sierra AirPrime MC7710 but that wasn't even recognised while booting. I guess it doesn't appear on some Lenovo white list...
 
If you look down the bottom of ucom(4), you will note:
Code:
FILES
     /dev/ttyU*          for callin ports
     /dev/ttyU*.init
     /dev/ttyU*.lock  corresponding callin initial-state and lock-state    de-
              vices

     /dev/cuaU*          for callout ports
     /dev/cuaU*.init
     /dev/cuaU*.lock  corresponding callout initial-state and lock-state de-
              vices

The use of callin/callout ports is a historical kickback to the beginnings of UNIX.
So, basically, your device is being treated by the system as a modem awaiting a call. There's likely a match to something in /etc/ttys. Comment it out and unplug/plug the device.

Can you cat < /dev/ttyU0 and watch data come in from the device?
You probably want to post the dmesg. Also, what's your kldtstat output? Do you have some u3g device module active?
kldstat() shows the presence of u3g.ko.

I also see ttyu2 ttyu2.ini and ttyu2.lock - that's 'u' (lowercase) which match the cuau2* devices.

cat < /dev/ttyu2 doesn't do anything, it just seems to wait.

Is there any way to issue 'AT' commands like you do with an old fashioned modem?
 
Meanwhile things look different here. I am working on a fresh install of FBSD-13 on a new SSD, since the missing cuaU device I installed several ports and rebooted. When I plug the adapter back in now I get both /dev/cuaU0 and /dev/ttyU0. So the cuaU device I need to connect to a tape recorder is back. An installation glitch solved by a reboot, I suppose. I was a bit worried about the webcamd message, because I tweaked its code to get a DVB-stick to work. But that thing works too now. Looks like balanga is having a different problem.
 
Is there any way to issue 'AT' commands like you do with an old fashioned modem?
The only way is via a serial terminal.
I am worried that perhaps this modem was in a machine with Windows10 on it.
Windows10 will install (via Windows Update) a firmware onto Sierra modems.
It switches the modem to MBIM-only mode. This means no serial port available.
To recover from this snafu requires much kung-fu.

Here is what a regular Sierra MC7700 looks like.
Code:
cu -l /dev/cuaU0.3
Connected
at
OK
ati
Manufacturer: Sierra Wireless, Incorporated
Model: MC7700
Revision: SWI9200X_03.05.29.03ap r6485 CNSHZ-ED-XP0031 2014/12/02 17:53:15
IMEI: 0126XXXXXXXXXXX
IMEI SV: 23
FSN: CDC0183099710
3GPP Release 8
+GCAP: +CGSM,+DS,+ES

OK


Here shows the USB Composition my module is using:
Code:
AT!ENTERCND="A710"
OK

AT!UDUSBCOMP?
!UDUSBCOMP: 3

OK
So we have the managment code and we are using USB Composition 3


Here are the available USB Compositions:
Code:
AT!UDUSBCOMP=?
0  - HIP  DM    NMEA  AT    MDM1  MDM2  MDM3  MS  SUPPORTED
1  - HIP  DM    NMEA  AT    MDM1  MS              NOT SUPPORTED
2  - HIP  DM    NMEA  AT    NIC1  MS              SUPPORTED
3  - HIP  DM    NMEA  AT    MDM1  NIC1  MS        SUPPORTED
4  - HIP  DM    NMEA  AT    NIC1  NIC2  NIC3  MS  SUPPORTED
5  - HIP  DM    NMEA  AT    ECM1  MS              SUPPORTED
6  - DM   NMEA  AT    QMI                         NOT SUPPORTED
7  - DM   NMEA  AT    RMNET1 RMNET2 RMNET3        NOT SUPPORTED
8  - DM   NMEA  AT    MBIM                        NOT SUPPORTED
9  - MBIM                                         NOT SUPPORTED
10 - NMEA MBIM                                    NOT SUPPORTED
11 - DM   MBIM                                    NOT SUPPORTED
12 - DM   NMEA  MBIM                              NOT SUPPORTED
13 - Config1: comp6    Config2: comp8             NOT SUPPORTED
14 - Config1: comp6    Config2: comp9             NOT SUPPORTED
15 - Config1: comp6    Config2: comp10            NOT SUPPORTED
16 - Config1: comp6    Config2: comp11            NOT SUPPORTED
17 - Config1: comp6    Config2: comp12            NOT SUPPORTED
18 - Config1: comp7    Config2: comp8             NOT SUPPORTED
19 - Config1: comp7    Config2: comp9             NOT SUPPORTED
20 - Config1: comp7    Config2: comp10            NOT SUPPORTED
21 - Config1: comp7    Config2: comp11            NOT SUPPORTED
22 - Config1: comp7    Config2: comp12            NOT SUPPORTED

So as you can see USB Composition has the following intentefaces:
3 - HIP DM NMEA AT MDM1 NIC1 MS SUPPORTED

So I have:
HIP
DM (Management Port)
NMEA (GPS)
AT (SERIAL PROMPT)
MDM1
NIC1
MS

But notice USB Composition 9. This is the MBIM-Only composition that Microsoft switches the module to.

There is a way with Linux to bring back the AT Console.
Install modemmanager.
qmicli --dms-swi-set-usb-composition=3
 
Since I wasn't making any progress, and wasn't even sure if the modem worked, I tried a different one, a Sierra MC7710 but this wasn't even recognised by the system, probably not on the whitelist. Then I find another one, a Sierra MC8775 but that only had a single terminal so had no idea how to connect it. Finally I found a WWAN card to USB adapter and put the modem in there. Not sure if this makes a difference although it is much easier to disconnect it.

Just wondered if the different naming of devices, ie cuau0 and cuaU0 is related to the FreeBSD version being used. I still have a cuau2 cuau2.init and cuau2.lock even without the modem installed.
 
cuau2 is probably onboard serial port. Just because there are no connectors does not mean it is not available.
Look at UART2 as shown. It is COM3 and tied to Intel AMT and probably is Serial Over LAN.
So you have COM ports even if not accessible.
 
Back
Top