LTE modem support for Beryl (GL-MT1300)

[XJIbIH]

Dear developers, The router is positioned as a mobile travel device. This assumes that the router will often be used with an LTE modem. However, the proprietary interface in its current state will not allow you to do this! He’s not ready for this …

I ask you to configure your proprietary web interface to configure network interfaces for LTE modems using the QMI protocol.
All required packages are available in Openwrt.

Here is a brief instruction for configuring the network interface for LTE modems using the QMI protocol via an SSH terminal:
In /etc/opkg.conf comment out the option check_signature line
In /etc/opkg/customfeeds.conf add
src / gz 132lan_luci http://openwrt.132lan.ru/packages/packages-19.07/luci
src / gz 132lan_app http://openwrt.132lan.ru/packages/packages-19.07/mipsel_24kc/packages
Required packages for work:
opkg update && opkg install kmod-usb-serial-option minicom usbutils uqmi (or modemmanager - I prefer it for displaying the choice of LTE bands).
For LuCi, you can still install the luci-proto-qmi package or luci-proto-modemmanager
Can be done via ssh or LuCi, there is no difference.
Install:
opkg update && opkg install luci-app-modeminfo luci-app-smstools3 luci-app-atinout luci-app-mmconfig
For the Russian language, still put:
opkg install luci-i18n-modeminfo-ru luci-i18n-smstools3-ru luci-i18n-atinout-ru luci-i18n-mmconfig-ru
For other languages, install the appropriate package.
We reboot the device.
We establish that the modem is detected in the device
Log in to the device again and issue commands in the SSH terminal:
lsusb && ls / dev / cdc- *
in response, you should see, among other things:
/ dev / cdc-wdm0

Connection to a mobile operator.
Turn off the device, insert the SIM card, turn on the device.
If you installed the uqmi package:
Log into the router via SSH and edit / etc / config / network adding the following network interface to it:
config interface ‘wwan’ (or LTE or whatever)
option device ‘/ dev / cdc-wdm0’
option proto ‘qmi’
option delay ‘30’
option delegate ‘0’

If you installed the modemmanager package:
config interface ‘LTE’
option proto ‘modemmanager’
option iptype ‘ipv4v6’
option auth ‘none’
option signalrate ‘30’
option device ‘/sys/devices/platform/1e1c0000.xhci/usb2/2-1/2-1.3’ (or another value that matches your modem)

The same manipulations can be done through the Luci web interface.
The connection is configured, add the wwan interface (or whatever you call it) to the WAN zone in the firewall of the device and enjoy the mobile internet. Execute reload_config or reboot the device.
You can verify that the interface is up and configured.
: ~ # ifconfig
wwan0 Link encap: UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr: 10.71.86.16 P-t-P: 10.71.86.16 Mask: 255.255.255.224
inet6 addr: fe80 :: 2754: fc8a: c9c6: 2ae4 / 64 Scope: Link
UP POINTOPOINT RUNNING NOARP MULTICAST MTU: 1500 Metric: 1
RX packets: 25726 errors: 0 dropped: 0 overruns: 0 frame: 0
TX packets: 31289 errors: 0 dropped: 0 overruns: 0 carrier: 0
collisions: 0 txqueuelen: 1000
Then you can configure all the necessary parameters for your LTE modem in the “Modem” tab.

All this works fine in Luci, but it does not work at all in the proprietary web interface. Implement this and there will be happiness for many users!

[elorimer]

Nice guide to implementing this. I think the Beryl is a poor choice for this use case though, because of the power draw. I think of it as a travel router that you take to places you travel to, not as a router that you take for while you are traveling. A Mudi would be better, no?

Smartphone tethering works for me for places where I am that don’t have internet service.

[alzhao]

From the packages you mentioned, it is just tools and interfaces. The driver is already there.

I am not sure why qmi does not work.

[XJIbIH]

QMI works … The proprietary interface does not work. It is impossible to set up a connection from a proprietary interface using the QMI protocol, only from Luci and an SSH terminal. The question to the developer is just this.

