i want get imsi data in oopnwrt by uqmi command from quectel ec25
but after send this command :
uqmi -d /dev/cdc-wdm0 --get-imsi
result is
"Not supported"
How can I fix this problem?
I'm getting this too. Also with --get-iccid, not supported. From the source code it appears that there has been a single patch to uqmi in the last 2 years. Is it safe to say that this is now abandonware?
Those QMI DMS requests are not supported by modern modems. That's not a uqmi problem. The requests work fine with older modems.
AFAIK, you have to read the IMSI and ICCID using the QMI UIM read-transparent requests now. See instructions here:
https://techship.com/faq/how-to-acquire-imsi-and-iccid-from-cellular-module-using-libqmi-command-line-tool-qmicli-in-linux-systems/
This request isn't implemented in uqmi yet. Probably because no one has been interested enough to write the code. This doesn't mean that uqmi is abandoned in any way. There are lots of tiny bits and pieces of OpenWrt with limited developer resources. It's still maintained.
Hey bmork, thanks for the update. I guess there's always the new modemmanager package but that's quite large for most OpenWrt targets. AT commands provide a hacky stopgap for the meantime
Off the top of your head, what would you say would be the difficulty of getting these functions working for uqmi?
Not difficult at all. Just work. All QMI messages are the same. Implementing one means
- Parse input parameters into message specific TLVs
- Parse reply TLVs
- Present result as json
It is pretty simple. And equally boring 
1 Like
I would be interested in doing that. I believe I find the code on github? Do you have a document describing how to set up the cross-build tool chain for my particular flavour of ARM (MediaTek 7620A)?
I was bitten by a serious concurrency issue in uqmi when I wrote a script that repeatedly uses uqmi to learn the signal strength, in order to change LED behaviour to reflect that. When during startup the interface goes up, uqmi is called to establish the connection. If the script calls uqmi at the same time the two processes lock up, the interface never comes up. I worked around with a wrapper script for now, but a proper fix within uqmi would be so much better of course.
It's probably somewhere on github too, but the main repo is here:https://git.openwrt.org/?p=project/uqmi.git;a=summary
Just follow the OpenWrt developer instructions. It will set up the toolchain for you. There is a simple guide on how to use it for cross-building outside OpenWrt here:.https://openwrt.org/docs/guide-developer/crosscompile
But I would just build the uqmi package.
It might be easier to build and test on an x86 system while developing, since you can skp the install step. If you have an x86 Linux system with a QMI modem. Note that it doesn't have to run OpenWrt. uqmi runs just fine on any Linux system. But you need to build libubox first if you are going to do that.
I do not. However, I do not consider that a big deal, as - what I can see - it seems sufficient to just copy over the executable, for which a simple scp is enough.
Installing the build system according to https://openwrt.org/docs/guide-developer/build-system/install-buildsystem is a rather rough experience. Apart from the bloat (the prerequisite "asciidoc" alone uses close to half a gigabyte of disk space), certain setups appear not to work right. Specifically the make target "prereq" complains about lots of missing libraries even though the libraries are installed and in plain sight. Example
WARNING: Makefile 'package/utils/busybox/Makefile' has a dependency on 'libpam', which does not exist
$ dpkg -s libpam0g
Package: libpam0g
Status: install ok installed
...
$ dpkg -s libpam0g-dev
Package: libpam0g-dev
Status: install ok installed
...
$ ls -l /lib/x86_64-linux-gnu/libpam.*
lrwxrwxrwx 1 root root 16 May 27 2017 /lib/x86_64-linux-gnu/libpam.so.0 -> libpam.so.0.83.1
-rw-r--r-- 1 root root 56016 May 27 2017 /lib/x86_64-linux-gnu/libpam.so.0.83.1
The same complaint about half a dozen other libraries.
I'm stuck for now.
You can ignore the WARNING: Makefile 'xxx' has a dependency on 'yyy', which does not exist warnings, they refer to packaging specific details, not related to your host system in any way.
Also asciidoc as prereq sounds odd, I never needed to install it. Wonder who did put it there...