Laurent Brand home
← Portfolio homelab
Browse homelab topics

Homelab / Technical documentation

A 2.4 GHz AP for an IoT device.

The historical Ubuntu/hostapd configuration that connected an ECOVACS device, kept distinct from the ASUS’s later Proxmox role.

Jump to a section

Solve the compatibility problem in stages

The 7 November record describes an Intel Wireless 7265 adapter acting as a 2.4 GHz AP: channel 6, 2437 MHz and 20 MHz width. The foreground hostapd test reached AP-ENABLED, with authentication, association and completed WPA handshakes in the described transcript. Earlier disconnects were part of the investigation.

The supplied reconstruction labels these terminal observations Observed. I later confirmed the ECOVACS connection worked. These are historical Ubuntu results. The ASUS is now a Proxmox host; the AP’s current placement is not established.

Evidence: S03 · S19.

Radio settings, without network identifiers

Illustrative · sanitized historical settings · incomplete, not a deployable config
interface=<WIRELESS_INTERFACE>
driver=nl80211
ssid=<IOT_SSID>
hw_mode=g
channel=6
wpa=2
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
wpa_passphrase=<PRIVATE_PASSPHRASE>

The recovered description includes systemd-networkd providing an AP subnet, DHCP, forwarding and masquerading via wired uplink. Exact final networkd contents were not recovered, so no invented addressing/NAT recipe is presented as the working configuration.

Evidence: S03.

What persistence evidence exists

Historical command shapes · S03 · first two commands change service state
sudo systemctl unmask hostapd
sudo systemctl enable --now hostapd
sudo systemctl status hostapd --no-pager
iw dev <WIRELESS_INTERFACE> info

The service was reported enabled and active/running, with AP mode and channel confirmed. The device connection was user-confirmed. Enabling a service is not a recorded reboot test. A station signal around −62 dBm belongs to that particular observation, not a coverage guarantee.

Evidence: S03.

Read-only troubleshooting sequence

  1. Inspect rfkill state and adapter AP-mode capability. If the radio cannot enter AP mode, DHCP changes will not fix it.
  2. Check hostapd service state and AP-enabled/authentication results locally. Redact SSIDs, MAC addresses and client identifiers before sharing logs.
  3. After association, verify the client obtained an address and then test permitted routing/DNS. Association and WPA completion alone do not prove Internet access.
  4. If the workload moved after the ASUS conversion, identify its actual runtime before applying any historical configuration.
Illustrative · read-only · inspect locally
rfkill list
iw list
systemctl is-active hostapd
systemctl is-enabled hostapd
iw dev <WIRELESS_INTERFACE> info

No IoT VLAN or firewall isolation is proven by this AP. OPNsense and replacement Wi-Fi hardware were discussions, not completed parts of this solution.

Evidence: S03 · S19.