I'm new to the forum and please forgive for my non mother-tongue english (I'm writing from Italy)...

I'm trying to setup a Unielec U7621 board with an LTE module, and asking your suggestions for a problem I have using latest snapshot build (both downloaded and/or compiled by myself). I'm using latest snapshot because I need the latest patches for the LTE module below.

Everything is working out-of-the box (following instructions found on: https://openwrt.org/docs/guide-user/network/wan/wwan/3gdongle) if I put in an Huawei ME909u-521 mPCI module temporary removed from a laptop.

The ME909 is obsolete (and expensive), so I've acquired a SIMCOM SIM7600E-H module, and installed on the board following the documentation page:
https://openwrt.org/docs/guide-user/network/wan/wwan/ltedongle for setting up a QMI interface.

The SIM7600 was very promising: GPS, LTE, cheap, but...

The module is recognized by lsusb, and the proper interfaces are shown in /dev (including /dev/cdc-wdm0).

I'm able to correctly send AT commands via minicom on /dev/ttyUSB2 interface.

By means of luci I did the configuration, creating a new MWAN interface, but was unable to let the LTE connection run.

In detail, the uqmi command seems to be "stucked" in either automatic and manual invocation (after killing all the pending processes).

When from the console I try to send uqmi commands (e.g. uqmi -d /dev/cdc-wdm0 --get-data-status) the command hangs-up until I hit ^C, with no useful results (always ""Failed to connect to service").

I've tried to search for information but, apart from the qmi_wwan.c patches (alredy incorporated in the latest snapshot build) I found very little useful.

Is there someone able to correctly configure this SIMCOM 7600E-H module? Can you give me hints to point in the right direction?

Thanks in advance for your support,



I do have the same issue with development and stable build, I am using PCEngines APU3. I was thinking that we are hitting the issue (https://patchwork.kernel.org/patch/10427381/), Are you sure if this was fixed on latest snapshot/main?. Keep me posted I need to fix the same issue like what you are facing.

Yes, that is most likely the problem. The described symptoms match the issue fixed by that patch. And it does not look like it is applied to the v4.14 stable branch yet. It appears someone promised to follow up and forgot all about it.. No need to mention any names :wink:

Sorry about that. I've sent a request now

1 Like

Thanks a lot very quick response indeed. Any chance if we can get a patch to test it ? I have the board and modem with me. Can test with VoLTE sim network.

The patch is a simple cherry-pick of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/drivers/net/usb/qmi_wwan.c?id=102cd909635612c0be784a519651954a7924c786

1 Like

I used same modem in the past. And now switched to the Quectel EC25. Both of them running in serial mode, though, to avoid the QMI hassles.

The patch is already included in latest snapshot build and did not solve the problem I have, since no command sent with uqmi -d /dev/cdc-wdm0 --... is correctly executed. uqmi simply stuck until ^C is pressed...


Thanks for the suggestion, will try to find an online dealer for this module.


Right. I didn't check to see if this patch was added to OpenWrt, only the upstream stable kernel branches.

Checked now, and there is something weird here:

bjorn@canardo:/usr/local/src/lede$ git grep 1e0e
package/kernel/lantiq/ltq-ptm/src/ifxmips_ptm_fw_vr9.h: 0x403c0000, 0x00000000, 0x41e0e000, 0xcdc000f8, 0x46612000, 0x58380004, 0xce4000f8, 0x58380006,
target/linux/brcm2708/patches-4.14/950-0415-qmi_wwan-apply-SET_DTR-quirk-to-the-SIMCOM-shared-de.patch:-        {QMI_FIXED_INTF(0x1e0e, 0x9001, 5)},    /* SIMCom 7230E */
target/linux/brcm2708/patches-4.14/950-0415-qmi_wwan-apply-SET_DTR-quirk-to-the-SIMCOM-shared-de.patch:+        {QMI_QUIRK_SET_DTR(0x1e0e, 0x9001, 5)}, /* SIMCom 7100E, 7230E, 7600E ++ */

How come this patch was applied only to the brcm2708 target? That does not make any sense. And unless you are on brcm2708, then I guess you don't have it? I certainly hope so. Because if you're right, then I have no idea where to start digging.

Anyway, wrt patch inclusion in other targets: GregKH has now queued the patch for v4.9 and v4.14. So it should be included with the next kernel refresh.

I'm on rampis/7621 platform.
I'm going to manually apply the patch to the source code and try again.
Thanks for the hint, will let you know asap.


No way...
patch was already in the right place on my repository:


but behaviour is the same...

I think the issue is inside uqmi package, the usb driver should be ok...

I have checked it, looks like linux-4.14.9 has the patch already in openWRT. I am building it now. Let me try with new build and get back to you.

I am not sure if "target/linux" is the right path to patch! I tried to do the kernel patch on linux-4.14.9 it seems to be the fix is already there. So I have just fired a build as it is.

Again the same issue. I think Daniele is right..I will give up OpenWrt unless some one gives me a solution to make it work..

I did additional tests this morning.

I'm sure to have the patches applied, because I've modified the sources manually (qmi_wwan.c file under .../drivers/net/usb/).

My understanding is that UQMI module does not correctly support SIM7600, this because of:

  1. I see the cdc-wdm0 and ttyUSBx interfaces under /dev
  2. if i manually connect via minicom to /dev/ttyUSB2 interface, I can send AT Commands to the LTE modem, With AT commands I can verify that the modem is correctly registered on the LTE network.

So the patched USB driver is working correctly.

What is missing is the working UQMI module required to activate the network interface, but I'm not skilled enough to dig inside UQMI source code to uderstand why this is not happening.

Thanks Daniele. I think its time to give up OpenWRT. I will go vanilla Debian or any other stuff to make it working. Good byE OpenWRT :slight_smile:

The patch in question does not affect probing or network registration. It changes the /dev/cdc-wdmX device from appearing dead silent to actually work. So the behaviour you describe is stll consistent with the patch not being applied.

But if you say that it is applied, then I am sure it is. Still don't think l a bug in uqmi is a likely cause. Some sort of bad driver/firmware interaction is much more likely IMHO.

1 Like

Thank you bmork,

from my research I understand that working with QMI interfaces always require some "black magic" and the installation is not straightforward as expected.

Sad to say, it's time to give up also for me.

Buddy, don't give up. I got it working :slight_smile: bmork is 100% right. Now I have uqmi to work with my devices. I did nothing other than checking out the main and firing a custom build with qmi enabled on the menuconfig and bunch of other network drivers. Hurray it works now..

My modem is working fine :). I have issues with my UIM and connect command.

root@OpenWrt:/# uqmi -d /dev/cdc-wdm0 --wda-get-data-format                     
root@OpenWrt:/# uqmi -d /dev/cdc-wdm0   --get-pin-status                        
"Not supported"                                                                                                                          
root@OpenWrt:/#  uqmi -d /dev/cdc-wdm0 --get-serving-system                     
        "registration": "searching",                                            
        "plmn_mcc": 404,                                                        
        "plmn_mnc": 80,                                                         
        "plmn_description": "",                                                 
        "roaming": true                                                         

I have to figure out how to connect my modem with my network provider. Can you help me over there ?

Shouldn't be the same as I did? Checkout latest snapshot, build and run...
Do you mean you set your uqmi as embedded inside kernel <*> instead than compile as module ?
For the configuration I'm setting up a new interface MWAN by means of luci-protocol-qmi...

Thanks to let me know