Huawei E3372 with NCM

Installing kmod-usb-serial-option should make the ttyUSBx devices work without any additional hack.

Don't know about the crash. Difficult to guess where it happens.

Wrt the config: Did /dev/cdc-wdm0 work as an AT command management device in Fedora? IIRC, different Huawei firmwares beahve differently here. But if the /dev/ttyUSBx device works, then I guess this isn't important.

kmod-serial-option?

kmod-usb-serial-option................... Support for Option HSDPA modems

Use kmod-usb-serial-wwan, instead!

kmod-usb-serial-wwan..................... Support for GSM and CDMA modems

Mea culpa, @bmork was right!

This is misleading at best. That might have been the original meaning, but the option driver is now a multi-vendor generic fast USB serial driver. And it specifically supports the serial functions of most Huawei 3G and LTE modems.

That is pointless. Did you try this yourself? The usb-wwan module is only a support module with some shared functions for option, qcserial and ipw drivers. It supports no modems by itself. But the option driver depends on it, so it will be installed when you install it.

1 Like

You're right I don't have kmod-usb-serial-option installed, but it's too late to get a version corresponding to my kernel now, so I'll upgrade again tonight

In fedora the cdc-wdm0 device was unresponsive, same as openWRT,
the ttyUSBx devices existed by default and AT commands worked in minicom

I had already tried kmod-usb-serial-wwan, with no effect

OK, thanks for confirming. Then I think we can assume this is how this particular Huawei firmware works.

It can be a bit confusing, because you have to use the /dev/cdc-wdm0 on some Huawei modems. On most you can use either the /dev/cdc-wdm0 or the /dev/ttyUSBx devices. And yet another bunch is like yours where you have to use /dev/ttyUSBx.

Can confirm that kmod-usb-serial-option created the /dev/ttyUSB* devices correctly

[   15.101457] usb 1-1: new high-speed USB device number 2 using dwc2
[   16.009757] usb 1-1: USB disconnect, device number 2
[   17.085427] usb 1-1: new high-speed USB device number 3 using dwc2
[   17.526264] option 1-1:1.0: GSM modem (1-port) converter detected
[   17.531753] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
[   17.538876] option 1-1:1.1: GSM modem (1-port) converter detected
[   17.544661] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB1
[   17.782268] huawei_cdc_ncm 1-1:1.2: MAC-Address: 00:1e:10:1f:00:00
[   17.787178] huawei_cdc_ncm 1-1:1.2: setting rx_max = 16384
[   17.807194] huawei_cdc_ncm 1-1:1.2: NDP will be placed at end of frame for this device.
[   17.814369] huawei_cdc_ncm 1-1:1.2: cdc-wdm0: USB WDM device
[   17.822024] huawei_cdc_ncm 1-1:1.2 wwan0: register 'huawei_cdc_ncm' at usb-1e101000.ifxhcd-1, Huawei CDC NCM device, 00:1e:10:1f:00:00

# lsusb -tv
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
    |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=option, 480M
    |__ Port 1: Dev 3, If 1, Class=Vendor Specific Class, Driver=option, 480M
    |__ Port 1: Dev 3, If 2, Class=Vendor Specific Class, Driver=huawei_cdc_ncm, 480M
    |__ Port 1: Dev 3, If 3, Class=Mass Storage, Driver=, 480M
|__ Port 1: Dev 3, If 4, Class=Mass Storage, Driver=, 480M

I'm not sure if I require your "skipinit" patch, the gcom script seems fairly happy with my dongle

