Huawei USB 3G Modems & tty numbering

I have a Huawei E353 modem which I'm using with a Raspberry Pi.

When I plug it in, I get three TTYs - ttyUSB0, ttyUSB1 and ttyUSB2.

But sometimes the modem interface (where you can issue Hayes-type AT commands) is on ttyUSB0 and sometimes it's on ttyUSB1.

I can't spot any common factor that makes the difference. And I'm not certain, but it does seem that it always does the same thing on the same Pi (or maybe the same dongle - I've got several of each and haven't had a chance to try different combinations too much).

Can anyone suggest what influences the tty numbering?

Tom

Posted 2017-04-07T17:39:34.167

Reputation: 315

Answers

All device numbering (harddisk, tty, whatever) has to be considered unreliable and not consistent accress boots, because it can happen in random order.

Look at lsusb and dmesg to find out the details of how the tty's get created, then write apropriate udev rules to make symlinks with constant names which can be relied on.

Edit:

Yes, I understood perfectly that this is one device handled by a single driver, which produces three tty's. You can't distinguish them in the output of lsusb (but you can see the vendor/device id, which you'll need to identify what's going on in dmesg), but I'm pretty sure you can find distinguishing udev attributes.

If there's nothing at all in dmesg (unlikely), use

udevadm info -a -p  $(udevadm info -q path -n /dev/ttyUSB0)

to walk up the device path and see attributes, and

udevadm monitor --udev --property

to get an idea what udev thinks it's doing when you plug the device in.

dirkt

Posted 2017-04-07T17:39:34.167

Reputation: 11 627

This may be incorrect depending on your distribution. – davidgo – 2017-04-08T18:49:00.150

@davidgo: I still have to see a non-ancient distribution where it is incorrect. Care to elaborate? At least for any distribution using udev, it is not incorrect. – dirkt – 2017-04-08T18:56:29.467

Sorry. The first line of your post put me off - because a fair few devices are coded by modern OS's to get fixed addresses (based on udev) at runtime - Ethernet springs to mind for a start, but also drives addressed by uuid or partition name and many others. Your solution to craft udev rules is spot on though. – davidgo – 2017-04-08T19:05:12.817

@davidgo: And note that even new style network interface names don't always work reliably - there are a few questions on stackexchange relating to that. So, just don't rely on them if you for some reason need to identify a particular device. – dirkt – 2017-04-08T19:09:52.863

As for the other answer, you seem to have missed the point. These are not separate devices but one USB device handled by one driver (huawei_cdc_ncm) that presents three ttys. I'm not sure how to distinguish the ttys in the output of lsusb - especially since it seems the device doesn't present a standard usbserial interface (all the interfaces are either USB Mass Storage class or class 255 - Vendor Specific). – Tom – 2017-04-10T10:18:06.623

The problem you are having is not unique to Huawei devices (so you might get a better response if you remove that from your title).

The issue has to do with device detection and what the system thinks is already installed. The solution is to craft appropriate UDEV rules to ensure that the device is always recognised as a particular piece of hardware and assigned the same interface.

The specifics will vary slightly by distribution, but it typically means using lsusb to find unique attributes for the device, then coding a line to match those attributes in udev config files. Google is your friend here - googling udev try rules [distribution] should give you the specifics you need.

davidgo

Posted 2017-04-07T17:39:34.167

Reputation: 49 152

I think you've missed the point here. I know that when I plug in a USB tty device the numbering will be unreliable. But the point here is that these are three ttys for the same USB device. lsusb doesn't show them up as separate devices with separate IDs. I'm not quite sure how to distinguish them through udev. – Tom – 2017-04-10T10:04:11.493