Umbim does not support roaming (was "Huawei K5150, uqmi does not work")

Installing and Using OpenWrt Network and Wireless Configuration
1

NOTE: This device does NOT support uqmi, it supports only MBIM. It seems this is an issue with the SIM being in roaming mode. See the comments below for the details.

I am trying to setup an OpenWrt 22.03.0-rc6 with a Huawei K5150 LTE stick.

The LTE device works fine using modemmanager (IIRC it uses libqmi), but that option uses way too much space that I need for other tools.

It also works by defining a DHCP interface, manually calling mbim-network and then restarting the interface. But this option is too manual, and I'd like to avoid writing some automation.

So I am trying with the QMI protocol (https://openwrt.org/docs/guide-user/network/wan/wwan/ltedongle), and while I can configure everything, the modem initialization stops at:

Fri Aug 12 21:22:59 2022 daemon.notice netifd: Interface 'LTE' is setting up now
Fri Aug 12 21:23:59 2022 daemon.notice netifd: LTE (3568): Waiting for SIM initialization

So far, I discovered that uqmi -s -d /dev/cdc-wdm0 --get-pin-status is running forever.

If I remove the interface and I try to use uqmi to run any command on the device, it just hangs, until I use CTRL+C.

If I add a timeout, then the request times out:

# uqmi -s -d /dev/cdc-wdm0 --get-pin-status -t 600
Request timed out
"Failed to connect to service

I am not sure what else I can try, but I happy to provide more info or debug the problem if something tells me what I should be looking at :slight_smile:

2

I case it could be relevant for the issue, the SIM card is on national roaming, something quite normal here in Spain for some virtual mobile networks.

3

The link provide herein is for a totally different device but the remedy may be useful for insight.

2022-08-12_191825
2022-08-12_191825951×797 156 KB

4

Unfortunately one of the things I tried was disabling the PIN, and still there was no difference.

In fact I could not use any uqmi calls at all.

I will see if there's a firmware update, just in case.

5

QMI and MBIM are different things. And your modem also supports NCM, maybe try it?

6

Yes, I know they are. That's why I mentioned I tried it, and it worked (but requires manual intervention or extra automation).

I tried NCM yesterday, but I didn't mention it on the first post because the device was not recognized. I will try once again just in case, but I am wondering: where did you see that the K5150 supports NCM?

7

I must have been confused. Sorry.

Anyway, if I install umbim, I get a file, /lib/netifd/proto/mbim.sh, which suggests that netifd can connect via MBIM. Luci support is unfortunately missing. Maybe try this? The values are made up, adjust accordingly.

config interface 'wwan'
	option device '/dev/cdc-wdm0'
	option proto 'mbim'
	option apn 'internet'
	option auth 'pap'
	option username 'lte'
	option password 'lte'
8

I tried, for whatever reason it seems /lib/netifd/proto/mbim.sh does not recognize the device.

ifup wwan

Just doesn't show anything

root@OpenWrt:~# ifstatus wwan
{
        "up": false,
        "pending": false,
        "available": false,
        "autostart": true,
        "dynamic": false,
        "proto": "none",
        "device": "/dev/cdc-wdm0",
        "data": {

        },
        "errors": [
                {
                        "subsystem": "interface",
                        "code": "NO_DEVICE"
                }
        ]
}

mbim itself works if I manually call mbim-network /dev/cdc-wdm0 start

I checked /lib/netifd/proto/mbim.sh and I'd say something happens at:

        [ -n "$ctl_device" ] && device=$ctl_device

        [ -n "$device" ] || {
                echo "mbim[$$]" "No control device specified"
                proto_notify_error "$interface" NO_DEVICE
                proto_set_available "$interface" 0
                return 1
        }
        [ -c "$device" ] || {
                echo "mbim[$$]" "The specified control device does not exist"
                proto_notify_error "$interface" NO_DEVICE
                proto_set_available "$interface" 0
                return 1
        }
9

Well, you know which "umbim" commands it runs, so you can run them yourself with the "-v" flag added for the extra verbosity.

The part that you quoted does not call umbim, it only tries to validate the device - so all we have is an incorrectly constructed configuration statement. What's the error, by the way? What's in logread | tail -n 50?

10

OK, so, based on the error, $device is either not set or points to something other than a character device. We can distinguish between these two cases by looking into logread output - it should say either "No control device specified" or "The specified control device does not exist". Which one is the case for you?

11

This is also highly suspicious.

12

First things first, I think this device is not QMI compatible.

Plugging the device on a GNU/Linux laptop clearly shows:

ago 13 16:23:47 localhost.localdomain ModemManager[984]: <info>  [cdc-wdm0/mbim] MBIM device is not QMI capable
ago 13 16:23:47 localhost.localdomain ModemManager[984]: [/dev/cdc-wdm0] channel destroyed
ago 13 16:23:47 localhost.localdomain ModemManager[984]: <info>  [device /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1] creating modem with plugin 'huawei' and '2' ports
ago 13 16:23:47 localhost.localdomain ModemManager[984]: <info>  [base-manager] modem for device '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1' successfully created
ago 13 16:23:47 localhost.localdomain ModemManager[984]: opening device...
ago 13 16:23:47 localhost.localdomain ModemManager[984]: [/dev/cdc-wdm0] Read max control message size from descriptors file: 1024
ago 13 16:23:47 localhost.localdomain ModemManager[984]: <info>  [modem5/cdc-wdm0/mbim] MBIM device is not QMI capable
ago 13 16:23:47 localhost.localdomain ModemManager[984]: <warn>  [modem5] couldn't load carrier config: QMI PDC not supported
ago 13 16:23:47 localhost.localdomain ModemManager[984]: <warn>  [modem5] couldn't load supported bands: Unsupported
ago 13 16:23:49 localhost.localdomain ModemManager[984]: <warn>  [modem5/sim5] couldn't load list of emergency numbers: No AT port available to run command
ago 13 16:23:49 localhost.localdomain ModemManager[984]: <warn>  [modem5] couldn't load current bands: Unsupported
ago 13 16:23:49 localhost.localdomain ModemManager[984]: <warn>  [modem5] couldn't load UE mode of operation for EPS: No AT port available to run command
ago 13 16:23:49 localhost.localdomain ModemManager[984]: <warn>  [modem5] couldn't load initial EPS bearer settings: LTE attach configuration is unsupported
ago 13 16:23:49 localhost.localdomain ModemManager[984]: <warn>  [modem5] couldn't open ports during Modem SIM hot swap enabling: Couldn't get primary port

So it's clear a I need to stick to the mbim protocol. I am doing some tests now.

1 Like
13

And here comes more useful information, after I started everything from scratch.

/etc/network/config now contains:

config interface 'wwan'
        option device '/dev/cdc-wdm0'
        option proto 'mbim'
        option apn 'tel.hitsmobile.es'

ifstatus wwan0 shows:

root@OpenWrt:~# ifstatus wwan
{
        "up": false,
        "pending": true,
        "available": true,
        "autostart": true,
        "dynamic": false,
        "proto": "mbim",
        "data": {

        },
        "errors": [
                {
                        "subsystem": "mbim",
                        "code": "NO_REGISTRATION"
                }
        ]
}

This comes from having logread -f running.

Sat Aug 13 14:39:17 2022 daemon.notice netifd: wwan (20539): mbim[20539] Reading capabilities
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   devicetype: 0002 - removable
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   cellularclass: 0001
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   voiceclass: 0001 - no-voice
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   simclass: 0002
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   dataclass: 8000001F
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   smscaps: 0003
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   controlcaps: 0001
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   maxsessions: 0001
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   deviceid: 860112020327997
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   firmwareinfo: V3.0
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   hardwareinfo: CH1K5150M
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539): mbim[20539] Checking pin
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539): Pin Unlocked
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539): mbim[20539] Checking subscriber
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   readystate: 0001 - initialized
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   simiccid: 89345XXXXXXXXXXXXXX
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   subscriberid: 214XXXXXXXXXXXX
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539): mbim[20539] Register with network
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   nwerror: 0000 - unknown
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   registerstate: 0004 - roaming
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   registermode: 0001 - automatic
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   availabledataclasses: 0020 - lte
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   currentcellularclass: 0001 - gsm
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   provider_id: 21401
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   provider_name: Voda ES
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   roamingtext: (null)
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539): mbim[20539] Subscriber registration failed
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   sessionid: 0
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   activationstate: 0003 - deactivated
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   voicecallstate: 0000 - none
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   nwerror: 0000 - unknown
Sat Aug 13 14:39:18 2022 daemon.notice netifd: wwan (20539):   iptype: 0000 - default

