Can I connect a small 5V 0.2A fan like this one to +5V0 and GND pins? (Or to +3V3, as this particular fan seems to accept anything between 3.0V and 5.8V)
@hyc I’ve followed the steps outlined in Turris Omnia LTE Router Project | LTE-Forum Österreich. Except, instead of using their versions of MBIM, I used yours from the pull requests. Specifically:
opkg update
opkg install icomgt comgt-directip kmod-mii kmod-usb-net kmod-usb-net-cdc-mbim kmod-usb-net-cdc-ncm kmod-usb-net-sierrawireless kmod-usb-serial kmod-usb-serial-qualcomm kmod-usb-serial-sierrawireless kmod-usb-serial-wwan umbim wwan
wget 'https://raw.githubusercontent.com/openwrt/openwrt/c3c409f1c70bc1aa69d3ab6b4d6af3f07c0c0d25/package/network/utils/umbim/files/lib/netifd/proto/mbim.sh' -O /lib/netifd/proto/mbim.sh
wget 'https://raw.githubusercontent.com/openwrt/luci/8995accd5c52188388857d6e1238697e14e1b478/protocols/luci-proto-mbim/htdocs/luci-static/resources/protocol/mbim.js' -O /www/luci-static/resources/protocol/mbim.js
reboot # because I didn't know how to tell Luci UI to reload its JavaScripts
At this point, the modem itself seems functional, as in, you can send commands to it, and it says OK if it understands me, and ERROR if not. So far so good.
AT!ENTERCND="A710"
OK
AT!BAND=00
OK
AT!XD=0
ERROR
I can even see the modem exposes many useful LTE related data:
AT!GSTATUS?
!GSTATUS:
Current Time: 12070 Temperature: 30
Reset Counter: 1 Mode: ONLINE
System mode: LTE PS state: Attached
LTE band: B5 LTE bw: 10 MHz
LTE Rx chan: 2600 LTE Tx chan: 19150
LTE CA state: NOT ASSIGNED
EMM state: Registered Normal Service
RRC state: RRC Idle
IMS reg state: No Srv
PCC RxM RSSI: -71 RSRP (dBm): -100
PCC RxD RSSI: -67 RSRP (dBm): -97
Tx Power: 0 TAC: 730E (29454)
RSRQ (dB): -12.8 Cell ID: 0852EE02 (139652610)
SINR (dB): 4.6
Then I proceeded to creating an interface:
Unfortunately, this is where I’m stuck at. I tried both /dev/cdc-wdm0 and /dev/cdc-wdm1.
logread says:
Sep 11 23:31:47 turris netifd: Interface 'lte' is setting up now
Sep 11 23:31:47 turris netifd: lte (13950): mbim[13950] Reading capabilities
Sep 11 23:32:01 turris crond[14076]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Sep 11 23:32:02 turris netifd: lte (13950): ERROR: mbim message timeout
Sep 11 23:32:02 turris netifd: lte (13950): mbim[13950] Failed to read modem caps
Sep 11 23:32:03 turris root: mbim bringup failed, retry in 15s
Sep 11 23:32:18 turris netifd: lte (14111): mbim[14111] Stopping network
Sep 11 23:32:18 turris netifd: lte (14111): Command failed: Permission denied
Sep 11 23:32:18 turris netifd: Interface 'lte' is now down
It appears to be a problem on the MBIM level, and not on the kernel module level.
Any ideas what went wrong and how to fix it?
BTW, failing to read capabilities should expose something different than PIN_FAILED. Maybe CAPS_FAILED to differentiate this from a PIN error. Maybe it’s worth adding to your existing PR since it wasn’t merged yet.
umbim $DBG -n -d $device caps || {
echo "mbim[$$]" "Failed to read modem caps"
proto_notify_error "$interface" PIN_FAILED
return 1
}
1 Like
@hyc I had no luck with MBIM but I came across people talking QMI is a better choice than MBIM so tried that. After opkg install kmod-usb-net-qmi-wwan libqmi luci-proto-qmi qmi-utils uqmi, was able to get it working using QMI protocol. I simply set the protocol to QMI, and got this first:
Sep 12 00:58:30 turris netifd: Interface 'lte' is setting up now
Sep 12 00:58:30 turris netifd: lte (22068): Waiting for SIM initialization
Sep 12 00:58:31 turris netifd: lte (22068): Device does not support 802.3 mode. Informing driver of raw-ip only for wwan0 ..
Sep 12 00:58:31 turris netifd: lte (22068): Waiting for network registration
Sep 12 00:58:31 turris netifd: lte (22068): Starting network lte
Sep 12 00:58:32 turris netifd: lte (22068): Unable to connect IPv6
Sep 12 00:58:32 turris netifd: lte (22200): Stopping network lte
Sep 12 00:58:32 turris netifd: lte (22200): Command failed: Permission denied
Sep 12 00:58:32 turris netifd: Interface 'lte' is now down
However, qmicli -d /dev/cdc-wdm1 --device-open-proxy --nas-get-cell-location-info was showing me good things - tower IDs, signal strenght, etc. - so I knew the QMI protocol itself works on /dev/cdc-wdm1 so it must be a matter of configuration. I forced the QMI’s network protocol to IPv4, and boom, all working:
Sep 12 01:05:34 turris netifd: Interface 'lte' is setting up now
Sep 12 01:05:34 turris netifd: lte (31137): Waiting for SIM initialization
Sep 12 01:05:35 turris netifd: lte (31137): Device does not support 802.3 mode. Informing driver of raw-ip only for wwan1 ..
Sep 12 01:05:35 turris netifd: lte (31137): Waiting for network registration
Sep 12 01:05:36 turris netifd: lte (31137): Starting network lte
Sep 12 01:05:36 turris netifd: lte (31137): Setting up wwan1
Sep 12 01:05:36 turris netifd: Interface 'lte' is now up
Sep 12 01:05:36 turris netifd: Network device 'wwan1' link is up
Sep 12 01:05:36 turris netifd: Network alias 'wwan1' link is up
Sep 12 01:05:36 turris netifd: Interface 'lte_4' is enabled
Sep 12 01:05:36 turris netifd: Interface 'lte_4' has link connectivity
Sep 12 01:05:36 turris netifd: Interface 'lte_4' is setting up now
Sep 12 01:05:36 turris netifd: lte_4 (31296): udhcpc: started, v1.30.1
Sep 12 01:05:36 turris netifd: lte_4 (31296): udhcpc: sending discover
Sep 12 01:05:36 turris netifd: lte_4 (31296): udhcpc: sending select for 10.238.127.188
Sep 12 01:05:36 turris netifd: lte_4 (31296): udhcpc: lease of 10.238.127.188 obtained, lease time 7200
Sep 12 01:05:36 turris netifd: Interface 'lte_4' is now up
@hyc Out of curiosity, did you check QMI yourself? And do you understand the difference between the two?
1 Like
Originally yes, I tried QMI too but it wasn’t well supported back then.
It sounds to me like you never got your modem into MBIM mode, since QMI is the default.
The main difference is that QMI is proprietary to Qualcomm, and MBIM is meant to be an industry standard.
@hyc I see. I’m open to using MBIM. But how do I set the modem into MBIM mode? The guide on Austrian forum doesn’t say anything about it. As if MBIM mode was “automatic” for them - but it doesn’t appear to be a case for me.
You have to use the usbcomp command, instructions are here https://gist.github.com/Juul/e42c5b6ec71ce11923526b36d3f1cb2c
Thanks! I see it now. The guide on AT forum mentiioned usbcomp command - but only for EM7565, and not for MC7455. That’s why I missed it. I’ll play with MBIM next week.
Hi @hyc you seem fluent with the Lte modems on openwrt. I am still stack with the quectel EC20 (no MBIM option afaik) and it’s connection issues on omnia. For a little while, I bypassed the issues by using a script to reset the modem if connection was lost (echo -e "AT+CFUN=1,1" > /dev/ttyUSB2).
For few days now, the modem is stack at reseting and no other transition is acceptable other than reset.
Any idea how to get it out of reset mode without power-cycling the router? Thanks.
Summary
root@turris:~# qmicli -d /dev/cdc-wdm0 --device-open-qmi --nas-get-system-info
[/dev/cdc-wdm0] Successfully got system info:
GSM service:
Status: 'none'
True Status: 'none'
Preferred data path: 'no'
WCDMA service:
Status: 'none'
True Status: 'none'
Preferred data path: 'no'
LTE service:
Status: 'none'
True Status: 'none'
Preferred data path: 'no'
Registration restriction: 'unrestricted'
SIM reject info: 'unavailable'
root@turris:~# qmicli --device=/dev/cdc-wdm0 --uim-get-card-status
[/dev/cdc-wdm0] Successfully got card status
Provisioning applications:
Primary GW: session doesn't exist
Primary 1X: session doesn't exist
Secondary GW: session doesn't exist
Secondary 1X: session doesn't exist
Slot [1]:
Card state: 'error: possibly-removed (6)
UPIN state: 'not-initialized'
UPIN retries: '0'
UPUK retries: '0'
root@turris:~# qmicli -d /dev/cdc-wdm0 --uim-sim-power-on=1
[/dev/cdc-wdm0] Successfully performed SIM power on
root@turris:~# qmicli --device=/dev/cdc-wdm0 --uim-get-card-status
[/dev/cdc-wdm0] Successfully got card status
Provisioning applications:
Primary GW: slot '1', application '1'
Primary 1X: session doesn't exist
Secondary GW: session doesn't exist
Secondary 1X: session doesn't exist
Slot [1]:
Card state: 'present'
UPIN state: 'not-initialized'
UPIN retries: '0'
UPUK retries: '0'
Application [1]:
Application type: 'usim (2)'
Application state: 'ready'
Application ID:
xx:00:00:00:87:10:02:FF:xx:FF:FF:89:xx:0B:00:xx
Personalization state: 'ready'
UPIN replaces PIN1: 'no'
PIN1 state: 'disabled'
PIN1 retries: '3'
PUK1 retries: '10'
PIN2 state: 'enabled-not-verified'
PIN2 retries: '3'
PUK2 retries: '10'
root@turris:~# qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode
[/dev/cdc-wdm0] Operating mode retrieved:
Mode: 'reset'
HW restricted: 'no'
root@turris:~# qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode=offline
error: couldn't set operating mode: QMI protocol error (60): 'InvalidTransition'
root@turris:~# qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode=online
error: couldn't set operating mode: QMI protocol error (60): 'InvalidTransition'
root@turris:~# qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode=low-power
error: couldn't set operating mode: QMI protocol error (60): 'InvalidTransition'
root@turris:~# qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode=reset
[/dev/cdc-wdm0] Operating mode set successfully
root@turris:~# qmicli -d /dev/cdc-wdm0 --device-open-qmi --nas-get-system-info
[/dev/cdc-wdm0] Successfully got system info:
GSM service:
Status: 'none'
True Status: 'none'
Preferred data path: 'no'
WCDMA service:
Status: 'none'
True Status: 'none'
Preferred data path: 'no'
LTE service:
Status: 'none'
True Status: 'none'
Preferred data path: 'no'
Registration restriction: 'unrestricted'
SIM reject info: 'unavailable'
root@turris:~# qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode
[/dev/cdc-wdm0] Operating mode retrieved:
Mode: 'reset'
HW restricted: 'no'
root@turris:~#
Have you tried using the usbreset command instead, to force a hardware reset of the modem?
Yes, I tried but it doesn’t help
Thanks for sharing AT+CFUN=1,1. You saved my day. I was stuck in a situation where the official proto-qmi couldn’t connect:
# uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,36 --start-network --apn broadband --auth-type none --autoconnect
"No effect"
# uqmi -s -d /dev/cdc-wdm0 --get-data-status
"disconnected"
# uqmi -d /dev/cdc-wdm0 --get-current-settings
"Out of call"
At the same time, the modem itself was logged in to the network:
# uqmi -s -d /dev/cdc-wdm0 --get-serving-system
{"registration":"registered","plmn_mcc":310,"plmn_mnc":410,"plmn_description":"AT&T","roaming":false}
Nothing worked, including usbreset and even power cycling. But your AT+CFUN=1,1 fixed the thing immediately. Thanks!
Hi,
AT+CFUN=1,1 is mentioned in the AT commands manual of the EC20.
Its been now 10 days that I am using qmicli to troubleshoot modem and card errors. This is the best tool that I used so far. Just do not use it with serial console (minicom, picocom etc) at the same time.
In my case the connection issues of EC20 seem to originate mostly from the (omnia) sim card holder. Its seems that the sim is getting powered off causing disconnections. I have also seen usb disconnections in the omnia logs.
For the moment I am using watchcat to check the status of the connection and power on the sim using qmicli though I would prefer to have a specific script (but I am not that advanced).
Can you share dmesg or logread output related to SIM card disconnects? So that when I see something similar, I know what it is.
Please share all the commands you use and I’ll write an automated script for you. Gotta help each other!
@hyc @lampra Do you guys know why there’s always two devices /dev/cdc-wdm0 and /dev/cdc-wdm1, but only one of them is functional in a sense only one can obtain actual Internet connection? I had to configure two interfaces in my OpenWRT - lte1 and lte2 - because I could never predict which one was the “right” one to use.
No idea. I only have /dev/cdc-wdm0 on mine.
This is a bit tricky. When Lte interface is setting up, you do have a log
2020-09-18 18:33:10 notice netifd[]: Lte (3062): SIM not initialized
But when the sim is powered off during the connection there is no log.
The only reliable way according to my little experience is to use qmicli
Here is the output of qmicli when sim is powered off and on:
Summary
root@turris:~# qmicli --device=/dev/cdc-wdm0 --uim-get-card-status
[/dev/cdc-wdm0] Successfully got card status
Provisioning applications:
Primary GW: session doesn't exist
Primary 1X: session doesn't exist
Secondary GW: session doesn't exist
Secondary 1X: session doesn't exist
Slot [1]:
Card state: 'error: possibly-removed (6)
UPIN state: 'not-initialized'
UPIN retries: '0'
UPUK retries: '0'
root@turris:~# qmicli -d /dev/cdc-wdm0 --uim-sim-power-on=1
[/dev/cdc-wdm0] Successfully performed SIM power on
root@turris:~# qmicli --device=/dev/cdc-wdm0 --uim-get-card-status
[/dev/cdc-wdm0] Successfully got card status
Provisioning applications:
Primary GW: slot '1', application '1'
Primary 1X: session doesn't exist
Secondary GW: session doesn't exist
Secondary 1X: session doesn't exist
Slot [1]:
Card state: 'present'
UPIN state: 'not-initialized'
UPIN retries: '0'
UPUK retries: '0'
Application [1]:
Application type: 'usim (2)'
Application state: 'ready'
Application ID:
xx:00:00:00:87:10:02:FF:xx:FF:FF:89:xx:0B:00:xx
Personalization state: 'ready'
UPIN replaces PIN1: 'no'
PIN1 state: 'disabled'
PIN1 retries: '3'
PUK1 retries: '10'
PIN2 state: 'enabled-not-verified'
PIN2 retries: '3'
PUK2 retries: '10'
That is why I cant rely on the logs to check Lte connection status as it will take (in my case) 1 hour for the interface to try to renew the dhcp ip.
I use ping (through watchcat) to ping google dns every 2 minutes and if ping fails for 3 consecutive times i use qmicli to power on the sim (qmicli -d /dev/cdc-wdm0 --uim-sim-power-on=1). A script could use ping to check the connection status, and if ping fails, to check the sim state (qmicli --device=/dev/cdc-wdm0 --uim-get-card-status) before powering the sim on.
PS: An other source of disconnections in my case is usb disconnections. After re-connection the sim is not always powered on.
Logs of usb disconnection and re-connection:
Summary
2020-09-22 18:43:40 info kernel[]: [346227.937359] usb 1-1: USB disconnect, device number 2
2020-09-22 18:43:40 info kernel[]: [346227.942652] qcserial ttyUSB0: Qualcomm USB modem converter now disconnected from ttyUSB0
2020-09-22 18:43:40 info kernel[]: [346227.951004] qcserial 1-1:1.0: device disconnected
2020-09-22 18:43:40 info kernel[]: [346227.956806] qcserial ttyUSB1: Qualcomm USB modem converter now disconnected from ttyUSB1
2020-09-22 18:43:40 info kernel[]: [346227.965085] qcserial 1-1:1.1: device disconnected
2020-09-22 18:43:40 info kernel[]: [346227.970366] qcserial ttyUSB2: Qualcomm USB modem converter now disconnected from ttyUSB2
2020-09-22 18:43:40 info kernel[]: [346227.978647] qcserial 1-1:1.2: device disconnected
2020-09-22 18:43:40 info kernel[]: [346227.983944] qcserial ttyUSB3: Qualcomm USB modem converter now disconnected from ttyUSB3
2020-09-22 18:43:40 info kernel[]: [346227.992271] qcserial 1-1:1.3: device disconnected
2020-09-22 18:43:40 notice netifd[]: Network device 'wwan0' link is down
2020-09-22 18:43:40 notice netifd[]: Network alias 'wwan0' link is down
2020-09-22 18:43:40 notice netifd[]: Interface 'Lte_4' has link connectivity loss
2020-09-22 18:43:40 info kernel[]: [346228.000597] qmi_wwan 1-1:1.4 wwan0: unregister 'qmi_wwan' usb-f1058000.usb-1, WWAN/QMI device
2020-09-22 18:43:41 notice netifd[]: Lte_4 (9354): udhcpc: SIOCGIFINDEX: No such device
2020-09-22 18:43:41 notice netifd[]: Lte_4 (9354): udhcpc: received SIGTERM
2020-09-22 18:43:41 notice netifd[]: Interface 'Lte_4' is now down
2020-09-22 18:43:41 notice netifd[]: Interface 'Lte_4' is disabled
2020-09-22 18:43:41 notice netifd[]: Lte (26933): Stopping network Lte
2020-09-22 18:43:41 notice netifd[]: Lte (26933): Command failed: Permission denied
2020-09-22 18:43:41 notice netifd[]: Interface 'Lte' is now down
2020-09-22 18:43:51 info kernel[]: [346238.196313] usb 1-1: new high-speed USB device number 3 using orion-ehci
2020-09-22 18:43:51 info kernel[]: [346238.415114] qcserial 1-1:1.0: Qualcomm USB modem converter detected
2020-09-22 18:43:51 info kernel[]: [346238.421949] usb 1-1: Qualcomm USB modem converter now attached to ttyUSB0
2020-09-22 18:43:51 info kernel[]: [346238.429553] qcserial 1-1:1.1: Qualcomm USB modem converter detected
2020-09-22 18:43:51 info kernel[]: [346238.437202] usb 1-1: Qualcomm USB modem converter now attached to ttyUSB1
2020-09-22 18:43:51 info kernel[]: [346238.444765] qcserial 1-1:1.2: Qualcomm USB modem converter detected
2020-09-22 18:43:51 info kernel[]: [346238.451624] usb 1-1: Qualcomm USB modem converter now attached to ttyUSB2
2020-09-22 18:43:51 info kernel[]: [346238.459131] qcserial 1-1:1.3: Qualcomm USB modem converter detected
2020-09-22 18:43:51 info kernel[]: [346238.465838] usb 1-1: Qualcomm USB modem converter now attached to ttyUSB3
2020-09-22 18:43:51 info kernel[]: [346238.473767] qmi_wwan 1-1:1.4: cdc-wdm0: USB WDM device
2020-09-22 18:43:51 info kernel[]: [346238.479510] qmi_wwan 1-1:1.4 wwan0: register 'qmi_wwan' at usb-f1058000.usb-1, WWAN/QMI device,
Since yesterday, I had a new disconnection but this time, the modem was not responding to qmicli or uqmi commands, only AT commands.
Usbreset did not help, connection and functionality restored using AT+CFUN=1,1
What is your ISP? Maybe AT&T in the US?
Nope, WIND in Greece.