root@hh5a:~# ifup LTE
Thu Feb 22 22:21:11 2018 daemon.notice netifd: Interface 'LTE' is setting up now
root@hh5a:~# Thu Feb 22 22:21:14 2018 daemon.notice netifd: LTE (3939): sending -> AT
Thu Feb 22 22:21:14 2018 daemon.notice netifd: LTE (3939): sending -> ATZ
Thu Feb 22 22:21:15 2018 daemon.notice netifd: LTE (3939): sending -> ATQ0
Thu Feb 22 22:21:16 2018 daemon.notice netifd: LTE (3939): sending -> ATV1
Thu Feb 22 22:21:16 2018 daemon.notice netifd: LTE (3939): sending -> ATE1
Thu Feb 22 22:21:17 2018 daemon.notice netifd: LTE (3939): sending -> ATS0=0
Thu Feb 22 22:21:17 2018 daemon.notice netifd: LTE (3939): sending -> AT+CGDCONT=1,"IP","3internet"
Thu Feb 22 22:21:18 2018 daemon.notice netifd: LTE (3939): Configuring modem
Thu Feb 22 22:21:18 2018 daemon.notice netifd: LTE (3939): Setting mode
Thu Feb 22 22:21:19 2018 daemon.notice netifd: LTE (3939): sending -> AT^SYSCFGEX="00",3fffffff,2,4,7fffffffffffffff,,
Thu Feb 22 22:21:20 2018 daemon.notice netifd: LTE (3939): Starting network LTE
Thu Feb 22 22:21:20 2018 daemon.notice netifd: LTE (3939): Connecting modem
Thu Feb 22 22:21:20 2018 daemon.notice netifd: LTE (3939): sending -> AT^NDISDUP=1,1,"3internet"
Thu Feb 22 22:21:21 2018 daemon.notice netifd: LTE (3939): Setting up wwan0
Thu Feb 22 22:21:21 2018 daemon.notice netifd: Interface 'LTE' is now up
Thu Feb 22 22:21:21 2018 daemon.notice netifd: Network device 'wwan0' link is up
Thu Feb 22 22:21:21 2018 daemon.notice netifd: Network alias 'wwan0' link is up
Thu Feb 22 22:21:21 2018 daemon.notice netifd: Interface 'LTE_4' is enabled
Thu Feb 22 22:21:21 2018 daemon.notice netifd: Interface 'LTE_4' has link connectivity
Thu Feb 22 22:21:21 2018 daemon.notice netifd: Interface 'LTE_4' is setting up now
Thu Feb 22 22:21:21 2018 daemon.notice netifd: LTE_4 (3996): udhcpc: started, v1.27.2
Thu Feb 22 22:21:21 2018 daemon.notice netifd: LTE_4 (3996): udhcpc: sending discover
Thu Feb 22 22:21:21 2018 user.notice firewall: Reloading firewall due to ifup of LTE (wwan0)
Thu Feb 22 22:21:22 2018 daemon.info odhcpd[1188]: Using a RA lifetime of 0 seconds on br-lan
Thu Feb 22 22:21:22 2018 daemon.notice odhcpd[1188]: Failed to send to ff02::1%br-lan (Operation not permitted)
Thu Feb 22 22:21:24 2018 daemon.info dnsmasq[2257]: read /etc/hosts - 4 addresses
Thu Feb 22 22:21:24 2018 daemon.info dnsmasq[2257]: read /tmp/hosts/odhcpd - 2 addresses
Thu Feb 22 22:21:24 2018 daemon.info dnsmasq[2257]: read /tmp/hosts/dhcp.cfg01411c - 7 addresses
Thu Feb 22 22:21:24 2018 daemon.info dnsmasq-dhcp[2257]: read /etc/ethers - 0 addresses
Thu Feb 22 22:21:24 2018 daemon.notice netifd: LTE_4 (3996): udhcpc: sending discover
Thu Feb 22 22:21:27 2018 daemon.notice netifd: LTE_4 (3996): udhcpc: sending discover

The issue now is that udhcpc doesn't seem to get any response,
"devstatus wwan0" shows the tx_bytes keeps ticking up, while rx_bytes remains stuck at zero.

config interface 'LTE'
        option ifname 'wwan0'
        option proto 'ncm'
        option mode 'auto'
        option apn '3internet'
        option ipv6 'auto'
        option metric '100'
        option delegate '0'
        option device '/dev/ttyUSB1'
        option auto '0'

Try that skipinit patch and lets see if it helps!

There was an issue in the OpenWrt GitHub about ncm and e3372, about skipping that initialization to help ifup / ifdown work correctly, but now the issues tab is disabled.

Unfortunately not, it bypasses the 9600 baud Hayes style commands, leaves the 3G/4G style commands, possible the SYSCFGEX parameters need tweaking?