In this case, the device LED keeps blinking in purple.

So we don't reach the "registered" state.

Now, if I call ifdown wwan and then call:

root@OpenWrt:~# mbim-network /dev/cdc-wdm0 start
Loading profile at /etc/mbim-network.conf...
    APN: tel.hitsmobile.es
    APN auth protocol: unset
    APN user: unset
    APN password: unset
    mbim-proxy: no
Querying subscriber ready status 'mbimcli -d /dev/cdc-wdm0 --query-subscriber-ready-status --no-close'...
[/dev/cdc-wdm0] Subscriber ready status retrieved: Ready state: 'initialized' Subscriber ID: '2140XXXXXXXXXXX' SIM ICCID: '8934XXXXXXXXXXXXXXXX' Ready info: 'none' Telephone numbers: (0) 'unknown' [/dev/cdc-wdm0] Session not closed: TRID: '3'
Querying registration state 'mbimcli -d /dev/cdc-wdm0 --query-registration-state --no-open=3 --no-close'...
[/dev/cdc-wdm0] Registration status: Network error: 'unknown' Register state: 'roaming' Register mode: 'automatic' Available data classes: 'lte' Current cellular class: 'gsm' Provider ID: '21401' Provider name: 'Voda ES' Roaming text: 'unknown' Registration flags: 'none' [/dev/cdc-wdm0] Session not closed: TRID: '4'
Attaching to packet service with 'mbimcli -d /dev/cdc-wdm0 --attach-packet-service --no-open=4 --no-close'...
[/dev/cdc-wdm0] Successfully attached to packet service [/dev/cdc-wdm0] Packet service status: Network error: 'unknown' Packet service state: 'attached' Available data classes: 'lte' Uplink speed: '0 bps' Downlink speed: '0 bps' [/dev/cdc-wdm0] Session not closed: TRID: '5'
Starting network with 'mbimcli -d /dev/cdc-wdm0 --connect=apn='tel.hitsmobile.es' --no-open=5 --no-close'...
Network started successfully
Saving state at /tmp/mbim-network-state-cdc-wdm0... (TRID: 7)

