Wi-Fi, TCP/IP & Embedded Networking Engineering
Production Wi-Fi firmware, TCP/IP stack configuration, and network protocol implementation for embedded devices — from 802.11 association and DHCP to TLS mutual authentication, MQTT, and OTA update over contested enterprise Wi-Fi.
What We Build on This Platform
802.11 Station & AP Firmware
Wi-Fi station mode association, background scan, reconnect state machine, and AP mode with configurable DHCP server for provisioning and local network modes on ESP-IDF and embedded Linux targets.
WPA2-Enterprise & 802.1X
EAP-TLS, EAP-PEAP, and EAP-TTLS for enterprise Wi-Fi network authentication, including per-device client certificate provisioning and RADIUS CA chain validation for hospital, manufacturing, and campus deployments.
TLS Stack & Certificate Management
mbedTLS and WolfSSL TLS 1.3 configuration, mutual TLS for device-server authentication, certificate pinning, and certificate storage in NVS, secure element, or encrypted filesystem.
MQTT over TLS
MQTT 3.1.1 and MQTT 5.0 over TLS with QoS 0/1/2, reconnect backoff with jitter, offline message queuing, last-will configuration, and MQTT 5.0 enhanced authentication for cloud broker integration.
mDNS & DNS-SD Service Discovery
Multicast DNS for zero-configuration device discovery and DNS-SD service advertisement for companion app device discovery on local networks, including conflict resolution for duplicate device names.
OTA Update over HTTP/HTTPS
Secure OTA firmware update via HTTPS with binary signature verification, delta update for bandwidth-constrained deployments, and power-loss-safe partition commit using dual-bank OTA with automatic rollback.
Power-Save & DTIM Configuration
802.11 power-save mode, DTIM period configuration, and Wi-Fi modem sleep interaction with application latency requirements — including the tradeoff between beacon interval, DTIM period, and wake latency.
Wi-Fi Provisioning
BLE-based Wi-Fi provisioning (ESP Bluetooth provisioning, Apple WAC, or custom BLE provisioning service), soft-AP provisioning, and WPS — with credential storage in NVS encryption partition.
How Ankh Uses This Platform
Network Architecture & Protocol Stack
TCP/IP stack is selected for the target RTOS and microcontroller: lwIP with esp-netif for ESP-IDF on ESP32 targets, FreeRTOS+TCP for STM32 and other Cortex-M targets, Linux kernel TCP/IP for embedded Linux on i.MX or AM335x platforms. TLS library is selected based on compliance requirements: mbedTLS for most embedded targets, WolfSSL for FIPS 140-2 Level 1 requirements. Application protocol is selected for the product's communication pattern: MQTT for persistent bidirectional device-cloud communication, HTTPS for request-response, WebSocket for streaming telemetry to a browser or Node.js backend. Protocol-level memory footprint is profiled before implementation to verify the target microcontroller has sufficient RAM for the TLS handshake buffers.
Security Configuration
TLS 1.2 versus TLS 1.3 decision is made based on the server's TLS support and the client's available cipher suite implementations — TLS 1.3 reduces handshake round-trips but requires ECDHE support, which adds latency on microcontrollers without hardware ECC acceleration. Certificate chain validation is configured for the CA chain of the cloud backend, with explicit root CA pinned in firmware. Client certificate and private key storage is placed in NVS with NVS encryption enabled to prevent extraction via JTAG or serial flash readback. Certificate pinning versus CA validation is evaluated based on the product's OTA update lifecycle — CA validation is preferred when the server certificate may rotate before the device can be updated.
Wi-Fi Association & Reconnect Logic
SSID and passphrase are stored in NVS with NVS encryption enabled, using a separate NVS namespace partition to allow factory reset without erasing provisioning data. Association state machine is designed for the product's connectivity requirement: always-connected devices implement exponential backoff with per-device random seed to avoid DHCP exhaustion storms; periodic-connect devices implement scheduled wakeup association. RSSI monitoring triggers a scan and roaming decision at a configurable RSSI floor, with 802.11r fast BSS transition, 802.11k neighbor report requests, and 802.11v BSS transition management for enterprise AP roaming.
MQTT/HTTP Implementation & Testing
MQTT topic design and QoS level selection are finalized with the cloud backend team before firmware implementation. MQTT client is configured with keepalive interval, clean versus persistent session selection, and a last-will message that the broker publishes on unexpected client disconnect. HTTP client is configured with connection pooling, chunked transfer encoding for OTA payloads, and socket-level timeout at both the connect and receive phases. Testing is conducted against the target cloud backend at simulated production device count using a load generator, to validate broker throughput, Lambda concurrency, and DynamoDB write capacity at fleet scale.
RF Performance & Regulatory
Wi-Fi conducted output power is measured across all channels and compared to the module or chip specification and regulatory limit. Antenna is selected and placed based on PCB and enclosure constraints, with keep-out zones enforced around the antenna feed. Pre-compliance 802.11 radiated measurements are taken in the enclosure at FCC Part 15E and CE RED ETSI EN 300 328 test configurations. Coexistence measurement validates that simultaneous Wi-Fi and BLE operation does not degrade Wi-Fi throughput below the product's minimum connectivity requirement. Regulatory submission is managed from measurement data through FCC grant.
Deep Technical Capability
DHCP Exhaustion and Reconnect Storm Management in Large Wi-Fi Deployments
When 500 IoT devices on the same access point lose power simultaneously — a common scenario in a factory power outage — and then reboot within a 30-second window after power restoration, the network infrastructure faces a coordinated traffic spike at every layer of the stack. The DHCP server receives 500 simultaneous DISCOVER requests, potentially exhausting the configured address pool if leases from the previous session haven't expired. The TCP/IP stack on each device initiates TLS handshakes simultaneously, creating a CPU load spike on the cloud load balancer. The MQTT broker receives 500 simultaneous CONNECT packets, triggering session restore operations for each persistent session. The cloud backend's Lambda function concurrency limit is saturated by the simultaneous rules engine invocations. At the infrastructure level, the traffic spike resembles a DDoS attack and may trigger rate limiting. Ankh implements randomized reconnect jitter in firmware using a per-device random seed derived from the device's MAC address or serial number, so the 500-device reboot produces a Poisson-distributed reconnection arrival over 5 minutes rather than a 30-second burst. DHCP lease time is configured for rapid expiry of stale leases. MQTT reconnect backoff is implemented with capped exponential backoff plus jitter. These measures are validated under simulated power cycle testing before production deployment.
WPA2-Enterprise EAP-TLS Certificate Provisioning for IoT Devices
WPA2-Enterprise with EAP-TLS authentication requires each device to present a unique client certificate that the RADIUS server validates against a trusted CA. Unlike consumer WPA2-Personal where a shared passphrase is acceptable, enterprise EAP-TLS provides per-device identity — but it imposes a factory provisioning requirement that most embedded hardware programs are not designed for. Ten thousand IoT devices require ten thousand unique client certificates programmed at manufacturing time, stored in a partition that survives OTA firmware updates but can be read by the Wi-Fi driver. Ankh designs the end-to-end enterprise Wi-Fi provisioning flow: CA hierarchy design (root CA offline, intermediate CA online for CSR signing), per-device certificate generation from device serial number using the SCEP or EST protocol at the factory programming station, certificate programming into an encrypted NVS partition during production testing, RADIUS server configuration for the device CA chain, and certificate validity period and renewal design for the 10-year product lifecycle. The certificate provisioning throughput must keep pace with the factory test station cycle time, which typically requires a scripted certificate issuance pipeline rather than a manual web UI.
TLS Memory Overhead on Constrained Embedded Targets
TLS 1.3 with AES-128-GCM and ECDHE_RSA key exchange on mbedTLS requires approximately 50KB of RAM for handshake buffers during the handshake phase: the certificate chain from the server may be 3-4KB, the ECDHE computation requires a 32-byte private key and working buffers, and the record layer maintains separate send and receive buffers sized to the maximum TLS record size (16KB by default). On an STM32F030 with 4KB of RAM, this is physically impossible. On an STM32F4 with 192KB of RAM, TLS is feasible but the 50KB handshake allocation must be accounted for in the application heap budget, since it competes with sensor data buffers, MQTT message queues, and RTOS task stacks. Ankh profiles TLS memory consumption using mbedTLS memory tracking hooks for the specific cipher suite and server certificate chain, then applies mbedTLS compile-time configuration options that reduce RAM usage: MBEDTLS_SSL_IN_CONTENT_LEN and MBEDTLS_SSL_OUT_CONTENT_LEN set to actual maximum record sizes, MBEDTLS_SSL_CONTEXT_SERIALIZATION for session resumption without retaining full context, and record size limit extension negotiation to reduce the server's maximum record size. The application heap is sized around the TLS peak allocation from day one, rather than discovering the out-of-memory condition when the first production unit fails to establish a TLS connection.
Products Built on This Platform
IoT Devices
MQTT over TLS and dual-bank OTA update for ESP32-based connected sensor hardware.
View ProductSmart Home Automation
Wi-Fi provisioning, mDNS discovery, and local HTTP API for hub and device products.
View ProductSmart Agriculture
WPA2-Enterprise integration and reconnect logic for farm network IoT deployments.
View ProductIndustrial Equipment Monitoring
802.1X EAP-TLS authentication for factory floor IoT nodes on enterprise Wi-Fi.
View ProductCold Chain Monitoring
TLS mutual authentication and MQTT QoS 1 for tamper-evident temperature telemetry.
View ProductAtmospheric Sensors
Power-save DTIM configuration for battery-operated outdoor atmospheric monitoring nodes.
View ProductWi-Fi firmware engineered for the contested enterprise network, not the development bench router
An IoT product that connects reliably to a development lab router may fail intermittently on an enterprise network with 802.1X authentication, hidden SSIDs, 5GHz-only access points, and an IT-managed DHCP server with aggressive lease reclaim. Ankh tests Wi-Fi firmware against enterprise network configurations that match the product's target deployment environment — including RADIUS-authenticated EAP-TLS, VLAN segmentation, and AP configurations that reject probe requests on certain channels. The reconnect state machine is validated against network conditions that cause failures not visible in development: DHCP NACK on rapid reconnect, RADIUS authentication latency under load, and AP transition during roaming.
TLS configuration that actually fits in the microcontroller's RAM
TLS memory overhead is one of the most commonly underestimated constraints in embedded networking design. A TLS implementation copied from an ESP-IDF example and running on an ESP32 with 520KB of RAM works fine; the same TLS configuration ported to an STM32F4 with 128KB of RAM produces intermittent out-of-memory crashes under specific server certificate chain lengths or when the MQTT message queue fills simultaneously with a TLS handshake. Ankh profiles TLS memory consumption using mbedTLS heap tracking at the actual handshake and record processing phases, identifies the peak allocation that determines the minimum heap requirement, and applies the mbedTLS compile-time options that reduce footprint without breaking the TLS session against the production server.
Reconnect logic designed for fleet reboots, not single-device development
Reconnect behavior that looks correct in a single-device test — immediate retry, then backoff — produces a coordinated reconnection storm when 500 devices on the same network lose power simultaneously and reboot within a 30-second window. The DHCP server, RADIUS authenticator, MQTT broker, and cloud backend all receive the same load spike that a single-device test never reveals. Ankh designs reconnect logic with per-device random jitter seeded from hardware identity, DHCP lease configuration that supports rapid lease reclaim, and MQTT session configuration that reduces broker reconnect overhead — then validates the fleet reconnect behavior under simulated power cycle testing at the target device density.