root@hh5a:~# ifup LTE
Fri Feb 23 04:29:24 2018 daemon.notice netifd: Interface 'LTE' is setting up now
Fri Feb 23 04:29:26 2018 daemon.notice netifd: LTE (9901): Skipping initialize modem LTE
Fri Feb 23 04:29:26 2018 daemon.notice netifd: LTE (9901): Configuring modem
Fri Feb 23 04:29:26 2018 daemon.notice netifd: LTE (9901): Setting mode
Fri Feb 23 04:29:26 2018 daemon.notice netifd: LTE (9901): sending -> AT^SYSCFGEX="00",3fffffff,2,4,7fffffffffffffff,,
Fri Feb 23 04:29:27 2018 daemon.notice netifd: LTE (9901): Starting network LTE
Fri Feb 23 04:29:27 2018 daemon.notice netifd: LTE (9901): Connecting modem
Fri Feb 23 04:29:28 2018 daemon.notice netifd: LTE (9901): sending -> AT^NDISDUP=1,1,"3internet"
Fri Feb 23 04:29:28 2018 daemon.notice netifd: LTE (9901): Setting up wwan0
Fri Feb 23 04:29:28 2018 daemon.notice netifd: Interface 'LTE' is now up
Fri Feb 23 04:29:28 2018 daemon.notice netifd: Network device 'wwan0' link is up
Fri Feb 23 04:29:28 2018 daemon.notice netifd: Network alias 'wwan0' link is up
Fri Feb 23 04:29:28 2018 daemon.notice netifd: Interface 'LTE_4' is enabled
Fri Feb 23 04:29:28 2018 daemon.notice netifd: Interface 'LTE_4' has link connectivity
Fri Feb 23 04:29:28 2018 daemon.notice netifd: Interface 'LTE_4' is setting up now
Fri Feb 23 04:29:29 2018 daemon.notice netifd: LTE_4 (9950): udhcpc: started, v1.27.2
Fri Feb 23 04:29:29 2018 daemon.notice netifd: LTE_4 (9950): udhcpc: sending discover
Fri Feb 23 04:29:29 2018 user.notice firewall: Reloading firewall due to ifup of LTE (wwan0)
Fri Feb 23 04:29:29 2018 daemon.info odhcpd[1187]: Using a RA lifetime of 0 seconds on br-lan
Fri Feb 23 04:29:32 2018 daemon.info dnsmasq[2200]: read /etc/hosts - 4 addresses
Fri Feb 23 04:29:32 2018 daemon.info dnsmasq[2200]: read /tmp/hosts/odhcpd - 2 addresses
Fri Feb 23 04:29:32 2018 daemon.info dnsmasq[2200]: read /tmp/hosts/dhcp.cfg01411c - 7 addresses
Fri Feb 23 04:29:32 2018 daemon.info dnsmasq-dhcp[2200]: read /etc/ethers - 0 addresses
Fri Feb 23 04:29:32 2018 daemon.notice netifd: LTE_4 (9950): udhcpc: sending discover
Fri Feb 23 04:29:35 2018 daemon.notice netifd: LTE_4 (9950): udhcpc: sending discover

I see it running

udhcpc -p /var/run/udhcpc-wwan0.pid -s /lib/netifd/dhcp.script -f -t 0 -i wwan0 -x hostname:hh5a -C -O 121

Not sure how far it's getting with that, but "ip route show" doesn't have anything on the wwan0 interface, and the interface has no IP address, Interface still shows "up" but without receiving any bytes ...

I will check my modem about sw versions and default modes.

I'll see if I can spy on Modem Manager's /dev/ttyUSB* traffic using socat and tee on the fedora box ...

Actually I just ran modemmanager in debug mode
however the output is too big to paste here,
I tried to upload as an attachment, but it apparently I'm only authorised to upload ,jpgs etc
can someone authorise me to upload a .txt file?

Use dpaste.de or other 3rd party service!

Of course I can do that, just thought an upload would be better ...

Fedora ModemManager log file

I noticed that fedora was using /dev/ttyUSB0 while I was using /dev/ttyUSB1 on openWRT, so I changed it in my config, unfortunately this caused a kernel panic after "ifup LTE"

presumably (but not confirmed) the same one I get when doing "ifdown LTE"

Have spent an hour or so, not using ifup/ifdown LTE, but instead using
minicom -D /dev/ttyUSB1
in one putty session, and sending various AT commands
AT^NDISDUP=1,1,"3internet"
AT^NDISSTATQRY?
AT^SYSINFOEX
etc, the same as ModemManager does

while manually running
udhcpd -i wwan0
in another putty session, hoping to find some different commands to put in
/etc/gcom/ncm.json

But haven't managed to get any further ... hints appreciated ...

It seems that the modem is unwilling to act on certain commands such as
AT^NDISDUP=1,1,"3internet"
from the /dev/ttyUSB1 interface, only from the /dev/ttyUSB0 interface

