3g/4g USB dongle not showing up

Hardware Questions and Recommendations
1

[sorry, this post had more links but I had to remove then because as a newbie I'm forbidden of having more than two links in a post]

My device is the TL-MR3020 v1.
My USB dongle is the Olicard 500.

Does it work?

On an Ubuntu PC I followed these steps:

  1. notes.rioastamal.net/2014/05/ubuntu-linux-switching-usb-modem-to-serial-manually.html to make the /dev/ttyUSB* devices show up
  2. wiki.debian.org/Modem/3G to further configure the connection
    and it worked.

What I did
I've tried these steps first with OpenWrt 15.*, then 17.01.5 then 17.01.6, without any difference in the result:

  • I start by following the tutorial at /docs/guide-user/network/wan/wwan/3gdongle

The tutorial tells me to look for the dmesg output, it looks like this:

after installing comgt kmod-usb-serial kmod-usb-serial-option kmod-usb-serial-wwan usb-modeswitch
dongle not plugged yet

[  362.462026] usbcore: registered new interface driver usbserial
[  362.466672] usbcore: registered new interface driver usbserial_generic
[  362.473056] usbserial: USB Serial support registered for generic
[  362.707206] usbcore: registered new interface driver option
[  362.711467] usbserial: USB Serial support registered for GSM modem (1-port)


dongle plugged

[  413.064115] usb 1-1: new high-speed USB device number 3 using ehci-platform

There's no mention of the dongle being recognized as a CD-ROM device or anything like that, but still nothing shows up in the /dev/ list:

root@LEDE:~# ls /dev/
bus                 mtd3                null                ttyS13
console             mtd3ro              port                ttyS14
cpu_dma_latency     mtd4                ppp                 ttyS15
full                mtd4ro              ptmx                ttyS2
hwrng               mtd5                pts                 ttyS3
kmsg                mtd5ro              random              ttyS4
log                 mtdblock0           shm                 ttyS5
memory_bandwidth    mtdblock1           tty                 ttyS6
mtd0                mtdblock2           ttyATH0             ttyS7
mtd0ro              mtdblock3           ttyS0               ttyS8
mtd1                mtdblock4           ttyS1               ttyS9
mtd1ro              mtdblock5           ttyS10              urandom
mtd2                network_latency     ttyS11              watchdog
mtd2ro              network_throughput  ttyS12              zero

The tutorial says something about usb-modeswitch, but I don't know if that is relevant to my case. Anyway, I don't have the /etc/usb_modeswitch.d/ directory nor the usb-modeswitch command. I only have usbmode and usbmode -l doesn't output anything.

I tried the echo 'idVendor idProduct' > /sys/bus/usb-serial/drivers/option1/new_id, but that didn't yield any result. I've used 2020 2030, 0x2020 0x2030, 2020 2030 ff as the values here, but the result was always the same. I've taken these ids from /sys/bus/usb/devices/1-1/idVendor and /sys/bus/usb/devices/1-1/idProduct (and these are the same numbers I used on Ubuntu with success).

There's also a /sys/bus/usb/devices/usb1/ directory which is created when I plug the dongle, and it has different idVendor and idProduct. I also tried using these without success. usbmode -s 2020:2030 too, gives me nothing. Not even an error, no output, nothing appears on dmesg or logread.

Is there are any help for my case?

2

The Olivetti Olicard 500 is supposed to use 0b3c:f017 as device ID when unswitched, and 0b3c:c00b after switching. It is a standard QMI device supported by default by the option and qmi_wwan driver, so there should be absolutely no need to mess with any manual driver support. It is switched using a SCSI eject as described, so you can do that instead of using modeswitch if you really want to do it more difficult. But then you'll obviously have to install the usb-storage driver and the eject utility instead, so I don't understand the attraction.

If you want it to work, then
a) Use a recent OpenWrt release.
b) Follow the OpenWrt guides:

Do not follow any Ubuntu guides. I am tempted to say "ever" here :wink:

2 Likes
3

Oh, right. Thank you very much for knowing about Olicard 500. I was just following this other tutorial because I didn't know anything about it. I'll try stuff with qmi, then.

(The Ubuntu guide was a guide I followed on Ubuntu, not OpenWrt. I just pasted it here because I imagined that the fact that it worked under Ubuntu could give more information about the device.)

4

Ok, I was wrong. actually what I have is an Olicard 600.

I don't know what these mean, but I see entries here for various Olicards, but not to the 600. Does that mean I'm doomed?

