Selfhosted Connectivity: Wi-Fi, LAN Inventory, TR-181, and EasyMesh

TL;DR

Home connectivity is not just “do I have internet?”. A useful homelab needs repeatable checks for Wi-Fi quality, throughput, latency under load, LAN inventory, DNS behavior, and eventually router/AP-side telemetry through TR-181, OpenWrt, USP, and maybe EasyMesh.

Intro

The home network is the base layer for everything else I self-host: backups, media, VPN, local AI services, chat, monitoring, and family communication.

This post organizes my June 2026 connectivity notes around one practical question:

What can I observe from a Raspberry Pi inside the LAN, and what can only the router or access point know?

The short answer is:

• A Pi can measure its own Wi-Fi link, DNS behavior, latency, throughput, and IP-level LAN inventory.

• It cannot reliably know Wi-Fi quality for every other client.

• Per-client RSSI, bitrate, band, and association state live on the AP/router side.

• TR-181 becomes useful when a real device maps live router state into the data model.

• OpenWrt matters most when it is running as the AP/gateway, not merely as another Wi-Fi client.

• TR-471 Speed Test: Broadband Forum UDP performance test tool.

• Pi Connectivity: connectivity checks inside hermesagent.

The Problem

I had several related questions mixed together:

• How good is the Pi’s current Wi-Fi connection?
• Can I measure throughput and latency in a repeatable way?
• Can nmap show Wi-Fi quality for other devices?
• What does TR-181 expose, and what does it need from the device underneath?
• Would OpenWrt on a Pi unlock more Broadband Forum / TR-181 fields?
• Where do Wireshark, Pi-hole, AdGuard, Unbound, TapMap, and LAN scanning fit?

Those questions belong in one connectivity post, but they need separation by layer. Wi-Fi radio metrics, IP discovery, DNS observability, packet capture, throughput testing, and TR-181 modeling are related, but they are not the same tool surface.

Measurement Stack

The practical stack I want is:

The trap is expecting one tool to answer every layer. nmap is useful, but it is not a Wi-Fi signal tool. Pi-hole is useful, but it is not a packet capture tool. TR-181 is useful, but only when backed by real device state.

First Pi Measurements

The Pi was connected to the Piszymsiu SSID with a strong 5 GHz signal.

iwconfig wlan0
iw dev wlan0 link

The relevant readings were:

RSSI rule of thumb:

The scan also showed the ISP gateway exposing multiple radios under the same SSID. In practice, the Pi was band-steered to the cleaner-looking 5 GHz radio.

iwconfig wlan0
iw dev wlan0 link
watch -n 1 'iwconfig wlan0 | grep Signal'
cat /proc/net/wireless
sudo iw dev wlan0 survey dump
sudo iw dev wlan0 scan | grep -E "SSID|freq|signal" | head -40

wlan0  IEEE 802.11  ESSID:"Piszymsiu"
       Link Quality=63/70  Signal level=-47 dBm

Connected to 2c:ec:f7:4b:b5:a8 (on wlan0)
    SSID: Piszymsiu
    freq: 5500.0
    signal: -49 dBm
    rx bitrate: 433.3 MBit/s
    tx bitrate: 433.3 MBit/s

TR-471 Throughput Testing

I also tested a Broadband Forum TR-471-style UDP speed test flow with obudpst.

# make server
make client SERVER=192.168.1.18
make client SERVER=192.168.1.18 ARGS="--json --client-name $(hostname)"
# make analyze-file FILE=result_jalcocert-x300.json

The key result: the run sustained about 118.75 Mbps upload with no packet loss at the selected sustain rate, but latency rose sharply under load.

That points to a link that can move data, but still deserves QoS/AQM attention if interactive traffic matters.

