An IOT2050 running IOT OS V1.3.1 intermittently loses internet access through a connected 3G modem. Connecting a DHCP-enabled network to P1 restores connectivity, but removing that cable does not always return traffic to the modem. Rebooting without the P1 cable also restores access temporarily. This behavior points to an interface, default-route, or connection-state problem, but the available evidence does not establish a single root cause.
Separate modem connectivity from routing
Capture the modem interface address and routing table both while the connection works and immediately after it fails. The decisive comparison is whether the modem retains a valid IP address and whether the system still has a default route through that interface. If the address disappears, investigate modem or mobile-service connectivity. If the address remains but the default route changes or disappears, investigate Linux network configuration and DHCP route handling.
| Observation after failure | Diagnostic direction |
|---|---|
| Modem interface has no valid IP address | Inspect modem state, signal, mobile service, and system logs. |
| Modem has an IP address but no default route uses it | Inspect routing and DHCP configuration. |
| Address and route remain present | Use ping and path tracing to locate where traffic stops. |
Capture Linux diagnostics during the outage
Run the same command set before and during a failure so the results can be compared. Do not reboot or connect P1 before collecting the failed-state data, because either action may alter the condition being diagnosed.
ip addr
ip route
ping <local-IP-address>
ping <remote-IP-address>
traceroute <remote-IP-address>
dmesgifconfig and route can provide similar interface and routing information. If available, mtr can replace or supplement traceroute. Review /var/log/syslog for events recorded at the loss time; one observed outage occurred at approximately 5:36, so correlate commands and log entries around the actual failure timestamp.
Audit interface and DHCP configuration
- Review
/etc/network/interfacesor/etc/netplan/01-network-manager-all.yaml, depending on which configuration system the installation uses. - Check the DHCP client configuration applied to P1 and determine whether connecting its DHCP server adds or replaces the default route.
- Verify that removing P1 leaves or restores a default route through the 3G modem interface.
- Repeat the checks after the connection has remained active long enough to reproduce the intermittent loss.
The evidence does not identify the modem interface name, route metric, modem model, or configuration method. Record those values from the affected system instead of assuming them. The SIM, antennas, and 3G modem were each replaced without eliminating the fault, which makes a simple failure of one replaced component less likely but does not rule out signal quality, provider behavior, or a shared configuration problem.
Verify the corrective result
A successful correction must survive both route switching and elapsed time. Start without P1, confirm that the modem supplies internet access, connect the DHCP-enabled P1 cable, then disconnect it and confirm that the default route returns to the modem. Continue monitoring with iftop, nethogs, or vnstat if available, and retain timestamped interface, route, path, and log data if another outage occurs.
FAQ
Why does connecting P1 restore IOT2050 internet access?
The evidence suggests that P1's DHCP connection changes network state or routing, but it does not prove the exact cause. Compare ip route before connection, while P1 is connected, and after removal to identify the route change.
Which Linux commands diagnose an IOT2050 3G outage?
Capture ip addr, ip route, local and remote ping results, traceroute or mtr, and dmesg. Also inspect /var/log/syslog at the failure timestamp.
Does replacing the SIM, antenna, and 3G modem prove routing is the fault?
No. Those replacements did not resolve the reported failure, but the root cause remains unconfirmed. Failed-state address, route, path, and log captures are required to distinguish Linux routing from modem, signal, or provider problems.