And in this case, the LED stays purple and doesn't blink. However mbin-network calls /usr/bin/mbimcli and not /sbin/umbim

Now, running the umbim calls manually, lands me with the command registration exiting with an error, even if... it seems the registration worked and the SIM is in roaming mode?

root@OpenWrt:~# umbim -d /dev/cdc-wdm0 registration; echo $?
  nwerror: 0000 - unknown
  registerstate: 0004 - roaming
  registermode: 0001 - automatic
  availabledataclasses: 0020 - lte
  currentcellularclass: 0001 - gsm
  provider_id: 21401
  provider_name: Voda ES
  roamingtext: (null)
4

Could it be umbim does not handle roaming mode while mbimcli does?

14

What both umbim and mbimcli share is:

  • nwerror: 0000 - unknown for umbim
  • Network error: 'unknown' for nbimcli

And in both cases the mention to roaming is there.

However it seems nbimcli doesn't care, while umbim considers that a problem.

15

Bingo!

I tried a SIM from another carrier that does not do roaming, and it works perfectly with umbim, and thefore ifup wwan works as well.

Sat Aug 13 15:18:16 2022 daemon.notice netifd: wwan (25483): mbim[25483] Register with network
Sat Aug 13 15:18:17 2022 daemon.notice netifd: wwan (25483):   nwerror: 0000 - unknown
Sat Aug 13 15:18:17 2022 daemon.notice netifd: wwan (25483):   registerstate: 0003 - home
Sat Aug 13 15:18:17 2022 daemon.notice netifd: wwan (25483):   registermode: 0001 - automatic
Sat Aug 13 15:18:17 2022 daemon.notice netifd: wwan (25483):   availabledataclasses: 0020 - lte
Sat Aug 13 15:18:17 2022 daemon.notice netifd: wwan (25483):   currentcellularclass: 0001 - gsm
Sat Aug 13 15:18:17 2022 daemon.notice netifd: wwan (25483):   provider_id: 21403
Sat Aug 13 15:18:17 2022 daemon.notice netifd: wwan (25483):   provider_name: Orange
Sat Aug 13 15:18:17 2022 daemon.notice netifd: wwan (25483):   roamingtext: (null)

nwerror: 0000 - unknown is still there, but the registerstate is 0003 - home and not 0004 - roaming

Looks like I should create a bug report, providing the calls to umbim -d /dev/cdc-wdm0 registration with -v?

Or is there something else I should debug here first?

16

Just for the record, the SIM that fails on the K5150 is working perfectly fine with a Huawei K3806 that uses proto-3g

17

Looks to me I hit https://github.com/openwrt/openwrt/issues/8369

My proposal for a fix is https://github.com/openwrt/openwrt/issues/8369#issuecomment-1214247627

2 Likes
18

And just for completeness, I developed a fix and prepared a PR: https://github.com/openwrt/openwrt/pull/10456 (I hope it's OK) :slight_smile:

2 Likes
19

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