GL-M2; possible hardware fault with recent order (GL29575)

Technical Support for Routers
9

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 :lab_coat::nerd_face::wrench:).
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 :slightly_smiling_face: (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 uqmi aren'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 ModemManager might 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(?) :man_shrugging:
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 :laughing:.

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. :+1::slightly_smiling_face:

1 Like