if I use ttyUSB0, then I do get a status response
^NDISSTAT:1,,,"IPV4"

Unfortunately immediately after that I get a kernel panic, perhaps the issue is with the wwan0 device crashing when the NDIS interface actually passes data?

I'll hook a serial console again tomorrow and see if i can get any more information when it crashes ...

Confirm that the panic which happens when using /dev/ttyUSB0 is the same one I logged a couple of weeks ago when I was trying to use the same dongle in "router" mode rather than "stick" mode

FS#1367

[44398.791094] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.82 #0
[44398.797007] task: 8059bd80 task.stack: 8058c000
[44398.801526] $ 0   : 00000000 806f0000 811d1be0 00000001
[44398.806748] $ 4   : 00000000 00001077 00004000 4e434d48
[44398.811970] $ 8   : 805a0000 00000001 00000003 4e434d48
[44398.817192] $12   : 00002863 ffffffff 00000000 77c632c0
[44398.822420] $16   : 86db1500 854e0008 87d7ba00 00000000
[44398.827637] $20   : 805990a0 00010000 00000002 00000000
[44398.832859] $24   : 00000001 875c36f8                  
[44398.838083] $28   : 8058c000 87c0dea8 00000018 875c36cc
[44398.843305] Hi    : 00000016
[44398.846178] Lo    : 00000001
[44398.849082] epc   : 800f3a78 kfree+0x78/0x1a4
[44398.853485] ra    : 875c36cc dwc2_lowlevel_hw_disable+0x12d0/0x1c20 [dwc2]
[44398.860279] Status: 1100ff03 KERNEL EXL IE 
[44398.864458] Cause : 10800034 (ExcCode 0d)
[44398.868463] PrId  : 00019556 (MIPS 34Kc)
[44398.872376] Modules linked in: ltq_ptm_vr9 ath9k ath9k_common option ath9k_hw ath10k_pci ath10k_core ath usb_wwan pppoe nf_conntrack_ipv6 mac80211 iptable_nat ipt_REJECT ipt_
MASQUERADE huawei_cdc_ncm cfg80211 cdc_ncm xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_e
cn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY usbserial usbnet pppox ppp_async owl_loader
 nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache ltq_deu_vr9 iptable_ma
ngle iptable_filter ipt_ECN ip_tables crc_ccitt compat cdc_wdm sch_cake nf_conntrack act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_tbf sch_htb 
sch_hfsc sch_ingress drv_dsl_cpe_api drv_mei_cpe ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables pppoatm ppp_generic slh
c ifb br2684 atm mii drv_ifxos dwc2 gpio_button_hotplug
Process swapper/0 (pid: 0, threadinfo=8058c000, task=8059bd80, tls=00000000)
[44398.976563] Stack : 00000000 875c370c 00000000 00000000 8110c2ac 86db1500 00000000 802d9b2c
[44398.984916]         806f41e0 00b29000 805a0000 8059bd80 00200100 87d7bae8 87d7baf0 87c0df00
[44398.993272]         87d7baec 802da144 00002863 ffffffff 00000a12 77c632c0 87c0df00 87c0df00
[44399.001628]         00000040 87d7bafc 87d7baf8 805e31fc 805993f8 80033524 00000000 8000c64c
[44399.009984]         87cc0000 80002000 8058c000 00000007 8058e058 00000040 806f41e0 00000006
[44399.018340]         ...
[44399.020778] Call Trace:
[44399.023237] [<800f3a78>] kfree+0x78/0x1a4
[44399.027290] [<875c36cc>] dwc2_lowlevel_hw_disable+0x12d0/0x1c20 [dwc2]
[44399.033792] Code: 30630001  24030001  38630001 <00030336> 8c430000  7c630380  10600003  00000000  10000002 
[44399.043495] 
[44399.045134] ---[ end trace 562d43e3ca4364f0 ]---
[44399.050518] Kernel panic - not syncing: Fatal exception in interrupt
[44399.056621] Rebooting in 3 seconds..

The panic from dwc2 appears to be fixed in 18.06.2 so the E3372s is now working for me.

1 Like

Can confirm that the E3372(h) works fine in NCM mode using /dev/ttyUSB0
No need to change anything apart from APN
Firmware 21.329.63.00.541 for those wondering.

TP-Link TL-WDR3600 (ar71xx) running trunk/master

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