Managing 4G Connections for Linux-Based IoT Devices

Introduction

At AIknow, over the years we’ve had to manage 4G connections on many Linux-based IoT devices, from simple solutions to complex industrial gateways. Our experience has led us through a natural evolution in the tools used for managing connectivity: starting with the traditional wvdial, moving towards NetworkManager, and discovering ModemManager as a fundamental tool for debugging and monitoring.

This article tells the story of our journey, sharing the issues we encountered, the solutions we developed, and the criteria we now use to choose the most appropriate tool for each project.

The First Steps: wvdial and the Direct Approach

Why We Started with `wvdial`

In our early projects involving 4G connectivity, wvdial seemed like the most natural choice: a simple, lightweight, and straightforward tool that used the PPP protocol to establish connections through cellular modems. The configuration appeared immediate, and the documentation, though limited, was clear.

The Advantages We Appreciated

Using wvdial immediately revealed some significant advantages:

Extremely lightweight: Resource usage was minimal, ideal for devices with limited RAM (64–128MB). On such systems, wvdial left enough headroom for the main application without compromising performance.

Simple configuration: A single file, /etc/wvdial.conf, contained everything needed for the connection. The configuration was transparent and easy to understand. Here’s an example:

[Dialer Defaults]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init3 = AT+CGDCONT=1,"IP","your.apn.here",,0,0
Modem Type = Analog Modem
ISDN = 0
Modem = /dev/ttyUSB0
Baud = 9600
Phone = *99#
Username = your_username
Password = your_password
New PPPD = yes

Direct control: The ability to directly manage the AT commands sent to the modem gave us complete control over the connection process.

The Issues That Made Us Rethink

However, using wvdial in real-world projects, we encountered significant limitations:

Handling disconnections: The most critical issue. wvdial lacked robust mechanisms for automatically handling disconnections. When the connection dropped—due to signal issues, operator network restarts, or simple timeouts—we had to implement external scripts to detect the situation and reconnect.

Lack of abstraction: Every modem or carrier change required manual configuration adjustments. There was no abstraction layer to automatically manage differences between devices.

Complex debugging: When something didn’t work, we had to manually inspect PPP logs and interact directly with the modem via AT commands to understand what was going on.

When we use wvdial

Despite its limitations, wvdial remains our choice in specific scenarios:

Devices with less than 256MB of RAM where every resource matters
Projects with very limited hardware budgets
Installations where brief service interruptions are acceptable
Situations where we have full control of the environment and can implement custom monitoring systems

The Discovery of ModemManager for Modem Status Verification

The Debugging Problem

One of the biggest issues with wvdial was the difficulty in diagnosing connection problems. We often had to open a direct serial session with the modem and send AT commands to retrieve basic information such as:

Signal quality (AT+CSQ)
Operator information (AT+COPS?)
Device IMEI (AT+CGSN)
SIM ICCID (AT+CCID)
SIM IMSI (AT+CIMI)
Configured APN (AT+CGDCONT?)
SIM PIN status (AT+CPIN?)
IP assigned to the connection (AT+CGPADDR)

ModemManager as a Diagnostic Tool

ModemManager revolutionized our approach to debugging 4G connections. Through mmcli, we gained immediate access to all modem information without having to interact directly with AT commands.

# Full modem information
mmcli -m 0

# Real-time signal quality
mmcli -m 0 --signal-get

# SIM information
mmcli -m 0 --sim=0

# Connection status
mmcli -m 0 --bearer=0

The Advantages of ModemManager

ModemManager provided us with:

AT command abstraction: We no longer had to remember the specific syntax of each modem to retrieve basic information.
Structured information: Data was presented in a readable and parsable format, making it easier to automate monitoring.
Extended compatibility: It automatically supported a wide range of modems without additional configuration.
Integration with scripts: We could easily integrate ModemManager’s data into our monitoring systems.

Using AT Commands for Specific Cases

Although ModemManager covered most of our needs, in some cases we still had to resort to direct AT commands:

# Direct modem access for specific commands
echo "AT+COPS=?" > /dev/ttyUSB2  # Scan for available operators
echo "AT+CGDCONT?" > /dev/ttyUSB2  # Check APN configuration
echo "AT+CREG?" > /dev/ttyUSB2     # Network registration status

AT commands remained useful for:

Advanced modem-specific configurations
Debugging particular issues not covered by ModemManager
Optimizations for certain network providers
Testing experimental features

The Evolution Towards NetworkManager: Reliability and Robustness

Why We Made the Switch

As our projects grew more complex and required more reliable connections, the limitations of wvdial became increasingly evident. NetworkManager promised to solve many of the problems we had faced, offering a more robust and automated connection management system.

The Benefits We Immediately Appreciated

Automatic connection management: The most immediate benefit was the automatic reconnection management. NetworkManager constantly monitors connection status and reconnects automatically in case of interruption.
Integration with ModemManager: Native integration with ModemManager gave us instant access to all modem information without additional configuration.
Extended hardware support: We no longer had to worry about the specifics of each modem; NetworkManager handled differences between devices automatically.
Centralized configuration: All connections could be managed through a unified interface, simplifying maintenance.
Advanced connection profiles: We could configure multiple connections, priorities, failover, and other advanced features.

