When your network link goes down, every second counts. Whether you're running a home office with a cable modem and cellular backup, or managing a multi-WAN enterprise router, you need to know the moment a connection fails -- and you need the system to respond automatically.
Apinger gives you that capability. It's a lightweight alive-monitoring daemon that pings multiple targets across different interfaces and triggers configurable alarm actions when links degrade or fail. With the new UCI and LuCI integration, setting it up takes minutes.
What Apinger Monitors Link to heading
Apinger continuously pings configured targets on each network interface and tracks:
- Packet loss percentage -- is the link dropping packets?
- Round-trip time (RTT) -- is latency spiking?
- Alarm conditions -- customizable thresholds that trigger actions
A typical setup monitors both internal and external targets. Your router pings the ISP gateway to detect WAN failures and pings an internal server to verify LAN connectivity:
INTERNAL LAN (192.168.1.10) <--> OpenWrt Router <--> EXTERNAL WAN (8.8.8.8)
|
WAN: 192.168.111.15
LAN: 192.168.1.1/24
Installation Link to heading
OpenWrt's LuCI interface makes installation straightforward. Log into your router and navigate to System -> Software. Click Update lists to refresh the package metadata, then search for "apinger."
You need three packages:
| Package | Purpose |
|---|---|
| apinger | The monitoring daemon -- the backend that pings targets and tracks metrics |
| luci-app-apinger | The LuCI web interface -- configure monitoring from the browser |
| apinger-rrd | RRD graph generation -- visualise latency and packet loss over time |
Select all three and click Install. Once installed, refresh the page and you'll find Apinger under the Services menu.
Configuration via LuCI UI Link to heading
Navigate to Services -> Apinger. You'll see an interface-based configuration page.
The core concept is simple: each WAN interface gets its own monitoring configuration. If you have a cable modem on wan and a cellular backup on wan2, you configure them separately. Each interface monitors its own targets with its own thresholds.
Basic setup for a single WAN:
- Select your WAN interface (e.g.,
wan) - Add target IPs to monitor -- use reliable external hosts like
8.8.8.8,1.1.1.1, or your ISP's gateway - Set the check interval -- every 5 seconds is a good default for production
- Configure alarm thresholds -- trigger when packet loss exceeds a percentage or latency crosses a limit
- Save and apply
Apinger immediately begins monitoring. The overview page shows current status for each interface: green for healthy links, red when alarms trigger.
Configuration via UCI Command Line Link to heading
For scripted deployments or headless routers, the UCI command line provides the same control:
# Create an interface monitoring section
uci set apinger.wan=interface
uci set apinger.wan.status_interval='5'
uci add_list apinger.wan.target='8.8.8.8'
uci add_list apinger.wan.target='1.1.1.1'
# Apply and restart
uci commit apinger
/etc/init.d/apinger restart
Each interface section maps directly to a network interface in /etc/config/network. The apinger instance picks up the source IP from the network configuration automatically. For complex topologies where the default route doesn't match the monitored interface, you can set the source IP explicitly:
uci set apinger.wan2.srcip='192.168.2.100'
RRD Graphs -- Visualise Network Health Link to heading
With the apinger-rrd package installed, the system automatically generates RRD (Round-Robin Database) graphs that show latency and packet loss trends over time. Navigate to the Graphs tab in the LuCI interface to see:
- RTT (round-trip time) plotted over hours and days
- Packet loss percentage trends
- Per-interface and per-target breakdowns
This is invaluable for troubleshooting intermittent issues. A quick glance at the graphs tells you whether last night's outage was a brief spike or a sustained failure.
Automating Responses to Link Failures Link to heading
Monitoring is only half the picture. When apinger detects a failure, it can trigger actions through alarm scripts:
- QoS adjustments -- throttle non-critical traffic when bandwidth drops
- Load balancing -- shift traffic to a healthy WAN link
- Email alerts -- notify the operations team immediately
- Firewall rule changes -- block or redirect traffic based on link state
- Site-to-site failover -- switch VPN tunnels to backup paths
The alarm scripts run as shell commands, so the integration possibilities are wide open. Hook apinger into your existing monitoring stack, your notification system, or custom routing logic.
Why Procd-Based Instances Matter Link to heading
Under the hood, apinger now runs as individual procd instances -- one per interface. This architectural change means:
- Each interface is independently monitored. A failure on WAN1 doesn't affect WAN2 monitoring.
- Hotplug events restart instances automatically. Pull the cable and apinger notices. Plug it back in and monitoring resumes.
- Configuration is clean and isolated. No monolithic config file -- each interface section is self-contained.
For multi-WAN routers, cable modems with backup cellular links, or any setup where uptime matters, apinger with UCI and LuCI turns network monitoring from a chore into a configuration.
Originally published July 6, 2022 on jaymspatel.blogspot.com