Huawei E3372 with NCM

Installing and Using OpenWrt
1

I'm running SNAPSHOT r6150 on a BT homehub 5a with a Huawei E3372h USB dongle.

I ran into a bug that crashed dwc2_lowlevel_hw_disable when using the dongle in "HiLink router mode" with kmod-usb-net-cdc-ether, so flashed the dongle to "stick mode" and now using kmod-usb-net-huawei-cdc-ncm instead.

The dongle works properly on a PC running Fedora27, though I guess in that case it is using NetworkManager/ModemManager for the dongle.

Software versions ...
kernel - 4.9.77-1-b3856355ef32057f204aaf8b7ab28ff3
comgt-ncm - 0.32-30
kmod-usb-net-cdc-ncm - 4.9.77-1
kmod-usb-net-huawei-cdc-ncm - 4.9.77-1
luci-proto-ncm - git-18.047.57952-461df8b-1

When I plug the dongle into the homehub router, I get the following in the kernel log, which seems good to me

[  508.628244] usb 1-1: new high-speed USB device number 2 using dwc2
[  509.288672] usb 1-1: USB disconnect, device number 2
[  510.116203] usb 1-1: new high-speed USB device number 3 using dwc2
[  510.521635] huawei_cdc_ncm 1-1:1.2: MAC-Address: 00:1e:10:1f:00:00
[  510.526676] huawei_cdc_ncm 1-1:1.2: setting rx_max = 16384
[  510.544257] huawei_cdc_ncm 1-1:1.2: NDP will be placed at end of frame for this device.
[  510.551453] huawei_cdc_ncm 1-1:1.2: cdc-wdm0: USB WDM device
[  510.559159] 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

and I see the control device "/dev/cdc-wdm0" has been created, along with the network device "wwan0"

I have added a section to my /etc/config/network as follows

config interface 'LTE'
         option proto 'ncm'
         option device '/dev/cdc-wdm0'
         option mode 'auto'
         option apn '3internet'
         option ipv6 'auto'
         option metric '100'

But when I try to start the interface, all I see from logread is the following over and over

Sat Feb 17 10:00:58 2018 daemon.notice netifd: Interface 'LTE' is setting up now
Sat Feb 17 10:01:00 2018 daemon.notice netifd: LTE (15994): Configuring modem
Sat Feb 17 10:01:00 2018 daemon.notice netifd: LTE (15994): WARNING: Variable 'modes' does not exist or is not an array/object
Sat Feb 17 10:01:00 2018 daemon.notice netifd: LTE (15994): Setting mode
Sat Feb 17 10:01:00 2018 daemon.notice netifd: LTE (15994): sending ->
Sat Feb 17 10:01:15 2018 daemon.notice netifd: LTE (15994): Timeout running AT-command
Sat Feb 17 10:01:15 2018 daemon.notice netifd: LTE (15994): Failed to set operating mode
Sat Feb 17 10:01:16 2018 daemon.notice netifd: LTE (16026): Stopping network LTE
Sat Feb 17 10:01:16 2018 daemon.notice netifd: LTE (16026): sending ->
Sat Feb 17 10:01:20 2018 daemon.notice netifd: Interface 'LTE' is now down

it looks like some part of netifd may be confused whether the "option mode" clause should really be "option modes", when I added both options it silenced the error but didn't help the interface to start.

I get no output from usbmode -s
or usbmode -l

I can see the following running while the interface is trying to start

gcom -d /dev/cdc-wdm0 -s /etc/gcom/runcommand.gcom