After rebuilding the OpenWrt image so I could have the proper drivers preinstalled without taking my entire flash space I still didn't get anything recognized and no /dev/cdc_wdm_etc entries.

I've tried echoing my two idVendor:idProduct combinations to /sys/bus/usb/drivers/cdc_wdm/new_id and got cdc_wdm: probe of 1-1:1.0 failed with error -22.

5

Then I decided to go the other way and try the modeswitch path (I'm thinking that maybe byfirst making my device an SCSI and then ejecting and manually assigning to usb-serial it will work, but that sounds stupid).

Anyway, by just having an image with kmod-usb-storage my dongle was automatically recognized as a SCSI device and assigned to /dev/sda. I don't know what to do from there however, since there's no usb-modeswitch and usbmode -l doesn't list any device. sdparm or eject isn't available also.

6

No, you are not doomed. Anything can be fixed. We just need som details to figure out exactly how.

First, please post the output of
cat /sys/kernel/debug/usb/devices
as mentioned on https://openwrt.org/docs/guide-user/network/wan/wwan/ltedongle . This will show the device ID and the configuration before modeswitch. Not all modems require modeswitching so it's always good to start exploring the options here, even if eject might work.

The /dev/sda device sounds like your modem might have a card reader. It can't be the fake CD expected as a mode switch device. So I guess eject won't do any good. Anyway, you need to installe the eject package to get the eject tool.

2 Likes
7

Ok, I managed to get OpenWrt 18.06.2 running here, and now the idVendor/idProduct have changed! That's very odd. But still I don't have anything on my /dev/.

I compiled my image with the non-optional packages from the tutorial you first linked: usb-modeswitch kmod-mii kmod-usb-net kmod-usb-wdm kmod-usb-net-qmi-wwan uqmi.

root@LEDE:~# cat /sys/kernel/debug/usb/devices

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480  MxCh= 1
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev= 4.09
S:  Manufacturer=Linux 4.9.152 ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=ehci-platform
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=05c6 ProdID=9008 Rev= 0.00
S:  Manufacturer=Qualcomm CDMA Technologies MSM
S:  Product=QHSUSB_DLOAD
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=  2mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

root@LEDE:~# dmesg | grep usb
[    3.764417] usbcore: registered new interface driver usbfs
[    3.768679] usbcore: registered new interface driver hub
[    3.773867] usbcore: registered new device driver usb
[    4.578384] usb 1-1: new high-speed USB device number 2 using ehci-platform
[   13.812393] usbcore: registered new interface driver cdc_wdm
[   14.067185] usbcore: registered new interface driver qmi_wwan

On a separate note, there is no package eject. Am I doing something wrong about it? (I did call opkg update before)(the same applies to sdparm, which I saw being used instead of eject in some places).

root@LEDE:~# opkg install eject
Unknown package 'eject'.
Collected errors:
 * opkg_install_cmd: Cannot install package eject.
8

Ouch. That does not look good if it is a consistent result. I believe this device ID is used by Qualcomm for one of their chip internal bootloader failsafe stages. This could mean that there is something wrong with the flash on the modem, casuing the modem bootloader to fail. There is no easy way to fix this. If you Google the device ID you'll find a number of recipes for rescuing phones with this problem. But you'll need a file with the next bootloader stage to do that, and I'm afraid we don't have that.

Does the modem now show up like this on other systems too? If not, then this could be a temporary issue related the OpenWrt system (e.g. power issues), or some software issue (e.g. a mode switch command that made the modem firmware crash).

You are right. Sorry for the confusion. I just looked at the current set of packages and didn't notice that this is a pretty recent addition, which isn't released yet:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=fcfb9e4ded51dbba4be33562b73c94f5fd8f1fdc

So you're right. There is no such package in any OpenWrt release.

But it won't help anyway as long as the modem is in that mode, since it only presents a single Qualcomm DLOAD function (as displayed by the Product string).

9

Oh, I thought the Qualcomm stuff was a good thing.

But anyway, I didn't notice the modem leds were turned off (it's in a different room). Later I unplugged it and plugged again, and now I see this:

root@LEDE:~# cat /sys/kernel/debug/usb/devices

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480  MxCh= 1
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev= 4.09
S:  Manufacturer=Linux 4.9.152 ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=ehci-platform
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  3 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=2020 ProdID=2030 Rev= 2.32
S:  Manufacturer=Mobile Connect
S:  Product=Mobile Connect
S:  SerialNumber=0123456789ABCDEF
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=125us

So back to the previous ids. Which leads us to... where?

On dmesg I keep seeing lines like:

