Mastering Linux Networking:
Build an Automated Wi-Fi Speed & Stability Analyzer
As a associate system administrator I worked on Redhat Linux servers, including user management, permissions, services, and performance monitoring Automated routine administrative tasks using Bash scripting and cron jobs, reducing manual effort by ~30% I am aws certified sysops administrator and Google Certified Cloud Engineer. Determined to transition my career into cloud architect /Cloud Support role
In the world of System Administration and DevOps, network reliability is non-negotiable. While most users rely on browser-based speed tests, Linux engineers require something more robust—something scriptable, automated, and capable of providing deep insights into signal health, latency, and throughput over time.
In this article, we will walk through a comprehensive Linux networking project: The Wi-Fi Speed Analyzer. Built specifically for RHEL-based distributions (RHEL, Fedora, Rocky Linux, AlmaLinux), this tool leverages industry-standard utilities like nmcli, iperf3, and systemd to transform your terminal into a professional network diagnostic hub.
The Problem: Why a CLI Tool? Standard GUI speed tests only give you a "snapshot" of your current download speed. They don't tell you:
How your Signal-to-Noise Ratio (SNR) affects stability.
The consistency of latency (Jitter) over a 24-hour period.
Actual internal bandwidth capacity using iperf3.
By building a CLI-based analyzer, we can automate these checks, log them to a file, and generate reports that help identify the exact moment a network starts degrading.
Project Overview & Features Our Wi-Fi Speed Analyzer is designed with a "Production-First" mindset. Key features include:
Signal Monitoring: Capturing dBm levels and bitrates.
Latency Benchmarking: Tracking ICMP response times via ping.
Throughput Testing: Measuring actual data transfer rates via iperf3.
Automated Scheduling: Using systemd timers for background monitoring.
Human-Readable Reports: Converting raw logs into actionable analytics.
Step 1: Preparing the Environment
This project is optimized for RHEL 8/9 and its derivatives. Before we begin, we need to ensure our system has the necessary networking utilities.
Prerequisites You will need git, NetworkManager, and iperf3. Our setup script handles most of this, but ensure you have sudo privileges.
Cloning the Repository First, pull the project from GitHub:
Bash git clone https://github.com/kpratikshak/wifi-speed-analyzer.git cd wifi-speed-analyzer Initializing the Tool We have provided a setup.sh script to automate dependency installation and permission handling.
chmod +x setup.sh ./setup.sh
This script checks for the presence of nmcli (for connection management) and iw (for wireless statistics), ensuring the environment is ready for testing.
Step 2: Understanding the Core Architecture:
The project is divided into three functional layers:
The Collector (analyzer.sh):
This is the "brain." It executes networking commands, parses the output using grep and awk, and appends the data to a timestamped log file.
The Configurator (config.conf):
Allows you to set your target server for iperf3 tests and define latency thresholds.
The Reporter (report.sh): A formatting script that reads the raw logs and displays a clean summary of network performance.
Step 3: Deep Dive into the Analysis Logic:
Let’s look at how the analyzer gathers data.
Signal Strength Monitoring :
The tool uses nmcli -f IN-USE,SIGNAL,SSID,RATE device wifi.
Signal (0-100): A linear representation of strength.
Bars: A visual indicator. Higher numbers in the SIGNAL column indicate a more stable connection, while a fluctuating RATE suggests interference.
Latency and Jitter:
We use ping -c 5 8.8.8.8 to calculate the average round-trip time (RTT). High variance in these 5 packets indicates "Jitter," which is the primary cause of lag in VOIP calls and gaming.
Bandwidth Testing with iperf3 :
Unlike a standard "speed test" that pings a random web server, iperf3 allows us to test against a specific endpoint.
Bash iperf3 -c <server_ip> -t 5
This measures the actual TCP/UDP throughput of your network interface.
Step 4: Running Manual Tests
Before automating, it’s important to run a manual test to verify configurations.
Configure your target:
Edit config.conf to point to your preferred testing server.
Run the Analyzer:
Bash ./analyzer.sh View the Data: The results are saved in logs/wifi_stats.log. To see a formatted summary, run:
Step 5: Advanced Automation with Systemd :
One of the most powerful features of this project is the transition from manual execution to Automated Observability. While cron is traditional, modern Linux distributions prefer systemd timers because they offer better logging via journalctl and handle dependencies more gracefully.
Deploying the Timer We provide pre-configured systemd unit files in the repository. To enable them:
Bash sudo cp systemd/* /etc/systemd/system/ sudo systemctl daemon-reload sudo systemctl enable --now wifi-analyzer.timer Why Systemd Timers? Precision: You can define exactly when the test runs (e.g., every 15 minutes).
Logging: If a test fails, systemctl status wifi-analyzer.service will tell you exactly why.
Resource Management: Systemd can ensure the test doesn't run if the system is under extreme CPU load.
Step 6: Implementing Parallel Testing For advanced users, testing latency and throughput sequentially isn't enough. Network performance can change when the link is saturated. To simulate real-world stress, we use Bash background jobs.
In the analyzer.sh script, you can trigger parallel tests:
run ping in the background:
ping -c 10 8.8.8.8 > logs/latency.log &
Simultaneously run iperf3
iperf3 -c -t 10 > logs/throughput.log &
Wait for both to finish
This "Parallel Testing" approach reveals how high bandwidth usage affects your latency - a critical metric for network engineers.
Step 7: Interpreting the Reports:
Once the tool has been running via systemd for a few hours, run ./report.sh. You should look for the following patterns:
Consistent Signal, Low Throughput: This usually indicates channel interference or a congested Access Point.
Low Signal, High Latency: Physical distance or obstacles are the likely culprit.
Spikes in Latency (Jitter): Often caused by other devices on the network or ISP routing issues.
Conclusion:
Building a Wi-Fi Speed Analyzer is more than just a coding exercise; it’s about mastering the Linux networking stack. By combining nmcli, iperf3, and systemd, we’ve created a tool that provides production-grade analytics with minimal overhead.
Takeaways:
Automation is king: Don't check your speeds manually; let systemd do it.
Logs are gold: Use your historical data to argue for better hardware or ISP upgrades.
Linux Tools are powerful: Most of what you need is already built into RHEL; you just need to script it.
What's Next? You can extend this project by:
Adding a Python/Flask Dashboard to visualize the logs in a web browser.
Integrating Slack/Discord notifications to alert you when your signal strength drops below a certain threshold.
Exporting the data to Prometheus/Grafana for long-term storage and beautiful graphs.
Check out the full source code and contribute on GitHub. Happy networking!