{ncm.sh} /bin/sh ./ncm.sh ncm setup LTE {"proto":"ncm","metric":100,"device":"/dev/cdc-wdm0","mode":"auto","apn":"3internet","me /// truncated

If I use minicom -D /dev/cdc-wdm0
I don't get any response to AT commands, but then if I try the same when the stick is plugged into the Fedora PC, I get no responses either, so that may not be significant

Anyone got any suggestions to get the dongle running with NCM?

Thanks ...

2

A bit of thinking aloud ...

I uninstalled usb-modeswitch, and rmmod'ed the huawei_cdc_ncm, cdc_ncm and usbnet modules
un-plugged and re-plugged the dongle, which left it in Mass-storage mode, so I can see the VID/PID

Bus 001 Device 006: ID 12d1:14fe Huawei Technologies Co., Ltd. Modem (Mass Storage Mode)

It also confirms that usb-modeswitch does something useful to the dongle
After re-installing usb-modeswitch, it's back as a network device

Bus 001 Device 007: ID 12d1:1506 Huawei Technologies Co., Ltd. Modem/Networkcard

And I can see the entry in /etc/usb-mode.json for the device

        "12d1:14fe": {
                "*": {
                        "t_vendor": 4817,
                        "t_product": [ 5382, 5391, 5405, 7198 ],
                        "mode": "HuaweiNew",
                        "msg": [  ]
                }
        },

Am I right in thinking that openwrt has its own usb-modeswitch, which does the same job, but is a different implementation from e.g. that found in a desktop Linux?

3

OK, comparing the dmesg and lsusb from the fedora system that works with the dongle, and openwrt which doesn't ...

I was missing kmod-usb-serial.* so had to re-install a new kernel to get the corresponding kmods

But still the lsusb -tv showed no /dev/ttyUSB0 and ttyUSB1 loaded for the first first two USB endpoints of the dongle.

So I manually "persuaded" it to load drivers with

echo "12d1 1506 ff" > /sys/bus/usb-serial/drivers/generic/new_id

[ 1003.351417] usbserial_generic 1-1:1.0: The "generic" usb-serial driver is only for testing and one-off prototypes.
[ 1003.360515] usbserial_generic 1-1:1.0: Tell linux-usb@vger.kernel.org to add your device to a proper driver.
[ 1003.370345] usbserial_generic 1-1:1.0: generic converter detected
[ 1003.377122] usb 1-1: generic converter now attached to ttyUSB0
[ 1003.382521] usbserial_generic 1-1:1.1: The "generic" usb-serial driver is only for testing and one-off prototypes.
[ 1003.392654] usbserial_generic 1-1:1.1: Tell linux-usb@vger.kernel.org to add your device to a proper driver.
[ 1003.402464] usbserial_generic 1-1:1.1: generic converter detected
[ 1003.409607] usb 1-1: generic converter now attached to ttyUSB1

so, clearly not the correct way to get the driver loaded, but at last, I can use minicom -D /dev/ttyUSB1 and can talk AT commands to the modem

Setting a custom modem device for the wwan interface and the interface is up :smile:

Sun Feb 18 19:42:27 2018 daemon.notice netifd: LTE (15985): sending -> AT
Sun Feb 18 19:42:28 2018 daemon.notice netifd: LTE (15985): sending -> ATZ
Sun Feb 18 19:42:28 2018 daemon.notice netifd: LTE (15985): sending -> ATQ0
Sun Feb 18 19:42:29 2018 daemon.notice netifd: LTE (15985): sending -> ATV1
Sun Feb 18 19:42:29 2018 daemon.notice netifd: LTE (15985): sending -> ATE1
Sun Feb 18 19:42:30 2018 daemon.notice netifd: LTE (15985): sending -> ATS0=0
Sun Feb 18 19:42:31 2018 daemon.notice netifd: LTE (15985): sending -> AT+CGDCONT=1,"IP","3internet"
Sun Feb 18 19:42:31 2018 daemon.notice netifd: LTE (15985): Configuring modem
Sun Feb 18 19:42:31 2018 daemon.notice netifd: LTE (15985): Setting mode
Sun Feb 18 19:42:32 2018 daemon.notice netifd: LTE (15985): sending -> AT^SYSCFGEX="00",3fffffff,2,4,7fffffffffffffff,,
Sun Feb 18 19:42:33 2018 daemon.notice netifd: LTE (15985): Starting network LTE
Sun Feb 18 19:42:33 2018 daemon.notice netifd: LTE (15985): Connecting modem
Sun Feb 18 19:42:33 2018 daemon.notice netifd: LTE (15985): sending -> AT^NDISDUP=1,1,"3internet"
Sun Feb 18 19:42:34 2018 daemon.notice netifd: LTE (15985): Setting up wwan0
Sun Feb 18 19:42:34 2018 daemon.notice netifd: Interface 'LTE' is now up
Sun Feb 18 19:42:34 2018 daemon.notice netifd: Network device 'wwan0' link is up
Sun Feb 18 19:42:34 2018 daemon.notice netifd: Network alias 'wwan0' link is up
Sun Feb 18 19:42:34 2018 daemon.notice netifd: Interface 'LTE_4' is enabled
Sun Feb 18 19:42:34 2018 daemon.notice netifd: Interface 'LTE_4' has link connectivity
Sun Feb 18 19:42:34 2018 daemon.notice netifd: Interface 'LTE_4' is setting up now
Sun Feb 18 19:42:34 2018 daemon.notice netifd: LTE_4 (16045): udhcpc: started, v1.27.2
Sun Feb 18 19:42:34 2018 daemon.notice netifd: LTE_4 (16045): udhcpc: sending discover
Sun Feb 18 19:42:35 2018 user.notice firewall: Reloading firewall due to ifup of LTE (wwan0)

So does the lack of /dev/ttyUSB* indicate a problem with usb-modeswitch?

4

OK, so here is my network config, that sort of works

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'

Apart from the manual loading of /etc/ttyUSB* being required, I still have some other problem that is crashing the router, so I have to connect a serial console to see what's going on with that ...

5 
root@hh5a:/# ifdown LTE
root@hh5a:/#
root@hh5a:/# [256467.571884] CPU 1 Unable to handle kernel paging request at virtual address 67901b30, epc == 800f33f8, ra == 800f3b94
[256467.581230] Oops[#1]:
[256467.583518] CPU: 1 PID: 14 Comm: ksoftirqd/1 Not tainted 4.9.82 #0
[256467.589782] task: 87c3d080 task.stack: 87c7a000
[256467.594379] $ 0   : 00000000 806f0004 67901b30 00000001
[256467.599688] $ 4   : 87c02b00 810fb560 67901a00 67901a00
[256467.605003] $ 8   : 805993f8 04efd20a d208b27a 0000008c
[256467.610310] $12   : 52016177 ffffffff 00000000 1a0004e4
[256467.615619] $16   : 810fb560 850d8008 000d001a 00000000
[256467.620930] $20   : 805990a0 00000000 87c02b00 00000000
[256467.626238] $24   : 00000000 875e36f8
[256467.631549] $28   : 87c7a000 87c7bcd8 00000018 800f3b94
[256467.636856] Hi    : 00000000
[256467.639814] Lo    : 0000c400
[256467.642811] epc   : 800f33f8 __slab_free.isra.13+0x64/0x334
[256467.648453] ra    : 800f3b94 kfree+0x194/0x1a4
[256467.652963] Status: 1100c303        KERNEL EXL IE
[256467.657223] Cause : 0080000c (ExcCode 03)
[256467.661312] BadVA : 67901b30
[256467.664274] PrId  : 00019556 (MIPS 34Kc)
[256467.668270] Modules linked in: ltq_ptm_vr9 ath9k ath9k_common ath9k_hw ath10k_pci ath10k_core ath usb_wwan pppoe nf_nat_pptp nf_conntrack_pptp 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_ecn 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 ts_fsm ts_bm pppox ppp_async owl_loader nf_reject_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_redirect nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4 nf_nat_ipv4 nf_nat_h323 nf_nat_amanda nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip nf_conntrack_rtcache nf_conntrack_proto_gre nf_conntrack_irc nf_conntrack_h323 nf_conntrack_broadcast ts_kmp nf_conntrack_amanda ltq_deu_vr9 iptable_mangle 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 slhc ifb br2684 atm mii drv_ifxos dwc2 gpio_button_hotplug
Process ksoftirqd/1 (pid: 14, threadinfo=87c7a000, task=87c3d080, tls=00000000)
[256467.798220] Stack : 00000000 00000001 00000000 00000000 67901a00 67901a00 00000001 805a0000
[256467.806661]         04f6d940 850d8008 00003fe0 00000002 67901a00 04efd20a d208b27a d20f920a
[256467.815103]         52016177 ffffffff 00000000 1a0004e4 876a8d00 850d8008 87d7b800 00000000
[256467.823546]         876a8d00 850d8008 87d7b800 00000000 805990a0 00010000 00000002 00000000
[256467.831989]         00000018 800f3b94 00000018 875e36bc 1100c303 00000000 00000001 04f6d940
[256467.840432]         ...
[256467.842959] Call Trace:
[256467.845511] [<800f33f8>] __slab_free.isra.13+0x64/0x334
[256467.850826] [<800f3b94>] kfree+0x194/0x1a4
[256467.854986] Code: 8e12000c  00621021  8fa30018 <ac550000> 00121402  00431023  3042ffff  afb2002c  32570001
[256467.864804]
[256467.866497] ---[ end trace e77f91eef6b40e80 ]---

root@h[256467.872551] Kernel panic - not syncing: Fatal exception in interrupt
[256467.878975] Rebooting in 3 seconds..
6

I use this script (opkg-lte-modem.sh) for SNAPSHOT firmware:

#!/bin/sh
opkg update
opkg install chat comgt-ncm kmod-usb-serial-option kmod-usb-net-huawei-cdc-ncm usb-modeswitch patch diffutils minicom luci-proto-ncm

# https://ww.telent.net/2016/11/12/huawei_e3372_with_openwrt
# https://eko.one.pl/?p=openwrt-3g#obsugamodemwwtrybiencm
uci del network.ltemodem || true
uci set network.ltemodem=interface
uci set network.ltemodem.proto=ncm
uci set network.ltemodem.apn=net
uci set network.ltemodem.ifname=wwan0
uci set network.ltemodem.delay=15
uci set network.ltemodem.mode=auto
uci set network.ltemodem.skipinit=1
uci set network.ltemodem.device=/dev/ttyUSB0 # lub /dev/cdc-wdm0
# uci set network.ltemodem.pincode=1234
uci commit network

Sure, you need to change the pin & apn settings! :slight_smile:

After that I apply the patch below to /lib/netifd/proto/ncm.sh, to letting me skip the initialization process:

--- /lib/netifd/proto/ncm.sh.orig       2018-02-05 16:45:54.000000000 +0000
+++ /lib/netifd/proto/ncm.sh    2018-02-06 00:26:15.000000000 +0000
@@ -14,26 +14,27 @@
        proto_config_add_string auth
        proto_config_add_string username
        proto_config_add_string password
        proto_config_add_string pincode
        proto_config_add_string delay
        proto_config_add_string mode
        proto_config_add_string pdptype
        proto_config_add_int profile
+       proto_config_add_int skipinit
        proto_config_add_defaults
 }

 proto_ncm_setup() {
        local interface="$1"

        local manufacturer initialize setmode connect finalize ifname devname devpath

-       local device apn auth username password pincode delay mode pdptype profile $PROTO_DEFAULT_OPTIONS
-       json_get_vars device apn auth username password pincode delay mode pdptype profile $PROTO_DEFAULT_OPTIONS
+       local device apn auth username password pincode delay mode pdptype profile skipinit $PROTO_DEFAULT_OPTIONS
+       json_get_vars device apn auth username password pincode delay mode pdptype profile skipinit $PROTO_DEFAULT_OPTIONS

        [ "$metric" = "" ] && metric="0"

        [ -n "$profile" ] || profile=1

        pdptype=`echo "$pdptype" | awk '{print toupper($0)}'`
        [ "$pdptype" = "IP" -o "$pdptype" = "IPV6" -o "$pdptype" = "IPV4V6" ] || pdptype="IP"

@@ -83,24 +84,28 @@
        json_load "$(cat /etc/gcom/ncm.json)"
        json_select "$manufacturer"
        [ $? -ne 0 ] && {
                echo "Unsupported modem"
                proto_notify_error "$interface" UNSUPPORTED_MODEM
                proto_set_available "$interface" 0
                return 1
        }
-       json_get_values initialize initialize
-       for i in $initialize; do
-               eval COMMAND="$i" gcom -d "$device" -s /etc/gcom/runcommand.gcom || {
-                       echo "Failed to initialize modem"
-                       proto_notify_error "$interface" INITIALIZE_FAILED
-                       return 1
-               }
-       done
+       if [ ! "x$skipinit" = "x1" ]; then
+               json_get_values initialize initialize
+               for i in $initialize; do
+                       eval COMMAND="$i" gcom -d "$device" -s /etc/gcom/runcommand.gcom || {
+                               echo "Failed to initialize modem"
+                               proto_notify_error "$interface" INITIALIZE_FAILED
+                               return 1
+                       }
+               done
+       else
+               echo "Skipping initialize modem $interface"
+       fi

        [ -n "$pincode" ] && {
                PINCODE="$pincode" gcom -d "$device" -s /etc/gcom/setpin.gcom || {
                        echo "Unable to verify PIN"
                        proto_notify_error "$interface" PIN_FAILED
                        proto_block_restart "$interface"
                        return 1
                }

OK, this won't help with your kernel panics. :confused:

7

Thanks for the reply, I can only tinker with this at night, as the reboots disrupt my work connections in the day.

I think the crash only happens with ifdown, not ifup, so I can avoid it for now

I seem to have most of those packages installed, but if I have any missing I'll have to upgrade to latest snapshot to get any missing kmods

8

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.

9

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!

10

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
11

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

12

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

13

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.

14

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'
15

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.

16

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 ...

17

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

18

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

19

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?

20

Use dpaste.de or other 3rd party service!