wvdial<\/code>, moving towards NetworkManager<\/code>, and discovering ModemManager<\/code> as a fundamental tool for debugging and monitoring.<\/p>\nThis 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.<\/p>\n
![\"\"](\"https:\/\/www.aiknow.io\/wpvt\/wp-content\/uploads\/2025\/06\/20250616_1142_Comandi-AT-su-USB_remix_01jxw1r6m8epz8rrw4gh4rw3hk-1-300x200.png\")
<\/p>\n
<\/p>\n
The First Steps: wvdial and the Direct Approach<\/h2>\nWhy We Started with wvdial<\/code><\/h3>\nIn our early projects involving 4G connectivity, wvdial<\/code> 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.<\/p>\nThe Advantages We Appreciated<\/h3>\n
Using wvdial immediately revealed some significant advantages:<\/p>\n
Extremely lightweight<\/strong>: Resource usage was minimal, ideal for devices with limited RAM (64\u2013128MB). On such systems, wvdial left enough headroom for the main application without compromising performance.<\/p>\nSimple configuration<\/strong>: A single file, \/etc\/wvdial.conf<\/code>, contained everything needed for the connection. The configuration was transparent and easy to understand. Here\u2019s an example:<\/p>\n\n[Dialer Defaults]\r\nInit1 = ATZ\r\nInit2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0\r\nInit3 = AT+CGDCONT=1,\"IP\",\"your.apn.here\",,0,0\r\nModem Type = Analog Modem\r\nISDN = 0\r\nModem = \/dev\/ttyUSB0\r\nBaud = 9600\r\nPhone = *99#\r\nUsername = your_username\r\nPassword = your_password\r\nNew PPPD = yes<\/pre>\n<\/div>\nDirect control<\/strong>: The ability to directly manage the AT commands sent to the modem gave us complete control over the connection process.<\/p>\nThe Issues That Made Us Rethink<\/h3>\n
However, using wvdial in real-world projects, we encountered significant limitations:<\/p>\n
Handling disconnections<\/strong>: The most critical issue. wvdial lacked robust mechanisms for automatically handling disconnections. When the connection dropped\u2014due to signal issues, operator network restarts, or simple timeouts\u2014we had to implement external scripts to detect the situation and reconnect.<\/p>\nLack of abstraction<\/strong>: Every modem or carrier change required manual configuration adjustments. There was no abstraction layer to automatically manage differences between devices.<\/p>\nComplex debugging<\/strong>: When something didn\u2019t work, we had to manually inspect PPP logs and interact directly with the modem via AT commands to understand what was going on.<\/p>\nWhen we use wvdial<\/h3>\n
Despite its limitations, wvdial remains our choice in specific scenarios:<\/p>\n
\n- Devices with less than 256MB of RAM where every resource matters<\/li>\n
- Projects with very limited hardware budgets<\/li>\n
- Installations where brief service interruptions are acceptable<\/li>\n
- Situations where we have full control of the environment and can implement custom monitoring systems<\/li>\n<\/ul>\n
The Discovery of ModemManager for Modem Status Verification<\/h2>\nThe Debugging Problem<\/h3>\n
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:<\/p>\n
\n- Signal quality (
AT+CSQ<\/code>)<\/li>\n- Operator information (
AT+COPS?<\/code>)<\/li>\n- Device IMEI (
AT+CGSN<\/code>)<\/li>\n- SIM ICCID (
AT+CCID<\/code>)<\/li>\n- SIM IMSI (
AT+CIMI<\/code>)<\/li>\n- Configured APN (
AT+CGDCONT?<\/code>)<\/li>\n- SIM PIN status (
AT+CPIN?<\/code>)<\/li>\n- IP assigned to the connection (
AT+CGPADDR<\/code>)<\/li>\n<\/ul>\nModemManager as a Diagnostic Tool<\/h3>\n
ModemManager revolutionized our approach to debugging 4G connections. Through mmcli<\/code>, we gained immediate access to all modem information without having to interact directly with AT commands.<\/p>\n\n# Full modem information\r\nmmcli -m 0\r\n\r\n# Real-time signal quality\r\nmmcli -m 0 --signal-get\r\n\r\n# SIM information\r\nmmcli -m 0 --sim=0\r\n\r\n# Connection status\r\nmmcli -m 0 --bearer=0<\/pre>\n<\/div>\nThe Advantages of ModemManager<\/h3>\n
ModemManager provided us with:<\/p>\n
\n- AT command abstraction<\/strong>: We no longer had to remember the specific syntax of each modem to retrieve basic information.<\/li>\n
- Structured information<\/strong>: Data was presented in a readable and parsable format, making it easier to automate monitoring.<\/li>\n
- Extended compatibility<\/strong>: It automatically supported a wide range of modems without additional configuration.<\/li>\n
- Integration with scripts<\/strong>: We could easily integrate ModemManager’s data into our monitoring systems.<\/li>\n<\/ul>\n
Using AT Commands for Specific Cases<\/h3>\n
Although ModemManager covered most of our needs, in some cases we still had to resort to direct AT commands:<\/p>\n
\n# Direct modem access for specific commands\r\necho \"AT+COPS=?\" > \/dev\/ttyUSB2 \u00a0# Scan for available operators\r\necho \"AT+CGDCONT?\" > \/dev\/ttyUSB2 \u00a0# Check APN configuration\r\necho \"AT+CREG?\" > \/dev\/ttyUSB2 \u00a0 \u00a0 # Network registration status<\/pre>\n<\/div>\nAT commands remained useful for:<\/p>\n
\n- Advanced modem-specific configurations<\/li>\n
- Debugging particular issues not covered by ModemManager<\/li>\n
- Optimizations for certain network providers<\/li>\n
- Testing experimental features<\/li>\n<\/ul>\n
The Evolution Towards NetworkManager: Reliability and Robustness<\/h2>\nWhy We Made the Switch<\/h3>\n
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.<\/p>\n
The Benefits We Immediately Appreciated<\/h3>\n\n- Automatic connection management<\/strong>: The most immediate benefit was the automatic reconnection management. NetworkManager constantly monitors connection status and reconnects automatically in case of interruption.<\/li>\n
- Integration with ModemManager<\/strong>: Native integration with ModemManager gave us instant access to all modem information without additional configuration.<\/li>\n
- Extended hardware support<\/strong>: We no longer had to worry about the specifics of each modem; NetworkManager handled differences between devices automatically.<\/li>\n
- Centralized configuration<\/strong>: All connections could be managed through a unified interface, simplifying maintenance.<\/li>\n
- Advanced connection profiles<\/strong>: We could configure multiple connections, priorities, failover, and other advanced features.<\/li>\n<\/ul>\n
The Challenges We Faced<\/h3>\n\n- Higher resource consumption<\/strong>: NetworkManager requires more RAM and CPU than wvdial. On devices with 256MB of RAM, we observed a significant performance impact, especially during activity peaks.<\/li>\n
- Configuration complexity<\/strong>: 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.<\/li>\n
- Layered debugging<\/strong>: When something goes wrong, we have to investigate the interaction between NetworkManager, ModemManager, and the kernel. Debugging requires knowledge across multiple system layers.<\/li>\n
- More dependencies<\/strong>: NetworkManager introduces more components into the system, increasing the surface for potential issues and deployment complexity.<\/li>\n<\/ul>\n
When We Use NetworkManager<\/h3>\n
NetworkManager has become our standard choice, especially for:<\/p>\n
\n- Critical installations<\/strong>: Where connection reliability is a top priority<\/li>\n
- Complex systems<\/strong>: That require advanced network configurations (failover, VPN, bridging)<\/li>\n
- Production environments<\/strong>: Where we need robust monitoring and management tools<\/li>\n<\/ul>\n
Pros and Cons from Our Experience<\/h3>\n
wvdial \u2013 Advantages:<\/strong><\/p>\n\n- Minimal resource usage<\/li>\n
- Simple and transparent configuration<\/li>\n
- Direct control over commands sent to the modem<\/li>\n
- Ideal for low-resource devices<\/li>\n
- Relatively simple debugging (once PPP and AT commands are understood)<\/li>\n<\/ul>\n
wvdial \u2013 Disadvantages:<\/strong><\/p>\n\n- Manual reconnection management<\/li>\n
- Lack of hardware abstraction<\/li>\n
- Complex debugging for connectivity issues<\/li>\n
- Requires external scripts for robustness<\/li>\n
- Not suitable for critical production environments<\/li>\n<\/ul>\n
NetworkManager \u2013 Advantages:<\/strong><\/p>\n\n- Robust and automated connection management<\/li>\n
- Extensive and automatic hardware support<\/li>\n
- Native integration with ModemManager<\/li>\n
- Advanced features (failover, priorities, profiles)<\/li>\n
- Built-in debugging and monitoring tools<\/li>\n
- Suitable for production environments<\/li>\n<\/ul>\n
NetworkManager \u2013 Disadvantages:<\/strong><\/p>\n\n- Higher resource consumption (RAM and CPU)<\/li>\n
- More complex configuration for advanced scenarios<\/li>\n
- More components to manage and potential failure points<\/li>\n
- Steeper learning curve<\/li>\n
- Overkill for simple applications<\/li>\n<\/ul>\n
Support Tools and Best Practices<\/h2>\nOur Diagnostic Toolkit<\/h3>\n
Regardless of the main tool we choose, we have developed a set of diagnostic procedures that we systematically use in all our projects:<\/p>\n
Modem Status Check:<\/strong><\/p>\n\nmmcli -L<\/code> to list modems detected by the system<\/li>\nmmcli -m 0<\/code> to get full information about the main modem<\/li>\nmmcli -m 0 --signal-get<\/code> to monitor real-time signal quality<\/li>\n<\/ul>\nSIM Information Check:<\/h3>\n\nmmcli -m 0 --sim=0<\/code> to verify IMSI, ICCID, and operator<\/li>\n- Direct AT commands
AT+CPIN?<\/code> to check PIN status<\/li>\nAT+CIMI<\/code> and AT+CCID<\/code> for alternative IMSI and ICCID checks<\/li>\n<\/ul>\nBasic Connectivity Tests:<\/h3>\n\n- Ping public DNS servers (
ping -c 3 8.8.8.8<\/code> and ping -c 3 1.1.1.1<\/code>)<\/li>\n- DNS resolution check (
nslookup google.com<\/code>)<\/li>\n- HTTP\/HTTPS connectivity test with
curl<\/code><\/li>\n<\/ul>\nNetwork Interface Analysis:<\/h3>\n\nip addr show<\/code> to display all active interfaces<\/li>\nip route show<\/code> to check routing tables<\/li>\n- Specific check of cellular interfaces (ppp, wwan, usb)<\/li>\n<\/ul>\n
Data Traffic Monitoring:<\/h3>\n\n- Counter analysis in
\/proc\/net\/dev<\/code> for cellular interfaces<\/li>\nifconfig<\/code> for detailed TX\/RX statistics<\/li>\n- Real-time bandwidth usage monitoring<\/li>\n<\/ul>\n
Advanced Debugging with AT Commands:<\/h3>\n\nAT+CSQ<\/code> for signal quality when ModemManager is not available<\/li>\nAT+CGDCONT?<\/code> to verify APN configuration<\/li>\nAT+CGPADDR<\/code> to check the IP assigned to the connection<\/li>\nAT+COPS?<\/code> for information about the network operator<\/li>\n<\/ul>\nConnection Status Check:<\/h3>\n\nnmcli connection show<\/code> to see the status of NetworkManager profiles<\/li>\nnmcli device status<\/code> to verify device status<\/li>\n- System log analysis (
journalctl -u NetworkManager<\/code> or \/var\/log\/messages<\/code>)<\/li>\n<\/ul>\nDecision Criteria Based on Our Experience<\/h3>\n
After years of projects, we have defined clear criteria for selection:<\/p>\n
Choose wvdial when:<\/strong><\/p>\n\n- Available RAM < 256MB<\/li>\n
- Extremely limited hardware budget<\/li>\n
- Simple connectivity without high availability requirements<\/li>\n
- Team with system administration skills to manage custom scripts<\/li>\n
- Tolerance for short service interruptions<\/li>\n
- Full control over the deployment environment<\/li>\n<\/ul>\n
Choose NetworkManager when:<\/h3>\n