OpenClaw Network Diagnostics

Overview

Run a pure network diagnostic worker from CLI to continuously monitor connectivity between:

1. OpenClaw runtime host
2. Telegram Bot API (api.telegram.org)
3. Personal Telegram client approximation via delivery verification cycles

Keep diagnostics isolated from OpenClaw LLM flow:

• Use no LLM calls.
• Consume no AI tokens.
• Run in independent async worker loops.

Skill Files

• scripts/netdiag.py: standalone CLI worker (run/start/stop/status/validate-config)
• references/config.example.json: complete example configuration
• references/example-log-entries.jsonl: sample structured JSON logs
• references/openclaw-integration.md: integration patterns with pros/cons
• references/ai-log-analysis.md: workflow for later AI-based log analysis

Prerequisites

Install and verify:

1. Python 3.11+
2. macOS networking tools: dig, ping, traceroute
3. Telegram bot token and personal chat id

Install

From skill root:

cd /Users/ivanbelugin/Documents/Connection\ Monitoring\ System/openclaw-network-diagnostics
python3 scripts/netdiag.py validate-config --config references/config.example.json

Create a real config file from the example and set real credentials:

cp references/config.example.json config.json

Then edit config.json:

• telegram.bot_token
• telegram.personal_chat_id

Run Model

Foreground mode (manual stop via Ctrl+C)

python3 scripts/netdiag.py run --config config.json --pid-file ./logs/netdiag.pid

Behavior:

• Start manually from CLI.
• Run continuously until manual stop.
• Print JSON summary to stdout on stop.
• Save summary to logging.summary_file_path.

Background mode (non-blocking service)

python3 scripts/netdiag.py start --config config.json --pid-file ./logs/netdiag.pid
python3 scripts/netdiag.py status --pid-file ./logs/netdiag.pid
python3 scripts/netdiag.py stop --pid-file ./logs/netdiag.pid

Use this mode to avoid blocking OpenClaw main thread.

Monitoring Behavior

Every intervals_sec.ping (default 30s) perform active cycle:

1. Resolve DNS with TTL snapshot (system + public resolvers).
2. Send Bot API probe (getMe) and measure round-trip latency.
3. Run delivery verification cycle (sendMessage + selected ack mode).
4. Run packet-loss probe (ping) and log packet loss indicators.
5. Update outage/recovery and anomaly counters.

Additional periodic diagnostics:

• Traceroute (intervals_sec.traceroute)
• MTU discovery via DF ping binary search (intervals_sec.mtu_test)
• DNS re-resolution (intervals_sec.dns_reresolve)

Delivery Verification Modes

Set delivery_verification.mode:

1. bot_api_ack (default)

• Confirm only Bot API acceptance (sendMessage success).
• Lowest overhead.
• Does not prove handset render/read.