[ 1142.369993] cdc_wdm: probe of 1-1:1.0 failed with error -22

whether after I unplug/plug the modem or if I try to echo something to /sys/bus/usb/drivers/cdc_wdm/new_id.

10

Good! Then it was only some temporary glitch.

The output is useful because it confirms the device ID in the unswitched state, and it shows that this modem requires mode switching. There is only one configuration with one function here: The mode switching storage function.

Yes, that won't work. You need to switch the device mode first.

And adding device IDs to the cdc_wdm driver is futile. It will never do anything useful, since that driver needs specific WDM descriptors when used as a standalone driver. It works with WDM class devices and nothing else. Except if used as a subdriver for qmi_wwan, cdc_mbim and huawei_cdc_ncm. But the device ID matching and probing is then done by the master driver.

Anyway, let's get back switching the device mode. Your device is not yet part of the default usb-modeswitch config, so you need to add it manually for now. Install usb-modeswitch. Create a temporary test config. Look at /etc/usb-mode.json for examples. The syntax is simple. Something like this should work, assuming eject is the correct command:

{
        "messages" : [ ],
        "devices" : {
                "2020:2030": {
                        "*": {
                                "mode": "StandardEject",
                                "msg": [ ]
                        }
                }
        }
}

Save that to for example /tmp/mymodem.json and run
usbmode -v -s -c /tmp/mymodem.json

If successful, then make a note of the resulting device ID and add it to your temporary config as target ID. Unplug and replug the modem, and verify that the configuration still works. If it does, then you may want to add it to the default /etc/usb-mode.json configuration. And please submit it upstream too, so it can be added to the default. The master for the usb-modeswitch data is found at

If "StandardEject" doesn't work, then your modem might need some other command instead. Look at other devices with similar IDs in the usb-modeswitch configuration and try those messages. It might be easier to do this testing directly in the /etc/usb-mode.json file, since it uses references by index into the messages table. Or simply add a copy of that table to your temporary test config and use the same index there.

1 Like
11

StandardEject didn't work. I then tried all the commands related to vendor 2020 and product 2030, got not result. Then I tried a bunch of random configs taken from other devices. What is the procedure people use to discover these commands? Trial and error with random commands?

Maybe I should try doing this on Ubuntu and see what happens? Do you have any recommendations in these directions?

