Since receiving them (circa 2024-09-17), despite much effort to figure out what I was doing wrong (all sans InterWeb access), I've been unable to establish any meaningful connection (especially to the WAN) with the M2 I ordered.
When ordering, I specified the variant which included the QuecTel RM520N-GL module.
I followed the included setup instructions.
Having examined GL·iNet's FAQs/Troubleshooting documentation, it seems that I'm not even getting the most basic functionality. The UI of the gateway (‘router’) I have it connected to (currently an MT3000, but have also tried an AXT1800; both of which have firmware versions above the minimum required for the M2) presents as if I have no external cellular transceiver (modem’) connected at all. The display-captures (‘screenshots’) show that the Cellular section should change, even when no SIM is installed. This is not what I observe locally.
Weirdly, I'm able to talk to the M2 via minicom, and the uqmi CLI tool, to which it seems to respond somewhat normally.
The Troubleshooting documentation directed me to check some (hardware) basics, first.
While I can yield the IMEI value as expected, when I query for the ICCID (using the uqmi tool) the response is “not implemented”.
I'm suspecting some kind of hardware fault, at this point; perhaps something related to interfacing with the SIM. If this turns out to be the case, I'd like to return the faulty items for fully-functional replacements.
However, part of why I'm posting publicly is because I'm willing to (within reason) run whatever tests folks here might suggest, to at least accurately diagnose the problem.
Complications: I have very sporadic InterWeb access (scrounging a connection, very temporarily, at the moment), and thus I'll only be able to respond every couple of weeks (less over the December holidays, of course).
I'd appreciate if moderators/admins could permit this thread to remain open (as opposed to auto-closed due to inactivity) as a result.
Other possibly relevant context which I can think of: the M2 reports being able (having tried with a (borrowed) live SIM) to establish a basic (radio-link level) connection with the mobile/cellular network, and even register on the network. But, I've never been able to actually pass IP packets.
In OpenWrt/BusyBox, the wwan0 interface remains down.
I'm reluctant to acquire a live SIM for testing, until it's likely that I'll be able to achieve an InterWeb connection with it. Telephony service (especially mobile/cellular), in my area, is expensive.
While I'm new to GL·iNet's products (and somewhat OpenWrt), and mobile/cellular networking, I'm not new to general system administration (though, have limited experience with OpenWrt & BusyBox) or (non-cellular) networking.
For those who have read this far, I appreciate your attention; thankyou.
Suggestions of what else to try, most welcome. I'll respond when I'm able to.
Thanks, Bruce. Especially for the prompt response when I've been unable to reply, myself.
I've kludged together some crude access, temporarily.
As mentioned in my OP; I see no change to the UI on the ‘Internet’ tab, especially related to Cellular”. It remains as if I have no device connected at all, despite being able to communicate with it via other methods.
For clarity, the UI informs me that “No Modem device found. Plug in your USB modem to start.”
This persists regardless of whatever changes I make via minicom, such as the mode (AT+CFUN) of the radio/module. It never temporarily changes (even briefly), than I've seen, either. It always shows only the “No Modem device found. Plug in your USB modem to start.” message.
This is part of what's making me think that something low-level has failed, and basic sanity-checks aren't being passed (in order for the UI to be changed and allow GUI interaction).
Will do. What level of verbosity would you like? I presume ‘debug’/maximal.
The M2 dev board hardware has no problem, it can be recognized by the GL router and a connection is established.
However, it may be that the plugin minicom or uqmi you installed is booted faster than the GL ModemManager, which takes up ttyUSB channel, causing ModemManager to be unable to communicate with the M2 board, resulting in the GL GUI not recognizing and display of Cellular Modem.
Thankyou for your reply, and continued help, Bruce.
I'll agree that there appears to be no (obvious) problem with the USB interface, at least. However, that doesn't necessarily mean that other hardware of the board/module is fully-functional. I remain unconvinced about the whole (thus, more testing ).
I did mention, in my OP, about being able to communicate with the module over USB, using eg minicom. For example, changing its radio-mode via AT+CFUN, and setting/reading the date+time via AT+CCLK. Though, when a SIM card was installed, I couldn't get it to tell me the IMSI (but, could get the IMEI), which seemed weird to me.
But, I'm glad that we agree on this point re USB.
Regardless, even if the hardware is not faulty (which I hope to be the case), then I'm still unable to establish a WAN-link via the GL-M2 (and perhaps I need to change the title of this thread, accordingly). In that case, I have even fewer ideas about why. I tried a lot of different things before posting my OP.
I feel it important to get the facts right, to avoid faulty-assumptions and/or misdiagnosis (based on experience).
I didn't install uqmi; that's part of GL's own firmware (at least on the MT3000 (but, I can check the AXT1800, too), which is how I discovered its existence):
# opkg status uqmi | grep -i ^Installed-Time:
Installed-Time: 1725418757
# opkg status kernel | grep -i ^Installed-Time:
Installed-Time: 1725418757
Aside: I suspect (via educated guessing) that GL uses uqmi (which outputs JSON) in the backend for its Cellular UI frontend, to enable users to interact with such transceivers/modems (via the HTTP-UI, rather than only via SSH). (Which is a good idea and elegant design/implementation (not criticism).) Thus, it must be part of the firmware. (Else, how does the HTTP-UI communicate with (interrogate & command) the modem/transceiver?)
The other tools, like minicom and ModemManager, I only installed for diagnostic purposes (with a USB dongle type modem, before ordering an M2).
I'll uninstall/remove those packages, re-test, and report the results.
As per my OP:
That AXT1800 hasn't had either minicom or ModemManager installed on it, or any other (extra) packages (other than new GL firmware, not even upgrading packages via opkg), or otherwise changed the configuration (because it's the one with the non-functional 2.4GHz radio).
The AXT1800 yielded exactly the same (observed) results as the MT3000.
However, I'll re-test (capturing the syslog, this time) and report the results.
Interesting idea. Possibly.
A few thoughts;
minicom and uqmiaren't running continuously (eg as services) (and I haven't configured them to be invoked as part of the boot process (but, GL might've)); they only run when I invoke them via SSH (compare running opkg), and I only run them after the M2 has been allowed to boot & stabilise
ModemManager isn't/wasn't installed as part of GL's firmware (thus, isn't (depended upon for|a dependency of/for) GL's UI; see above re my guess that GL actually uses uqmi in the backend); I installed ModemManager manually for diagnostic purposes (# opkg status modemmanager | grep -i ^Installed-Time:[\n]Installed-Time: 1728907164 (versus # opkg status kernel | grep -i ^Installed-Time:[\n]Installed-Time: 1725418757))
I'm wondering if ModemManagermight be causing the type of interference you describe (or similar). I can't recall if I tested the M2 with ModemManager uninstalled/removed, so I'll (re-)perform that test, and report the results. — I vaguely recall seeing, in the past, syslog messages about some problem with the ttyUSB devices/interfaces. However, that doesn't account for the same results on the AXT1800, which has never had ModemManager installed.
Re my conjecture about dependencies (clearer here, like this, rather than in a(n unordered) list):
# opkg whatdepends modemmanager
Root set:
modemmanager
What depends on root set
luci-proto-modemmanager git-22.046.84868-a7b0fe1 depends on modemmanager
versus
# opkg whatdepends uqmi
Root set:
uqmi
What depends on root set
gl-sdk4-modem git-2024.179.42655-495765a-1 depends on uqmi
gl-sdk4-ui-sms git-2024.170.23619-96e7a91-1 depends on gl-sdk4-modem
gl-sdk4-sms-forward git-2023.205.14181-f7e453d-1 depends on gl-sdk4-modem
I'll re-test without ModemManager.
ModemManager isn't/wasn't installed as part of GL's firmware (thus, isn't (depended upon for|a dependency of/for) GL's UI. I installed ModemManager manually for diagnostic purposes (# opkg status modemmanager | grep -i ^Installed-Time:[\n]Installed-Time: 1728907164 (versus # opkg status kernel | grep -i ^Installed-Time:[\n]Installed-Time: 1725418757))
ModemManager is, to my understanding, (part of|from) OpenWrt, rather than GL.iNet
see my earlier point about uqmi being included in/with GL's firmware, and I think is the backend tool behind the Cellular (HTTP-)UI
Could it be confirmed, with the developers, how GL's Cellular UI talks to the GL-M2? That should help narrow down the possibilities for testing/diagnosis.
I'll do a variety of (re-)testing, and report the significant findings. (This might take me a while, because I'll have to reconfigure various things (perhaps multiple times), in order to talk to both boxes (to maintain InterWeb connectivity).)
Unless, of course, ModemManager is taking over (control), instead(?)
My understanding is that ModemManager's purpose is (mostly) for providing an easier configuration interface in (OpenWrt's) LuCI.
In any case, I have another MT3000 and AXT1800 (I have 2 of each), which haven't been changed (not even firmware upgrades), other than testing their hardware. They've never had a route to the InterWeb, either, so are very unlikely to be compromised in any way. If needs be, I could use those as a clean/fresh environment for testing.
I'm unsure what “LPM” is. Link Power Management (of the USB host-controller)?
What's the significance of (highlighted) line #495?
Just in case it might be relevant (noticing the mention of latency);
I have a USB hub between the MT3000 and the GL-M2.
Forgot to mention that, either earlier or in the contextual notes via PM; sorry.
The hub is used/needed, because;
currently, I'm connecting to the InterWeb via a USB-tethered phone; so need multiple USB-ports to test the M2 at the same time
I'll likely want to connect other USB devices, in future
It also makes equipment layout/positioning easier.
But, the USB connection/interface doesn't seem to be (the cause of) the problem. I certainly don't see how a hub would make any difference.
If it's not about line #495 (maybe that's just where your cursor happened to be), but about the section of the log, showing that ttyUSB devices were being removed/disconnected; that's likely because (as mentioned via PM) I had the M2 reboot a few times (commanding it to do so via uqmi), in order to ensure capture of the entire boot/connect process.
Given the timing (17:26Z, because I exported the syslog at 17:29Z), this is likely one of the times when it was rebooting (as I'd instructed it to do). Notice, in the same image;
line #492, the whole /dev/cdc-wdm0 device (the M2's network interface) disappears — this only happens (in my observations) when rebooting the M2. Otherwise, in terms of the USB interface, the M2 is very stable (I've never seen an uncommanded/spontaneous reboot), even when I've had it powered+idling for months.
on line #494, ~11 seconds later, it's starting its boot process again
later on (circra line #497 & #507) as part of that (re)boot process, the ttyUSB devices/interfaces are (re-)established. — Toward the end of the log (~17:29Z was when I exported it), when I'm no longer telling it to reboot, they should remain stable (as I observe them to be in my experience; I can readily/reliably connect to them via minicom whenever the M2 is powered+running)
For clarity (and whoever might read this in future), the notes I included in my PM, which attached the exported syslog files (‘logread.tar’), was:
If others would like to see non-sensitive (viz. privacy(location), unique IDs (MAC addresses), security) parts the original syslog export, I preserved them.
Ah.
I'm reluctant to do this with the MT3000, because:
I need to preserve various (important) configuration
it's in service for me connecting to the InterWeb currently
However, I'm quite willing to do it with the AXT1800 (which has no (important) configuration changes, and otherwise isn't in service), and effectively already have by upgrading firmware without keeping configuration.
So, I'm thinking that it'd be simpler to do all future testing of the M2 via the AXT1800, rather than the MT3000.
I'll do the necessary work, and (re-)testing, and report back with my findings.
Given this last request (firmware reset), I'm inclined to try doing this test (‘does the same problem happen on a clean, firmware-only system?’) first. Because, if it persists on a clean system, then much of the other testing (about details) becomes moot.
From memory (as an early FYI), the problem always persisted, even on the AXT1800 after upgrading firmware without keeping any configuration (so, a clean install; confirmed by the SSH host-keys changing), and changing nothing (neither configuration, nor packages) prior to testing. But, I'll retry/retest, to confirm (either way).
This is going to become an interesting rabbit-hole to dive down, methinks .
I better get started. I probably won't have anything before tomorrow (it's 17:16, here, now).
Again, thankyou for the time & attention in diagnosing this problem.
Compliment: this level of (technical-)support encourages me to continue being a customer of GL·iNet, in future (buying new products), in addition to the high-quality of the products themselves (which is very good for the size and price of them). It's noticed and appreciated. Feel free to bring this to the attention of management.
Thanks for your update and compliment, we will support and serve our professional user base better and harder.
You mentioned that the router has connected an external USB HUB.
It may be that this HUB HUB makes possible compatibility between the M2 board and GL router. I have submitted it to R&D. Please share this router with us, through GoodCloud:
Please PM me the router MAC and WebUI login password.
USB modem (like GL M2 5G dev board) connected to router via USB HUB, this issue we are aware.
The firmware download center, AX1800 4.7.0 and MT3000 4.7.4 has resolved this issue, please verified again in these version.
. Sorry that it took me so long.
).
.