Access Point

Access Point #

Purpose #

The access point provides wireless connectivity for mobile devices, laptops, and IoT devices within the site.

graph LR
    A[Access Switch
VLAN trunk] <--> B[Access Point
Wi-Fi] <--> C[Wireless Clients]

Hardware Platforms #

Site: mobile (mobile)

The EAP650-Outdoor is a Wi-Fi 6 outdoor access point from TP-Link’s Omada SDN product line. Despite being outdoor-rated, its rugged design makes it suitable for the mobile site’s varied deployment environments.

TP-Link Omada EAP650-Outdoor

Hardware #

AttributeValue
ModelTP-Link Omada EAP650-Outdoor
Wi-Fi StandardWi-Fi 6 (802.11ax)
BandsDual-band (2.4GHz + 5GHz)
SpeedAX3000 (574 + 2402 Mbps)
Antennas2x2 internal (2.4GHz), 2x2 internal (5GHz)
Ethernet1x Gigabit RJ45
Power802.3at PoE (12.3W typical), from the injector supplied with the AP β€” the SG2218 has no PoE
WeatherproofingIP67
Operating Temp-30Β°C to 70Β°C
MountingWall/pole mount

Selection Rationale #

  • VLAN capable: Supports VLAN tagging per SSID for network segmentation
  • API manageable: Omada controller provides REST API for automation
  • Wi-Fi 6: Modern standard with improved efficiency and capacity
  • Rugged: IP67 rating handles varied mobile deployment conditions
  • Omada ecosystem: Matches mobile switch (SG2218) for unified management
  • PoE powered: Single cable for power and data

Management #

AttributeValue
ControllerTP-Link Omada SDN
VLAN SupportYes β€” per-SSID VLAN tagging
APIYes β€” Omada controller REST API
Automationdeevnet.net Ansible collection (Omada API)

Roles #

RoleDescription
Wireless accessProvides Wi-Fi 6 connectivity for clients
SSID-to-VLAN mappingMultiple SSIDs mapped to VLANs
Band steeringDirects capable clients to 5GHz

Site: home (home) β€” 2 units

The UAP-AC-M is a compact Wi-Fi 5 mesh-capable access point from Ubiquiti’s UniFi product line. Two units provide coverage throughout the home site.

Ubiquiti UniFi UAP-AC-M

Hardware #

AttributeValue
ModelUbiquiti UniFi UAP-AC-M
Wi-Fi StandardWi-Fi 5 (802.11ac)
BandsDual-band (2.4GHz + 5GHz)
SpeedAC1200 (300 + 867 Mbps)
Antennas2x2 MIMO (external)
Ethernet1x Gigabit RJ45
Power802.3af PoE (8.5W max)
WeatherproofingOutdoor rated (IPX5)
MountingWall/pole mount
MeshWireless uplink capable

Selection Rationale #

  • VLAN capable: Supports VLAN tagging per SSID for network segmentation
  • API manageable: UniFi controller provides REST API for automation
  • Mesh capable: Wireless uplink for flexible placement
  • UniFi ecosystem: Matches home switches (USW-24-G2, US-8)
  • Compact: Low-profile design for unobtrusive mounting
  • PoE powered: Single cable for power and data

Management #

AttributeValue
ControllerUniFi Network Application
VLAN SupportYes β€” per-SSID VLAN tagging
APIYes β€” UniFi controller REST API
AutomationUniFi API (manual currently)

Roles #

RoleDescription
Wireless accessProvides Wi-Fi 5 connectivity for clients
SSID-to-VLAN mappingMultiple SSIDs mapped to VLANs
Mesh backhaulWireless uplink between units (if needed)

VLAN and API Capability Summary #

Both access points meet the core selection criteria:

RequirementEAP650-Outdoor (mobile)UAP-AC-M (home)
VLAN taggingβœ“ Per-SSIDβœ“ Per-SSID
API managementβœ“ Omada REST APIβœ“ UniFi REST API
Controller-managedβœ“ Omada SDNβœ“ UniFi Network
PoE poweredβœ“ 802.3atβœ“ 802.3af

Configuration Management #

SiteControllerAutomation
mobileOmada SDNdeevnet.net Ansible collection (Omada API)
homeUniFi NetworkUniFi API (manual currently)

SSID Design #

One SSID per trust class, each carrying one VLAN. The names come from wifi_ssid in deevnet_vlans, and the controller applies them β€” inventory is the only declaration ( ADR-0009).

SSIDVLANSecurityKey
DVNTM10 (trusted)WPA-Personalone shared key, from the vault
DVNTM-IOT30 (IoT)PPSK (security: 4)one key per tenant, issued by the Deevnet API
DVNTM-IOTV31 (IoT Vendor)WPA-Personalone shared key, from the vault
DVNTM-GUEST40 (guest)WPA-Personal + guest isolationone shared key, from the vault

There is deliberately no management SSID. The management segment is reached over the wire.

On DVNTM-IOT the key decides the VLAN. It is a PPSK SSID, so each key in its profile carries its own VLAN binding, and a device lands on the VLAN of the key it was flashed with β€” proven on this AP at firmware 1.3.11 in CHG-0005 phase 6. A per-key VLAN needs no controller network object: it is raw 802.1Q tagging, and the core router serves the DHCP.

Who owns what ( ADR-0012 Β§6):

  • Inventory owns the SSID and the PPSK profile. omada-wireless.yml creates them and never rewrites or deletes what it finds.
  • The Deevnet API owns the keys inside the profile, one per tenant per trust class. A tenant gets one from terraform apply and never touches the controller.
  • The automation therefore does not report those keys as drift. It names the profiles whose contents it is deliberately not inspecting, because reading them would pull every tenant’s password into Ansible’s memory and output.

One entry you may see and should leave alone. The controller refuses to let a PPSK profile reach zero keys (errorCode -34044), although it will happily create one empty. So when the last tenant key in a profile is revoked, the API leaves one placeholder named DEEVNET-PLACEHOLDER-DO-NOT-USE. Its password is generated, returned to nobody and stored nowhere, so it cannot be used to join anything, and it disappears the moment any real key is issued. It is only ever present when the alternative would be an empty profile.

Changing any of this is make wireless in deevnet.net, never the controller UI.

Page last modified: September 18, 2026