The Challenges We Faced

Higher resource consumption: NetworkManager requires more RAM and CPU than wvdial. On devices with 256MB of RAM, we observed a significant performance impact, especially during activity peaks.
Configuration complexity: For advanced scenarios, configuration becomes more elaborate. Setting up failover between different connections or integrating with VPNs requires a deep understanding of NetworkManager’s architecture.
Layered debugging: When something goes wrong, we have to investigate the interaction between NetworkManager, ModemManager, and the kernel. Debugging requires knowledge across multiple system layers.
More dependencies: NetworkManager introduces more components into the system, increasing the surface for potential issues and deployment complexity.

When We Use NetworkManager

NetworkManager has become our standard choice, especially for:

Critical installations: Where connection reliability is a top priority
Complex systems: That require advanced network configurations (failover, VPN, bridging)
Production environments: Where we need robust monitoring and management tools

Pros and Cons from Our Experience

wvdial – Advantages:

Minimal resource usage
Simple and transparent configuration
Direct control over commands sent to the modem
Ideal for low-resource devices
Relatively simple debugging (once PPP and AT commands are understood)

wvdial – Disadvantages:

Manual reconnection management
Lack of hardware abstraction
Complex debugging for connectivity issues
Requires external scripts for robustness
Not suitable for critical production environments

NetworkManager – Advantages:

Robust and automated connection management
Extensive and automatic hardware support
Native integration with ModemManager
Advanced features (failover, priorities, profiles)
Built-in debugging and monitoring tools
Suitable for production environments

NetworkManager – Disadvantages:

Higher resource consumption (RAM and CPU)
More complex configuration for advanced scenarios
More components to manage and potential failure points
Steeper learning curve
Overkill for simple applications

Support Tools and Best Practices

Our Diagnostic Toolkit

Regardless of the main tool we choose, we have developed a set of diagnostic procedures that we systematically use in all our projects:

Modem Status Check:

mmcli -L to list modems detected by the system
mmcli -m 0 to get full information about the main modem
mmcli -m 0 --signal-get to monitor real-time signal quality

SIM Information Check:

mmcli -m 0 --sim=0 to verify IMSI, ICCID, and operator
Direct AT commands AT+CPIN? to check PIN status
AT+CIMI and AT+CCID for alternative IMSI and ICCID checks

Basic Connectivity Tests:

Ping public DNS servers (ping -c 3 8.8.8.8 and ping -c 3 1.1.1.1)
DNS resolution check (nslookup google.com)
HTTP/HTTPS connectivity test with curl

Network Interface Analysis:

ip addr show to display all active interfaces
ip route show to check routing tables
Specific check of cellular interfaces (ppp, wwan, usb)

Data Traffic Monitoring:

Counter analysis in /proc/net/dev for cellular interfaces
ifconfig for detailed TX/RX statistics
Real-time bandwidth usage monitoring

Advanced Debugging with AT Commands:

AT+CSQ for signal quality when ModemManager is not available
AT+CGDCONT? to verify APN configuration
AT+CGPADDR to check the IP assigned to the connection
AT+COPS? for information about the network operator

Connection Status Check:

nmcli connection show to see the status of NetworkManager profiles
nmcli device status to verify device status
System log analysis (journalctl -u NetworkManager or /var/log/messages)

Decision Criteria Based on Our Experience

After years of projects, we have defined clear criteria for selection:

Choose wvdial when:

Available RAM < 256MB
Extremely limited hardware budget
Simple connectivity without high availability requirements
Team with system administration skills to manage custom scripts
Tolerance for short service interruptions
Full control over the deployment environment

Choose NetworkManager when:

Available RAM > 512MB
High reliability and availability requirements
Complex network configurations
Critical production environments
Need for integrated monitoring tools
Team with advanced system administration expertise

Other alternatives: ConnMan as an intermediate option

It is worth mentioning that ConnMan also exists as an intermediate alternative.
Designed specifically for embedded systems, it offers an interesting compromise between the lightness of wvdial and the features of NetworkManager.
However, our experience has mainly focused on the two main tools for most of our use cases.

Conclusions and recommendations

Our evolution from wvdial to NetworkManager reflects the maturation of our needs and project complexity.
Both tools have their place in our toolkit, and the choice always depends on the specific project requirements.

ModemManager has proven essential regardless of the primary choice, providing vital information for debugging and monitoring without constantly relying on direct AT commands.

AT commands remain an indispensable tool for specific situations and advanced debugging, even though ModemManager has significantly reduced the need to use them daily.

The most important lesson we have learned is that there is no universal solution: the choice must always be guided by the real project constraints, such as hardware resources, reliability requirements, and implementation complexity.

For future projects, we continue to evaluate new solutions, but the combination of NetworkManager + ModemManager remains our standard for most modern IoT implementations requiring reliable and robust 4G connectivity.

Have you had similar experiences managing 4G connections on IoT devices, or do you need support configuring connectivity for your project?
Contact us to share your experience or receive specialized technical assistance!