[makino16]

They don’t do that because different carriers and modules require different steps.
Even if they add multifunctional GL UI, some modules will not work reliably. And, it is not possible to provide comprehensive support for carriers and LTE modules around the world.

As a premise, they sell many routers as devices that only work with the few modem and operator combinations listed in the documentation.
But at the same time, they allow users to handle unsupported features at user’s own risk.
As a result, the user can connect any modem, returning half-hearted errors and occasionally success. That is a huge benefit for users.

This also applies when configuring Wi-Fi dongles and WANs.
Obviously some of the web UI that should exist are missing for similar reasons.
We can get a lot of user reports from this forum and Google, but they are not guaranteed by the manufacturer.
And at least they make it clear on the manufacturer’s site and documentation.

---

…I think this is the case, but I personally don’t like it. Rather than GL-iNet, @XJIbIH suggestion +1

I think the reason some users are having many problems and struggling more than expected is that the explanation is inadequate and consumers don’t understand the scope of the warranty.

At the very least, GL-iNet products in the past have been favored by tech-savvy geeks.
But now, their routers are gaining a lot of support in the market, and more consumers are choosing their products over the well-known manufacturers

However, consumers who aren’t interested in technology often just want everything to work as expected and don’t want to build the functionality themselves.
And if they encounter an error that is reproducible and not announced by the manufacturer as a defect, the consumer simply determines that it is a manufacturer’s blunder.

Therefore, they “don’t create” a WebUI with features that aren’t sure to work, so that users with skill levels below minimum required don’t deviate from the warranty.
But in reality, it seems that many consumers still using and bricking without understanding the advanced features.

It seems like a bad buying experience for that person, and this forum have more boring topics, and it also affect Alzhao’s motivation (important!)

In short, many warnings need to be implemented to prevent consumers from touching dangerous features.
For example, when you open a plugin, firewall, LuCI, etc., it pops up a checkbox that you understand is a dangerous feature and agrees to use at your own risk.

After that, I think it’s a good idea to add a web UI that follows the suggestions in this topic. Depending on privacy policy, you can also collect statistics to find out where they are likely to make mistakes.

[XJIbIH]

I agree with your arguments. However, it is not about technical guarantees and consumer information. The functionality I have specified works without any problems on the device. All that is required from the manufacturer is to link this functionality with its proprietary interface. For me personally, there are no problems to implement the functionality I need, which is present in Openwrt via Luci or SSH terminal. But not all users can afford it.

[makino16]

I totally agree!
The claim that “we should add a Web UI for tech-savvy users”, and The claim that “the Web UI, which is dangerous for consumers to use should be removed” isn’t conflict.
After all, they’re just struggling to be accountable as a company.

The problem for users is that they are reluctant to extend the GL UI until they improve the situation, and the only alternatives are LuCI and ssh.
LuCI is just a slightly nice looking CUI that only supports dependent modules. Relying on it is synonymous with losing most of the benefits of the GL-iNet kernel… unacceptable.
But there is no option to wait years for them to come, it’s worthless to the current product.

If there is a recommended procedure for creating a custom page for GL UI, I think that an active approach is possible from users.
You don’t have to let users use Vue. Declare the static .html file path ( /www/src/static/... ) via UCI. And router.js will make an unconditional jump during authentication. This is easier to control accessibility.
Also, it’s a silver bullet for some Web UI that were avoided due to edge case concerns, as it’s obvious to everyone that it’s out of GL-iNet warranty.

As a more advanced idea, we recommend providing a place like “GL UI hub” where users can commit and share custom resources.
It’s pretty simple enough, but it must be provided by GL-iNet, not me or anyone else, for centralized security.
The minimum configuration is a versionable Ash script file uploader, or a public repository via git or etc.
Currently, the only “official” resource management method available to users is attachment to post on web forums, so it is highly volatile.
Useful things may not spread, or similar things may be made repeatedly, or it’s a trap for persons who get lost in past topics.