{
  "timestamp": "2026-06-11T10:09:12Z",
  "client": "jalcocert-x300",
  "server": "192.168.1.18",
  "direction": "upload",
  "datagram_size": 1450,
  "phases": {
    "ramp_up": [
      {"rate_mbps": 1, "throughput_mbps": 1.0, "loss_pct": 0, "avg_latency_ms": 9.8, "verdict": "PASS"},
      {"rate_mbps": 2, "throughput_mbps": 2.0, "loss_pct": 0, "avg_latency_ms": 9.8, "verdict": "PASS"},
      {"rate_mbps": 5, "throughput_mbps": 5.0, "loss_pct": 0, "avg_latency_ms": 9.7, "verdict": "PASS"},
      {"rate_mbps": 10, "throughput_mbps": 10.0, "loss_pct": 0, "avg_latency_ms": 10.9, "verdict": "PASS"},
      {"rate_mbps": 20, "throughput_mbps": 20.0, "loss_pct": 0, "avg_latency_ms": 11.2, "verdict": "PASS"},
      {"rate_mbps": 50, "throughput_mbps": 50.0, "loss_pct": 0, "avg_latency_ms": 12.1, "verdict": "PASS"},
      {"rate_mbps": 100, "throughput_mbps": 99.99, "loss_pct": 0, "avg_latency_ms": 85.6, "verdict": "PASS"},
      {"rate_mbps": 200, "throughput_mbps": 123.46, "loss_pct": 38.27, "avg_latency_ms": 249.4, "verdict": "FAIL"}
    ],
    "refine": [
      {"rate_mbps": 150.0, "throughput_mbps": 121.36, "loss_pct": 19.09, "avg_latency_ms": 274.4, "verdict": "FAIL"},
      {"rate_mbps": 125.0, "throughput_mbps": 117.01, "loss_pct": 6.39, "avg_latency_ms": 261.7, "verdict": "FAIL"},
      {"rate_mbps": 112.5, "throughput_mbps": 112.5, "loss_pct": 0, "avg_latency_ms": 161.1, "verdict": "PASS"},
      {"rate_mbps": 118.8, "throughput_mbps": 118.75, "loss_pct": 0, "avg_latency_ms": 171.1, "verdict": "PASS"},
      {"rate_mbps": 121.9, "throughput_mbps": 120.51, "loss_pct": 1.11, "avg_latency_ms": 246.6, "verdict": "FAIL"}
    ],
    "sustain": {
      "rate_mbps": 118.8,
      "throughput_mbps": 118.75,
      "loss_pct": 0,
      "avg_latency_ms": 211.3
    }
  },
  "max_capacity_mbps": 118.8,
  "measured_mbps": 118.75,
  "packet_loss_pct": 0,
  "avg_latency_ms": 211.3,
  "_diagnostics": {
    "idle_latency_ms": 9.7,
    "loaded_latency_ms": 85.6,
    "saturation_rate_mbps": 100,
    "bufferbloat_ratio": 8.8,
    "est_buffer_formatted": "948.7 KB",
    "link_classification": "Fast Ethernet (100 Mbps) or 802.11n 2.4 GHz Wi-Fi - mild bufferbloat",
    "recommendations": [
      "Moderate bufferbloat - consider QoS or AQM tuning"
    ]
  }
}

TR-181: The Data Model I Want

TR-181 is the Broadband Forum data model for describing customer-premises network devices.

It is the vocabulary. TR-069/CWMP and TR-369/USP are protocols that can speak that vocabulary.

Example paths:

Device.DeviceInfo.ModelName
Device.WiFi.Radio.1.Channel
Device.WiFi.SSID.1.SSID
Device.WiFi.AccessPoint.1.AssociatedDevice.1.SignalStrength
Device.IP.Interface.1.IPv4Address.1.IPAddress

The important distinction:

My tr181-dump.sh script is not a real USP Agent. It is a pragmatic script that shapes Linux state into TR-181-like paths so I can inspect the model locally.

~/tr181-dump.sh
~/tr181-dump.sh --scan
~/tr181-dump.sh --filter Radio

Covered branches:

• Device.DeviceInfo.*
• Device.Time.*
• Device.Ethernet.Interface.1.*
• Device.IP.Interface.{i}.*
• Device.DNS.Client.Server.{i}.*
• Device.WiFi.Radio.1.*
• Device.WiFi.SSID.1.*
• Device.WiFi.EndPoint.1.*
• Device.WiFi.NeighboringWiFiDiagnostic.Result.{i}.* with --scan

Warning: The Pi can expose its own station-side Wi-Fi state. It cannot magically expose AP-side data for every client unless it is acting as the AP, or it can query the real AP/router.

Why OpenWrt Matters

OpenWrt itself is not “TR-181 by default”, but it has the right substrate: uci, ubus, netifd, hostapd, dnsmasq, firewall state, DHCP leases, and Wi-Fi association data.