By trying you mean editing the config JSON file, calling usbmode -s -v (assuming I'm editing /etc/usb-mode.json directly) and seeing if something appears on dmesg? Nothing ever appears on dmesg.

But this is odd. usbmode never returns anything. Despite complaining once about a malformed JSON it doesn't output anything ever. -v should mean verbose, right? It is completely silent. -l should list matching devices, right? My device is on the list, but usbmode -l doesn't output anything!

12

Wait, wait. As soon as I wrote the previous message I had the brilliant idea of checking my list of devices, and voilà:

root@LEDE:~# cat /sys/kernel/debug/usb/devices

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480  MxCh= 1
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev= 4.09
S:  Manufacturer=Linux 4.9.152 ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=ehci-platform
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=2020 ProdID=2031 Rev= 2.32
S:  Manufacturer=Mobile Connect
S:  Product=Mobile Connect
S:  SerialNumber=0123456789ABCDEF
C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E:  Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=125us

It has changed its id to 2031! What does that mean? I have no idea, but now that I changed its id in the usbmode file it appears in the list for usbmode -l.

I'm trying the commands again and still nothing works. Or maybe they do work but how am I going to know if they are working?

13

Wait again: should I be trying this with which packages installed? I'm trying to use the qmi stuff, not the usb-serial stuff. But apparently I need usb-serial, right?

14

Great! This means that your "target" device ID (for the usb-modswitch config) is 2020:2031.

You have 6 interfaces which each represents a separate function (guessing based on the umber of endpoints). The last one is a storage class, so that one is easy to figure out. Probably card reader?

The rest of the functions are all vendor specific (class ff), so they could be anything in theory. But if I am to guess, then I'd put a beer on something like:
0:QCDM
1:AT
2:AT
3:AT
4:QMI

Try adding the device to the option driver first. Install kmod-usb-serial-option and do

echo 2020 2031 >/sys/bus/usb-serial/drivers/option1/new_id

It should bind to all the 5 vendor specific interfaces, providing 5 /dev/ttyUSBx devices This doesn't imply that they work, or are serial functions at all. You still need to verify that. Use picocom or similar to test each of them. If I am correct then /dev/ttyUSB0 won't respond, although it is a serial function. It just speaks a different protocol. And if I am right about /dev/ttyUSB4 too, then that won't respond either. You should then try the qmi_wwan driver with it. To do that, you'll first have to unbind option using

echo '1-6:1.4' >/sys/bus/usb/drivers/option/unbind

and then install kmod-usb-net-qmi-wwan and add the device ID to it:
echo 2020 2031 >/sys/bus/usb/drivers/qmi_wwan/new_id

It should probe the free interface and create a wwan network device and a /dev/cdc-wdm0 device. This isn't proof of success though. You'll have to test it with uqmi to verify. Try something like
uqmi -d /dev/cdc-wdm0 --get-versions

Everything so far will only last until the next reboot, and this is obviously far too much hassle to repeat for every boot. But let us know how things go and we can add the device to those drivers by default. Then you won't have to do anything at all to make it work as soon as those changes make it back to OpenWrt

2 Likes
15

/dev/ttyUSB1 and /dev/ttyUSB2 responded to AT calls made with picocom. /dev/ttyUSB3 appears to be echoing my characters, but it's so broken I can't even exit picocom. The others don't respond.

I don't know how did you get that '1-6:1.4' from. Here I get a "No such device" error. Tried with '1-1:1.4' and others (1-1) should be an existing device, according to /sys/bus/usb/devices/. But that didn't work also. Anyway, I guess that doesn't matter.

I added my device to /etc/usb-mode.json and unplugged/plugged it again, then I got the usbmode thing done automatically. It appears as 2020:2031 with all the 6 interfaces and the following /dev/ entries appear:

root@LEDE:~# ls /dev/
bus                 memory_bandwidth    mtdblock0           random              ttyS3
cdc-wdm0            mtd0                mtdblock1           shm                 ttyS4
cdc-wdm1            mtd0ro              mtdblock2           tty                 ttyS5
cdc-wdm2            mtd1                mtdblock3           ttyATH0             ttyS6
cdc-wdm3            mtd1ro              mtdblock4           ttyS0               ttyS7
console             mtd2                mtdblock5           ttyS1               ttyS8
cpu_dma_latency     mtd2ro              network_latency     ttyS10              ttyS9
full                mtd3                network_throughput  ttyS11              ttyUSB0
gpiochip0           mtd3ro              null                ttyS12              urandom
gpiochip1           mtd4                port                ttyS13              watchdog
hwrng               mtd4ro              ppp                 ttyS14              zero
kmsg                mtd5                ptmx                ttyS15
log                 mtd5ro              pts                 ttyS2

In this scenario /dev/ttyUSB0 doesn't respond, nor the cdc devices 0-2, but /dev/cdc-wdm-3 does respond. I'm now going to follow the tutorial you linked to at the beginning.

It seems that once my device is added to /etc/usb-mode.json everything works automatically as long as the correct packages are installed, right? I'll see if I get this working and post a summary here later.

Is this the correct config for my /etc/usb-mode.json, right?

                "2020:2030": {                                                   
                        "*": {
                                "t_vendor": 2020,                                
                                "t_product": 2031,                               
                                "mode": "StandardEject",                         
                                "msg": [  ],                                     
                                "wait": 2                                        
                        }                                                        
                }

I'll also try to contribute to that enormous collection of device ids as you said.

16

OK, there are 4 /dev/cdc-wdmX devices because you have added the device to qmi_wwan without another driver like option being bound to the serial functions. So qmi_wwan has happily tried to use every interface as QMI, except interface 0 which is missing the required interrupt endpoint. The end result is that /dev/cdc-wdm3 is mapped to USB interface 4, which was the one I expected to be QMI.

I assume t /dev/cdc-wdm3 responded with a list of QMI subsystems?

This is great. I'll go ahead and submit the necessary patches for option and qmi_wwan so you don't have to go through hoops to get this running, eventually.

EDIT: I posted a summary of your findings to the usb_modeswitch forum as well, so you don't have to:
http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=3&t=2851

Please follow up with any corrections if necessary. Thanks for your help in improving Linux for everyone! This benefits more than just the OpenWrt users.

3 Likes
17

Everything is correct.

I was able to setup get the router running in an "automatic" mode by saving my /etc/usb-mode.json changes and adding sleep 20; echo 2020 2031 >/sys/bus/usb/drivers/qmi_wwan/new_id to rc.local (at least it worked the first three times I tested).

I wrote about my adventures here, maybe it will help someone in 2023: https://fiatjaf.alhur.es/3g-dongle.html

Thank you very much!

3 Likes
18

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.