You probably have to set the interface to raw-ip. Most newer modems don't support 802.3 framing. The ModemManager proto would have done this for you if you used it. Try
echo Y >/sys/class/net/wwan0/qmi/raw_ip
The netdev must be down when you do this, but the modem can be connected if you like.
Thank you bmork, that was exactly it. I think I might try to do my own logic just for the pin id and then just handover to proto to manage.
How can I install luci-proto-modemmanager on OpenWrt 19?
root@OpenWrt:~# opkg update
Downloading http://downloads.openwrt.org/releases/19.07.3/targets/ramips/mt7620/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_core
Downloading http://downloads.openwrt.org/releases/19.07.3/targets/ramips/mt7620/packages/Packages.sig
Signature check passed.
Downloading http://downloads.openwrt.org/releases/19.07.3/targets/ramips/mt7620/kmods/4.14.180-1-18384755d38fc43c447d83d4a3e07054/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_kmods
Downloading http://downloads.openwrt.org/releases/19.07.3/targets/ramips/mt7620/kmods/4.14.180-1-18384755d38fc43c447d83d4a3e07054/Packages.sig
Signature check passed.
Downloading http://downloads.openwrt.org/releases/19.07.3/packages/mipsel_24kc/base/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_base
Downloading http://downloads.openwrt.org/releases/19.07.3/packages/mipsel_24kc/base/Packages.sig
Signature check passed.
Downloading http://downloads.openwrt.org/releases/19.07.3/packages/mipsel_24kc/luci/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_luci
Downloading http://downloads.openwrt.org/releases/19.07.3/packages/mipsel_24kc/luci/Packages.sig
Signature check passed.
Downloading http://downloads.openwrt.org/releases/19.07.3/packages/mipsel_24kc/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_packages
Downloading http://downloads.openwrt.org/releases/19.07.3/packages/mipsel_24kc/packages/Packages.sig
Signature check passed.
Downloading http://downloads.openwrt.org/releases/19.07.3/packages/mipsel_24kc/routing/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_routing
Downloading http://downloads.openwrt.org/releases/19.07.3/packages/mipsel_24kc/routing/Packages.sig
Signature check passed.
Downloading http://downloads.openwrt.org/releases/19.07.3/packages/mipsel_24kc/telephony/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_telephony
Downloading http://downloads.openwrt.org/releases/19.07.3/packages/mipsel_24kc/telephony/Packages.sig
Signature check passed.
root@OpenWrt:~# opkg install luci-proto-modemmanager
Unknown package 'luci-proto-modemmanager'.
Collected errors:
* opkg_install_cmd: Cannot install package luci-proto-modemmanager.
Seems like there's not built package for 19.07.3. So I tested with the snapshot package; https://downloads.openwrt.org/snapshots/packages/mipsel_24kc/luci/luci-proto-modemmanager_git-20.192.38347-29edc02_all.ipk and it worked 
PR's welcome 
I have a few questions about the roadmap of luci-proto-manager and what is available in ModemManager/libqmi:
I don't know anything about the luci-proto-modemmanager plans, but am a bit worried about the limited exposure the features you propose would have. Features without users will eventually detoriate and become useless. in my experience.
There are a limited number of LTE/3G/5G users on OpenWrt. Very few of them are using ModemManager. And some of those aren't using Luci. The number of users are too few to ensure full feature testing coverage already here. Then let's say we add PUK entry. How many users are actually going to need that? You're "lucky" if there is one at all. And image selection? That's very modem specific. There might be a couple of users with an MC7455 or similar, but they probably already flashed and selected the image they want to use. It's not like it's something you do all the time for normal usage. And double SIM? There are very few users who have the hardware support for that. And most of those probably won't use it. It's not very useful for a stationary WAN link, which I assume is most common to OpenWrt users. It might be useful for those having a mobile OpenWrt installation. But that is probably a very limited number of users.
But if you can take on the testuser and developer role for these feaures, then I am sure pacthes are accepted as always
Hi,
I don't think "There is a limited number of LTE / 3G / 5G users on OpenWrt" is true.
I know many people who have turned to LTE internet connection due to the surprisingly poor cable connection. In fact, I am one of them.
I am a member of a community where all members use LTE / 4G home connection 24/7, and considering we are more than 1000 members limited to my country it makes me think there could be many uses for such features.
There are a lot of choices available of embedded systems that support m.2 or PCIe modems and people are really interested in finding open solutions because they are really cheaper and more featured than branded ones.
Unfortunately, the lack of ease of configuration and stability in managing protocols for 4G / LTE modems is a strong incentive to avoid the OpenWrt solution.
So I really thank those who went out of their way to develop packages like this, indeed I hope they continue to maintain and improve it over time
OK, I do not have any numbers to back up my statement, so my impression could definitely be wrong. And I definitely agree that the number of users is going to increase, with 5G fixed wireless access pretty much replacing DSL over the next few years.
Sure. I could not agree more.
And I do understand that modem firmware upgrade might be a required feature. The reason I consider the number of users limited wrt that is because it's a much more hardware specific feature than the rest of the modem management. MBIM and QMI hides most of the differences between modems, making an old D-Link 3G modem behave pretty much the same as a modern Quectel 5G modem. I believe this is one of our major success stories. Qualcomm always have pushed a new driver per modem with minor differences. It was Microsoft who forced them to accept MBIM. But we managed to make the same qmi_wwan driver support all of the Qualcomm modems. And that's not just across vendors, but also across chip generations with support for anything from the 1st generation Gobi1k of 2007 to the most powerful 5G modems of 2020.
But if you are going to support firmware upgrades, then you don't have this advantage. Every modem is different. And it's not just about different firmwares. All vendors user their own scheme. A vendor like Sierra Wireless has changed upgrade protocols 3 times over their last 4 modem generations. The number of OpenWrt users running the same firmware upgrade code is going to be low for most modems. This implies very limited testing. Given the possible errors, the risk analysis is not looking good.
Note that although I have written qmi_wwan and cdc_mbim and added support for the gazillion different modems they support, I still don't own more than 10 (or so) modems myself. And I'm only ever upgraded one of them on OpenWrt and 3 different modems in total on Linux. I definitely do not feel like supporting firmware upgrades in general.
As for PUK code entry, that is a procedure shared between all the modems. The reason I still think it's hard to get proper exposure is that it's not something you ever need to do. When you configure an interface with a PIN enabled SIM, then you either enter the correct code or you don't. If you enter the wrong code, then you fix that. Then you don't change that interface configuration again. It's very hard to get yourself into a situation where you would need the PUK code on OpenWrt. And even if it happens, it's probably easier to temporarily move the SIM to a phone for recovery instead of figuring out where to put the PUK code in Luci. So my estimate is that you are lucky if you get one real user/tester of the feature every 10 years or so. And you will probably get 200 users every day wondering what that PUK setting is supposed to be.
Hi Vincent,
Thanks for the feedback. This is a community maintained project, which I maintain outside of my regular job. Those features are achievable with some work, although I'm not sure if they would really fit within the LuCI "proto" itself (with the possible exception of the SIM switching) - it may be better to put these and related features into a companion luci-app, such as luci-app-modemmanager, which has more status information and capability for control.
In my view, and I think other OpenWrt devs would agree, luci-proto's should only be used for managing settings relating to the connectivity of some interface. Also, it would be very hard with the current architecture, to get the proto handler to respond to events that netifd has no idea about; it's just not designed that way.
However, thanks to the amazing work done in libqmi, libmbim, qmi_wwan and ModemManager by @bmork himself, and the rest of the ModemManager team, your features are definitely doable from a seperate application, which is something I would love to look into more. If you or your company are interested in sponsoring prioritisation of those features, or a more custom solution mainly geared towards your own particular needs, please PM me for an estimate.
Just a quick comment - FW upgrades for the 3G/4G/5G modems - this is largely managed by the modem vendor in coordination with the carriers and/or PTCRB, and once approved, the OEM's can offer this up outside of the client userland...
Anyways - modemManager is still very good with managing the qmi and mbin interfaces...
I built the master but now I have problems with Dbus:
dbus[5139]: Failed to start message bus: Failed to open "/dbus-1/system.conf": No such file or directory
So I removed and reinstalled it and this is the error:
root@OpenWrt:~# mmcli -L
error: couldn't get bus: Could not connect: No such file or directory
What is this?
im seeing this also ... whats missing ?
The missing part is run testing before committing, resulting in broken packages. This is a returning issue in the OpenWrt packages repo.
The story in this case gose like:
And that's where we are now. I assume dbus will be fixed by a grown-up at some point. But the underlying problem is more serious, and it doesn't look like it is going to be fixed. I guess a fork of openwrt-packages is the only real solution.
See also http://lists.openwrt.org/pipermail/openwrt-devel/2021-April/034805.html
The same committer has a history of breaking packages, and leaving them broken for someone else to fix up Another example I stumbled across a short while ago: https://github.com/openwrt/packages/pull/14366
I'm sure there are many many more. The combination of very active, no testing, and making unrelated changes while upgrading versions, is guaranteed to introduce lots of bugs. The two examples just stand out because the bugs are so bloody obvious that you wouldn't need to do more than just installing the packages to notice.
I don't think there is any hope for the OpenWrt packages repo as long as there are commiters who are too lazy to install a package before committing.
Thanks for the insight, so then i just ran a git revert on that commit, rebuilding n ow to see how it goes.
❯ git revert 0fb5d3ed2cb31a0a6076d36fb7a668cfe5328c92
yupp, correct builds fine and works with this reversion
Has this now been fix in packages? I'm having no success with revert and my build still fails right after luci-proto-modemmanager install step.
I'm not able to make openwrt-19.07 because of "missing separator" error, what is it? I show the log:
make[2]: Entering directory '/home/mint/Scrivania/openwrt/feeds/luci_proto_modemmanager/luci-proto-modemmanager'
Makefile:54: *** missing separator. Stop.
make[2]: Leaving directory '/home/mint/Scrivania/openwrt/feeds/luci_proto_modemmanager/luci-proto-modemmanager'
time: package/feeds/luci_proto_modemmanager/luci-proto-modemmanager/download#0.12#0.03#0.17
make[1]: *** [package/Makefile:113: package/feeds/luci_proto_modemmanager/luci-proto-modemmanager/download] Error 2
make[1]: Leaving directory '/home/mint/Scrivania/openwrt'
make[1]: Entering directory '/home/mint/Scrivania/openwrt'
make[2]: Entering directory '/home/mint/Scrivania/openwrt/target/linux'
make[3]: Entering directory '/home/mint/Scrivania/openwrt/target/linux/ramips'
make[3]: Nothing to be done for 'download'.
make[3]: Leaving directory '/home/mint/Scrivania/openwrt/target/linux/ramips'
make[2]: Leaving directory '/home/mint/Scrivania/openwrt/target/linux'
time: target/linux/download#0.05#0.02#0.08
Usually in feeds, luci_proto_modemmanager is within the luci feed directory. Are you using a custom or other feed than the official luci?
~/openwrt/feeds/luci/protocols/luci-proto-modemmanager