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?


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.

  • 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 Apr 10 '17 at 10:04

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.


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.

  • This may be incorrect depending on your distribution. – davidgo Apr 8 '17 at 18:49
  • @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 Apr 8 '17 at 18:56
  • 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 Apr 8 '17 at 19:05
  • @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 Apr 8 '17 at 19:09
  • 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 Apr 10 '17 at 10:18

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.