04 / AI NETWORK OPERATIONS · 2026-09-09
A router configured and diagnosed with an agent.
OpenWrt on the NAS, a switch and a Wi-Fi AP form the network. The agent helps migrate router functions, check connections, compare speed and recover from faults.
Configuration · Recovery · Wi-Fi tuning
Hunt through settings, then manually recheck devices and speed
Request → inspect → adjust → verify connectivity and speed
ASK. DIAGNOSE. ADJUST. VERIFY.
Wi-Fi tuning, with an agent doing the checks.
“Wi-Fi is slow. Tune it while keeping the other devices connected.”
- 01Inspect state & channel→
- 02Back up & adjust→
- 03Check speed & other devices→
- 04Keep or roll back
5GHz channel 40 · simultaneous-load test
5GHz channel 149 / 80MHz · sequential test
Measured download rates. Load mode and time limits differ, so this is not a controlled improvement-rate comparison. The later test also recorded 694.9Mbps upload and 29.1ms download-loaded latency.
Address reservations, service routing and an IPTV path were configured. WOL and VPN need their own completion checks.
Records show a DHCP conflict diagnosed and corrected, followed by checks of internet, NAS, web and mail.
Channel changes used the AP management interface; state and logs were checked through SSH. Both Macs on 5GHz and the Pi on 2.4GHz were confirmed after reconnection. OpenWrt, the switch and AP carry the traffic.
FROM REQUEST TO RESULT
How did we make it work?
- 01
Migrate the functions
Map required IPTV paths, address reservations and port forwarding.
- 02
Build the operating setup
The NAS routes, the switch connects wired devices, and the AP provides Wi-Fi.
- 03
Tune with the agent
Inspect connections, logs and channel settings before making targeted changes.
- 04
Retest and recover
Compare speed and other devices’ connections, with rollback when needed.
COULD THIS WORK FOR YOU?
Could this work in your setup?
How does the agent diagnose Wi-Fi, adjust settings and verify improvement?
THE EVIDENCE & LIMITS
Explore the records
What evidence supports this case?
Based on August–September 2026 Codex work records, handover notes and retained programs. Generated system illustrations are not photographs of the installation. Checks are limited to the dates and scope recorded.
01Familiar router features, tedious configuration
The operator valued the old ipTIME router’s IPTV configuration and familiar address reservation, port forwarding, WOL and VPN features, but describes the burden of relearning menus and maintaining website/server connections.
OpenWrt in a NAS VM provides routing, NAT, DHCP, DNS and firewall functions, with an unmanaged switch and Wi-Fi AP handling connectivity. Records support address reservations, service routing and the IPTV path; they do not establish completion of every feature, including WOL and VPN.
02The agent configures, then checks again
The agent uses SSH and device management interfaces to inspect state and configuration, back up settings, make targeted changes and recheck devices and services. Records include correcting a DHCP conflict and verifying internet, NAS, web and mail paths.
Wi-Fi tuning requires checking both performance after a channel/width change and continued connectivity for existing devices. This is network administration; an AI model does not make a decision for every packet.
03Wireless measurements in the 300s and 600s: the actual records
On 9 September 2026, real measurements forced the same Mac Studio onto its Wi-Fi interface. At 10:05 on 5GHz channel 40, download was 311.551Mbps and upload 164.836Mbps. At 10:14 on channel 149 at 80MHz, download was 666.586Mbps and upload 694.916Mbps, with about 29.1ms download-loaded latency.
The earlier networkQuality test used default simultaneous load; the later test used sequential load, with a different time limit. This is not a controlled demonstration that channel tuning alone doubled speed. These are measured traffic rates rather than negotiated link speeds, and the mode difference is disclosed.
The agent inspected nearby channels and reconnection bands, applied channel 149 at 80MHz and confirmed both Macs on 5GHz and the Pi on 2.4GHz. Channel settings used the AP’s HTTPS management interface; SSH was used for state and log checks.
| Field | Earlier observation | Later observation |
|---|---|---|
| Time KST | 10:05 | 10:14 |
| Download | 311.6 Mbps | 666.6 Mbps |
| Upload | 164.8 Mbps | 694.9 Mbps |
| Test mode | Simultaneous load | Sequential load |
| 5GHz channel | 40 | 149 / 80MHz |
0401 · Map the wiring and roles
The existing router, optical terminal and NAS WAN/LAN ports were identified and their configurations backed up.
0502 · Prepare OpenWrt on the NAS
OpenWrt was configured in a NAS virtual machine with separate WAN and LAN paths, centralizing DHCP, DNS and firewall functions.
0603 · Connect through switch and AP
Wired devices connected to the switch and wireless devices to the AP. Separate AP-side NAT and DHCP were removed so devices shared one LAN.
0704 · Operate and check with an agent
SSH supported state inspection, backups, reservations and service routing. After resolving a DHCP conflict, internet, NAS, web and mail paths were rechecked.
08Recorded checks and their limits
The 27 August 2026 record confirms the OpenWrt VM, firewall, NAT, DHCP, DNS and internet connection were working.
The recorded physical links negotiated 2.5 Gbps on NAS LAN and 1 Gbps on WAN; these are link rates, not end-to-end throughput claims.
A transition-time DHCP conflict with the old router was recorded. Stopping the NAS or VM can affect internet access, so backup and recovery paths remain necessary.
Internet → OpenWrt VM in NAS → Ethernet switch → wired devices / wireless AP ⇢ wireless devices. The AI operator uses a separate SSH management path.