With bbfdm + obuspa, that state can become a proper TR-181/USP surface.

The biggest jump is not “Raspberry Pi OS to OpenWrt”. The biggest jump is station to AP/gateway.

The AP is the device that has the useful per-client Wi-Fi truth.

Seeing Other Devices’ Wi-Fi Quality

nmap cannot tell me RSSI, band, bitrate, or noise for other devices. It works at IP/service level. Wi-Fi quality is a radio-layer property.

There are three real paths:

For LAN inventory, nmap and ARP tools still matter:

sudo nmap -sn 192.168.1.0/24
sudo arp-scan --interface=wlan0 --localnet
ip neigh show

For AP-side Wi-Fi state on OpenWrt:

iwinfo phy0-ap0 assoclist
hostapd_cli all_sta
obuspa -c get Device.WiFi.AccessPoint.*.AssociatedDevice.*.SignalStrength

For monitor mode on a Pi 4, the onboard Broadcom radio needs nexmon for proper monitor mode. In practice, a separate USB Wi-Fi adapter is cleaner because one radio cannot comfortably stay connected and sniff at the same time.

LAN Inventory

I generated a LAN inventory for 192.168.1.0/24.

This is useful for the device inventory side of connectivity, but it does not prove anything about Wi-Fi signal. The scan found 11 active hosts.

A few devices were worth identifying more carefully: unknown IoT vendors, ESP32-style devices, randomized MACs, and the ISP gateway.

LAN Check - 192.168.1.0/24
Date: 2026-05-18
Host: Raspberry Pi (192.168.1.18 on wlan0)
Method: ARP-based discovery and OUI lookup. No port scanning performed.

sudo apt-get install -y nmap
sudo nmap -sV -sC -p- --script=safe 192.168.1.9 192.168.1.11 192.168.1.12 192.168.1.17

DNS, Packets, and Local Process Traffic

Connectivity debugging needs tools at different layers.

• Wireshark: packet capture and protocol inspection.
• Pi-hole: DNS-level visibility for the LAN.

Wireshark is for packets and conversations: DNS failures, TCP resets, TLS handshakes, HTTP behavior, DHCP, mDNS, NTP, SMB, and .pcap captures.

Pi-hole, AdGuard Home, and Unbound answer a different question: what names are devices resolving, and which clients are talking to which services?

TapMap is another useful local view for processes and traffic on the host:

docker run --rm \
  --network host \
  --pid host \
  -v ~/tapmap-data:/data \
  -e TAPMAP_IN_DOCKER=1 \
  olalie/tapmap:latest

Then open:

http://localhost:8050/

git clone /Home-Lab
cd .Home-Lab/z-homelab-setup/evolution
sudo docker compose -f 2605_docker-compose.yml up -d wireshark

ip.addr == 192.168.1.50
tcp.port == 443
dns
http

EasyMesh Direction

EasyMesh is interesting because it standardizes multi-AP coordination.

A controller coordinates one or more agents, and the mesh shares client metrics such as RSSI, capabilities, and load.

That matters for TR-181 because EasyMesh data can surface under paths such as:

Device.WiFi.DataElements.*

Could I deploy an EasyMesh agent on a Pi? Yes, but the practical caveats are real:

• One radio is awkward because EasyMesh wants fronthaul and backhaul roles.
• A Pi 4 onboard Wi-Fi radio is not a great long-running AP.
• A USB Wi-Fi adapter makes the lab more realistic.
• A controller is still needed; for learning, the same OpenWrt/prplMesh box can run both controller and agent.
• Consumer mesh kits usually will not interoperate cleanly with a custom prplMesh lab.

The most useful lab setup would be:

1. Spare Pi or small router running OpenWrt.
2. USB Wi-Fi adapter acting as AP.
3. bbfdm + obuspa exposing TR-181/USP.
4. prplMesh running controller and agent roles.
5. Pi-hole/AdGuard providing DNS visibility.

The Selfhosted Connectivity Repo

The article is also turning into a small connectivity-checking project.

cd /home/jalcocert/selfhosted-connectivity
make setup
make snapshot
make report
make server

The local dashboard target was:

http://192.168.1.18:8080/

Useful device inventory commands:

