Identify what QMI (Qualcomm's “Wireless Data Service” layer) reports when the connection drops, and how to retrieve error codes or state info that explain the drop.
Use uqmi commands to query connection state: The uqmi utility can fetch real-time status from the modem's QMI interface. Key commands include:
uqmi --get-data-status: Returns "connected" or "disconnected" indicating whether the modem's packet data service is currently up forum.gl-inet.com . After your drop occurs, this will likely show "disconnected" (confirming the bearer went down).
uqmi --get-current-settings: Shows the current connection settings (IP address, DNS, gateway, etc.) when connected. If the session has dropped, it returns "Out of call" forum.gl-inet.com , meaning no active data call. For example, after a failure one user saw: "Out of call" and data status "disconnected" forum.gl-inet.com .
uqmi --get-serving-system: Provides registration status and network info (which network the modem is camped on, and whether it's registered/attached). For instance, it can show { "registration": "registered", "plmn_mcc": , "plmn_mnc": , ... "roaming": false } indicating the module is registered on a home network forum.gl-inet.com . If the modem loses registration during the drop, this may change (e.g. "searching" or "denied").
uqmi --get-signal-info: Returns signal strength/quality metrics such as RSRP, RSRQ, RSSI, and SINR. For example: { "type": "lte", "rssi": -53, "rsrq": -7, "rsrp": -78, "snr": 230 } (snr is scaled by 10) forum.archive.openwrt.org . Monitoring these before and after drops can reveal if poor signal might be a trigger.
uqmi --wda-get-data-format: Indicates the data format (usually "raw-ip" for LTE modems like the EP06-A forum.gl-inet.com ). This is mostly static - on EP06, it should be raw-IP. A mismatch here (e.g. modem in raw-IP but driver expecting 802.3) can break the link, but OpenWrt's QMI scripts usually handle this by setting raw-ip mode. It's good to double-check it's "raw-ip" forum.gl-inet.com .
Capturing QMI error codes: Unfortunately, uqmi doesn't directly print verbose error causes on a dropped connection without additional debugging. However, OpenWrt's QMI scripts (and tools like Quectel-CM or qmicli) can retrieve QMI call end reasons. These are numeric codes that explain why the data call ended. For example, a user using Verizon saw verbose call end reasons 209 and 211, which correspond to PDN IPv4/IPv6 call throttled (network-triggered disconnects) forum.gl-inet.com . While uqmi won't show these codes by default, you can glean them by:
Checking system logs (logread) for any QMI messages. The netifd QMI handler may log something when the interface drops. Look for lines containing “call_end_reason” or QMI errors.
Running a one-time test with a more verbose tool: If possible, try using Quectel-CM or qmicli in debug mode (just for diagnosis on a PC or a temporary OpenWrt install). These can print detailed call setup and termination info (including QMI result codes). For instance, Quectel-CM logs show call end reasons like above. This can tell you if the drop is initiated by the network (e.g. an operator policy) or by the modem/host.
There is also a QMI message to get the last call end reason. While uqmi has no explicit flag for it, uqmi --get-current-settings might include a verbose_reason field if the call failed. In many cases, though, it just says "Out of call" without detail. Thus, external debugging or source code reference (like the qmi-enums-wds.h in OpenWrt) is needed to interpret codes.
Is uqmi --sync relevant? Yes - --sync can be very useful to clear stale state. The --sync command was added to force a release of any “stalled” WDS client or packet data handle (CID) before starting a new connection patchwork.ozlabs.org . In practice, if a previous data session ended abruptly or a client ID wasn't properly released, uqmi --sync will reset the modem's WDS state and avoid the dreaded “POLICY MISMATCH” errors when reconnecting patchwork.ozlabs.org . In your context, running uqmi -d /dev/cdc-wdm0 --sync before starting a new network session (or as part of recovery) ensures no ghost session lingers from the drop. It won't tell you why the drop happened, but it guarantees a clean slate for the next connection attempt.
Retrieve the Packet Data Handle (PDH): Whenever you start a network with uqmi --start-network, the tool typically outputs a numeric handle (unless --autoconnect masks it). This PDH is the reference to that data session. If you capture it (e.g., pdh=$(uqmi -d /dev/cdc-wdm0 --start-network | sed -e 's/"//g')), you can later use it to stop the network: uqmi -d /dev/cdc-wdm0 --stop-network $pdh. Stopping with the proper PDH is the clean way to terminate the session (preventing “ghost” PDP contexts on the modem). If the modem dropped on its own, the PDH might already be invalid, but issuing a stop can ensure the modem knows the call is terminated. Always include the --autoconnect flag when stopping if the session was started with autoconnect, to disable autoconnect (more on this below) forum.archive.openwrt.org .
Check for host-side causes in logs: It's worth examining system logs around the time of the drop. For example, see if netifd or mwan3 (OpenWrt's multi-WAN manager) reported anything. In one GL.iNet log, the drop corresponded with an ifdown event on the wwan interface triggered by mwan3 (which then flagged the interface offline) forum.gl-inet.com . This suggests the watchdog detected a connectivity loss. Identifying whether the trigger was the modem going down vs. something on the host bringing the interface down can guide your focus (modem vs system).
Bottom line: Use uqmi to poll the modem's status frequently or at the moment of drop. Capture before and after snapshots of --get-serving-system, --get-signal-info, and --get-data-status. These will confirm if the modem lost registration or signal when the link dropped, or if it remained registered (pointing to a possible data session termination at a higher level). Also consider running a debug instance of a QMI client to catch call end errors - those codes can directly pinpoint causes (e.g. admin disconnection, network order, out-of-coverage, etc.). And remember to utilize --sync and proper stop commands in your script to avoid compounding issues with leftover state.
Signal and Registration Correlation
Goal: Determine if signal quality or network registration issues are causing the disconnects. Even with “strong signal” indicated, deeper metrics like RSRP/RSRQ/SINR and registration state changes could reveal transient problems.
Monitor --get-serving-system: This command reveals the modem's network registration status. Key fields:
"registration" - will be "registered" when attached to the network (home or roaming), or "searching"/"not_registered" if it loses connection. Watch if this flips around the time of drop. If you see it go from registered to searching and back, the modem might be camping on the network but dropping the packet service.
"roaming" - true/false if the SIM is roaming on a different operator. (Roaming could trigger carrier-specific behaviors, but likely not the issue if you have a home network SIM.)
"plmn_mcc/mnc" - the network code. Not usually directly relevant to drops, except to confirm it stays on the same network.
Some modems also report "ps" (packet-switch attached) and "cs" (circuit-switch) states in this output. If available, "ps": "attached" is what you want. If you catch the modem in a dropped state, check if it still shows as attached. A drop might coincidentally involve a packet-service detach.
Poll --get-signal-info: The signal info gives you RSRP, RSRQ, RSSI, and SINR (though SINR is labeled as "snr" in uqmi). These are critical for understanding link quality:
RSRP (Reference Signal Received Power) - the strength of the LTE signal. This is a more reliable indicator than RSSI for LTE. Higher (less negative) is better. For example, RSRP >= -80 dBm is excellent, around -90 dBm is good, and < -100 dBm is poor wiki.teltonika-networks.com . Extremely weak RSRP (e.g. -110 dBm or below) can definitely cause link drops or the modem camping on the cell edge.
RSRQ (Reference Signal Received Quality) - the quality of the signal (signal-to-interference for the reference signals). Values closer to 0 are better (since it's negative dB). RSRQ >= -10 dB is excellent quality, -15 dB is moderate, and -20 dB or less is very poor wiki.teltonika-networks.com . Poor RSRQ means even if RSRP is decent, the link may be suffering interference or load (which can cause throughput issues or drops).
SINR (reported as SNR by uqmi) - signal-to-noise ratio. Higher is better (this is in dB and can even be positive). SINR > 15 dB is excellent, 0-5 dB is bad wiki.teltonika-networks.com . A negative or very low SINR indicates the modem is barely decoding the signal, which can definitely lead to drops without explicit error (the radio link just fails).
RSSI - raw received power, less useful in LTE because it includes noise. You can mostly ignore RSSI or use it as a coarse “bars” measurement, but RSRP/RSRQ are more telling.
Correlate these metrics with the timing of disconnects. Is there a sudden dip in RSRP or SINR before the drop? For instance, if RSRQ/SINR momentarily tank (say SINR goes near 0 or RSRQ drops below -20 dB), the connection might become unstable or the cell might drop the link. QMI may not explicitly say “lost signal” - it will just show “disconnected” - so these numbers are your clues.
Are there known threshold “cliffs” for QMI? QMI itself doesn't impose specific thresholds; it's the underlying LTE link that fails if signal is too poor. In practice:
RSRP around -105 to -110 dBm is a typical edge where an LTE connection might start dropping frequently or toggling between LTE/3G. If your RSRP is comfortably better than this (e.g. -80 dBm) at all times, pure signal strength is likely not the issue.
RSRQ worse than about -15 to -20 dB can indicate heavy load or interference on the cell. If you consistently see RSRQ in that range, the link can be unreliable even if RSRP is OK.
SINR below about 5 dB (especially if 0 or negative) means there's significant noise or interference; the LTE link may experience errors or outages. A very high SINR (20+ dB) with a strong RSRP is ideal for stability.
There isn't a “silent fail” specific to QMI at a magic number - rather, the modem's radio might drop the connection if these metrics go out of bounds. Action: log these values over time (even just printing to console or a temp file) to see if the drop correlates with a momentary spike in noise or dip in power.
Cell/Network-specific issues: Note that a too-strong signal can also cause issues (though usually not immediate drops - more like throughput issues). In one case, an EP06-E was very close to a base station and would reboot under heavy load, possibly due to RF front-end overload or power draw forums.quectel.com forums.quectel.com . This is rare but consider the environment: if you have the modem right next to a cell tower or a repeater, try attenuating as a test.
Use AT commands for signal too: You can cross-verify signal via AT command if needed (e.g. AT+CSQ for RSSI/QUAL, or Quectel's AT+QENG="servingcell" for a detailed dump including RSRP/RSRQ). Since uqmi --get-signal-info already gives these, AT isn't strictly necessary here, but it's good for redundancy.
TL;DR: Strong signal on paper doesn't rule out a signal-related drop. Monitor the quality metrics (RSRQ, SINR) in addition to raw signal strength. If these show the modem was well within “excellent” range (e.g. RSRP > -80 and SINR > 15 dB) throughout, you can likely rule out RF conditions as the cause. If you see anything borderline, that may require attention (e.g. better antennas, locking to a band with more stable signal, etc.). At minimum, you'll either gain confidence that “signal was fine, so look elsewhere” or discover correlation (e.g. every drop coincided with SINR plunging to 0 dB for a few seconds).
QMI Profile Lifecycle and Autoconnect Behavior
Goal: Understand how the modem's connection profiles and autoconnect feature work, to ensure we're not inadvertently causing the drops or fighting the modem's internal state.
QMI profiles vs APN strings: The Quectel EP06 (like many LTE modems) has internal profile slots (often profile 1, 2, etc.) that store APN and PDP type info. When you use uqmi --start-network , by default it does not use a stored profile - it sends a “Start Network” request with the given APN (this is equivalent to a profile index of 0 in QMI, meaning a custom call). If you use --profile 1 instead, uqmi will tell the modem to use profile 1's preconfigured APN. In practice, if you have the APN and settings stored via an AT command (e.g. AT+CGDCONT=1,"IP","" for profile 1), then --profile 1 is just another way to connect without explicitly typing the APN each time. Functionally, both achieve a data session. There isn't a huge difference during the connection - except that with a profile the modem might reuse some settings. The key is to use one method consistently and ensure the APN is correct. If you pass an APN string and also have autoconnect enabled (see next point), the modem might save that somewhere or treat it as the default for autoconnect.
--autoconnect flag behavior: Using --autoconnect with --start-network tells the modem to automatically maintain the data connection. In Quectel's QMI implementation, this typically means if the link drops for any reason, the modem will attempt to re-establish it on its own (without requiring the host to send a new start command). It also might mean the session remains up even if the QMI client (uqmi) exits. Important details:
Once you start a network with --autoconnect, subsequent --start-network calls may return "No effect", because the modem already considers the connection active or the autoconnect already took care of it. For example, one user found that after switching a modem to QMI mode, uqmi --start-network ... --autoconnect replied "no effect", yet the connection was established and wwan0 got an IP technicalexperiments.wordpress.com . In another discussion, it was confirmed: “No effect” usually means the modem is already connected - likely because you used autoconnect forum.archive.openwrt.org . In short, "No effect" isn't an error; it's an indication that the request was redundant. The data call is already up (or being handled by the modem firmware).
Does autoconnect create a persistent profile? Not exactly in the sense of a saved profile slot, but it can persist as a setting. On some modems, enabling autoconnect will remain in effect until you disable it (even across reboots, if the modem saves it to non-volatile config). It effectively ties the APN (either provided or default profile's APN) to an auto-reconnect logic in the modem's firmware. This is why you might see the modem come up by itself on boot if autoconnect was left on. Quectel modems also support an explicit command --set-autoconnect <enabled|disabled|paused> to manage this feature outside of starting/stopping a network forum.archive.openwrt.org . In practice, consider autoconnect as the modem being in charge of the connection.
Caution: While autoconnect is convenient, it “delegates too many decisions to firmware you have no control over” forum.archive.openwrt.org as one OpenWrt developer notes. If autoconnect is on, the modem might be doing things (like reconnecting or even roaming decisions) that are opaque. This can complicate debugging because the drop could occur and the modem might attempt a reconnection in the background (or conversely, refuse to fully disconnect). In a troubleshooting scenario, you might temporarily disable autoconnect and manage reconnection purely from your script, just to have clearer control. (Your script is already reliably bringing it back, so you might not need the modem's autoconnect anyway.)
Disabling autoconnect: If you started with autoconnect but want to turn it off, the proper way is to issue uqmi --stop-network --autoconnect (the --autoconnect on stop tells the modem to disable the auto-reconnect setting as it brings down the link) forum.archive.openwrt.org . Alternatively, you can use uqmi --set-autoconnect disabled at any time to tell the modem to turn off the feature. Ensure autoconnect is off if you want full manual control during diagnosis.
What “No effect” means in practice: In your context, if you see "No effect" from uqmi --start-network, it likely indicates that the EP06-A was already connected or in the process of connecting (hence no new action was taken) forum.archive.openwrt.org technicalexperiments.wordpress.com . Practically, this could happen if:
The modem auto-reconnected so fast that by the time your script tries to start a network, it's already up.
Or a previous session wasn't fully torn down (ghost context) and the modem thinks it's still active, so it refuses a duplicate start (though in that case you might get a “Call failed” or error instead of “No effect”). “No effect” is more benign.
In any case, the connection light going off suggests the link truly dropped. So if you get “No effect” right after a drop, it could be the modem reconnected on its own (LED might come back), or it could simply be a stale state. This is where using --get-data-status and --get-current-settings immediately after is helpful: if data-status says “connected” but you have no traffic, the modem might be stuck in a phantom connected state.
Autoconnect and profile persistence: When --autoconnect is used, the modem firmware may implicitly use a profile behind the scenes. Quectel modems often have an “autoconnect PDP context” that they manage. For example, if profile 1 is defined with an APN and autoconnect is enabled, the modem could attempt to keep that profile active. If you pass an APN string with autoconnect, the firmware might treat that as the APN to use going forward (akin to populating a temporary profile). It's a bit fuzzy in documentation, but assume that autoconnect “remembers” the last APN and will try to use it after reboots unless told otherwise. This is why after using autoconnect, you might not need to call --start-network on subsequent boots - the modem will do it. Keep this in mind: if you reboot the router and the modem comes online by itself, autoconnect was still enabled internally.
Recommendation: For diagnosis purposes, consider turning autoconnect off and handling reconnect in your script explicitly. This way, when a drop happens, it will truly drop (allowing you to inspect the state), and it won't come back up until your script intervenes - giving you a deterministic sequence of events. Once you identify the cause and fix it, you can decide to re-enable autoconnect if desired (or leave it off and trust your script). Many experienced users actually prefer not to use --autoconnect at all: “Personally I'd drop the --autoconnect. I like being in control.” forum.archive.openwrt.org . This sentiment is because manual control avoids hidden behavior and makes scripting more straightforward.
Start-network with APN vs with --profile: There is normally no difference in the resulting connection quality or routes, but using --profile 1 requires that profile to be configured in the modem. If you haven't explicitly set profile 1 via AT commands or a prior QMI command, it may default to a carrier-detected APN or nothing. If your uqmi -d /dev/cdc-wdm0 --start-network mobile --autoconnect was working (with “mobile” as APN presumably), then continuing with the APN string is fine. Just ensure you're not mixing methods in a way that could confuse things (e.g., don't have autoconnect using a different APN than you expect). For completeness, you could check what profiles are stored by using AT commands: AT+CGDCONT? will list all defined PDP contexts in the modem. Profile 1 might show your APN “mobile” there. If not, then the modem was using the APN you gave on the fly.
To summarize: Use one consistent method to start the network. If you use autoconnect, be aware of its side effects and consider disabling it during testing. “No effect” messages indicate the modem's state machine didn't need to do anything - double-check if the connection was in fact already up (or stuck). And always properly stop the network (with autoconnect off) when you are intentionally bringing it down, to avoid ghost connections.