make devices-remember ID=192.168.1.12 NAME=laptop TAGS=trusted
make devices-remember ID=192.168.1.13 NAME=appliance TAGS=iot
make devices-list
make snapshot
make devices-history
make wifi-watch SAMPLES=12 INTERVAL=5

For scheduled snapshots:

make install-systemd-user
make scheduler-status
make scheduler-run
make scheduler-logs
SELFHOSTED_CONNECTIVITY_INTERVAL=30min make install-systemd-user

That split is useful because some checks can run directly on the Pi, while others work better as a server plus local client workflow.

Self-Hosting Updates From The Same Maintenance Window

These notes are not the core of the connectivity post, but they happened in the same maintenance window. I am keeping them collapsed so they remain findable without taking over the article.

cd ./Home-Lab/matrix-conduit
nano conduit.toml
docker compose up -d
curl -fsS https://what.everdomain.com/_matrix/client/versions

df -hT /mnt/data2tb /mnt/data1tb /mnt/backup2tb

sync_root="$(openssl rand -base64 24 | tr -d '=+/' | cut -c1-16)"
sync_pass="$(openssl rand -base64 24 | tr -d '=+/' | cut -c1-16)"

set_var() {
  key="$1"
  value="$2"
  if grep -q "^${key}=" .env; then
    sed -i "s|^${key}=.*|${key}=${value}|" .env
  else
    printf '\n%s=%s\n' "$key" "$value" >> .env
  fi
}

set_var MYSQL_ROOT_PASSWORD_SYNC "${sync_root}"
set_var MYSQL_PASSWORD_SYNC "${sync_pass}"
set_var MYSQL_DATABASE_SYNC "nextcloud_sync"
set_var MYSQL_USER_SYNC "nextcloud_sync"
set_var MYSQL_HOST_SYNC "nextclouddb-sync"
set_var NEXTCLOUD_TRUSTED_DOMAINS_SYNC "http://192.168.1.2:8069"

sudo docker compose -f 2605_docker-compose.yml up -d nextclouddb-sync nextcloud-app-sync

curl -X PATCH \
  "https://api.cloudflare.com/client/v4/zones/some/rulesets/thing/rules/secret" \
  -H "Authorization: Bearer $CF_AUTH_TOKEN" \
  -d '{
    "action": "block",
    "description": "allow countries",
    "enabled": true,
    "expression": "(http.host eq \"whatever.domain.com\" and not ip.src.country in {\"ES\" \"CH\"})",
    "id": "sth"
  }'

time rclone copy \
  "googledrive:x300-backup/data2tb/Z_BackUP_HD-SDD/Musica" \
  "/mnt/data2tb/restored/Z_BackUP_HD-SDD/Musica" \
  --progress

rclone copy \
  "googledrive:x300-backup/data2tb/Z_BackUP_HD-SDD/Z_FOTOS" \
  "/mnt/data2tb/restored/Z_BackUP_HD-SDD/Z_FOTOS" \
  --progress \
  --transfers 4 \
  --checkers 8

rclone check \
  "googledrive:x300-backup/data2tb/Z_BackUP_HD-SDD/Z_FOTOS" \
  "/mnt/data2tb/restored/Z_BackUP_HD-SDD/Z_FOTOS" \
  --one-way

mkdir -p ~/osmo-internal ~/osmo-sd
sudo mount /dev/sdc ~/osmo-internal
sudo mount /dev/sdd ~/osmo-sd

rsync -av --info=progress2 \
  --include='*/' \
  --include='*.MP4' \
  --include='*.mp4' \
  --exclude='*' \
  "$HOME/osmo-internal/" \
  "/home/jalcocert/Desktop/YoutubeVideos/OsmoAction/"

rsync -av --info=progress2 \
  --include='*/' \
  --include='*.MP4' \
  --include='*.mp4' \
  --exclude='*' \
  "$HOME/osmo-sd/" \
  "/home/jalcocert/Desktop/YoutubeVideos/OsmoAction/"

What I Learned

• The Pi’s own Wi-Fi metrics are easy to collect with iwconfig, iw, and scan/survey commands.
• TR-471-style testing gives a better view than a simple speed test because it exposes loss and latency under load.
• nmap is useful for LAN inventory, not Wi-Fi quality.
• Per-client RSSI is AP-side truth. The router/AP is the device to query or replace.
• OpenWrt becomes much more valuable when the device is acting as AP/gateway, not merely as another Wi-Fi client.
• TR-181 is a useful schema, but it only becomes operationally rich when backed by real system state through something like bbfdm.

What I Would Do Differently

I would keep future work split into three smaller artifacts:

1. A repeatable pi-connectivity project for local Wi-Fi, DNS, LAN, and latency checks.
2. A router/AP lab note for OpenWrt, bbfdm, obuspa, and EasyMesh.
3. A monthly self-hosting update post for Matrix, Nextcloud, rclone, and media maintenance.

That split keeps the public post readable while still preserving the lab notebook trail.

Durable Takeaways

• Connectivity observability starts at the LAN edge, but the richest Wi-Fi data lives on the AP.
• A Pi as a station is a good measurement client, not a full network observability source.
• TR-181 is most useful when a real agent maps it to live router state.
• DNS observability and packet capture solve different layers of the same home-network debugging problem.
• LAN inventory should be periodic, because self-hosted networks quietly accumulate devices.

Conclusion

The current home network looks healthy from the Pi’s point of view: strong 5 GHz RSSI, clean channel selection, and usable throughput.

The weak spot is observability, not raw connectivity.

The next serious step is not more ad hoc commands on the Pi. It is an AP/router-side lab: OpenWrt with bbfdm, obuspa, and possibly prplMesh, so the network can expose per-client Wi-Fi and LAN state through a standard model instead of scattered one-off checks.

• Travel Router: GL-MT3000 review.
• More Telco Stuff: concepts and tools for the telecom industry.

FAQ

RSSI vs SNR vs bandwidth

RSSI is received signal strength. SNR is signal compared with the noise floor. Bandwidth is channel width or data capacity depending on context. A strong RSSI helps, but loaded latency and packet loss still matter.

Can nmap show Wi-Fi signal for other devices?

No. nmap works at the IP/service layer. RSSI, band, bitrate, and noise are radio-layer properties. Use the AP/router, monitor mode, or each client device.

What is the difference between SSID and BSSID?

SSID is the network name. BSSID is the MAC address of a specific AP radio. One SSID can have several BSSIDs across bands, mesh nodes, or enterprise APs.

Why does the AP know client RSSI better than the Pi?

RSSI is measured by the receiving radio. The Pi knows how loudly it hears the AP. The AP knows how loudly it hears each client. For client diagnostics, the AP-side number is usually the useful one.

What is DFS, and why is channel 100 interesting?

DFS channels in 5 GHz are shared with radar systems. They can be less crowded, but the AP must move if radar is detected. Channel 100 was useful here because nearby lower 5 GHz channels looked busier.

Would OpenWrt on the Pi add more TR-181 fields?

Yes, especially with bbfdm + obuspa, but the role matters. A Pi as a Wi-Fi station still cannot report AP-side client RSSI. A Pi or router acting as AP/gateway exposes much more useful network state.

Can I run an EasyMesh agent?

Yes, with OpenWrt/prplMesh, but a practical lab wants at least one good USB Wi-Fi adapter and a controller. Running both controller and agent on the same lab box is fine for learning.

Pi-hole, AdGuard, or Unbound?

They solve DNS visibility and resolution, not radio quality. Pi-hole or AdGuard Home are good for seeing what devices resolve. Unbound is useful when you want local recursive DNS behavior.

What is QoS/AQM?

QoS is traffic prioritization. AQM, such as SQM with modern queue disciplines, actively manages queues so latency does not explode when the link is full. For home networks, AQM is often the practical fix for bufferbloat.

Where does Friis path loss fit?

Friis path loss is the radio propagation model behind the intuition that signal drops with distance and frequency. It is useful background for Wi-Fi planning, but real homes add walls, reflections, antennas, interference, and client behavior.

Related Notes

• Connectivity observability starts at the LAN edge
• Self-hosted servers need periodic inventory
• DNS is privacy infrastructure
• Backups are recovery design, not storage
• Media servers need organization before more storage

References

• Broadband Forum
• TR-181 spec page
• TR-369 / USP overview
• obuspa
• obudpst
• bbfdm
• nexmon
• OpenWrt
• prplMesh
• TapMap
• TapMap docs
• OpenWrt on Raspberry Pi