Windows Mobile 6.5 Wi-Fi DHCP IP Assignment

This article examines how the Dynamic Host Configuration Protocol (DHCP) managed IP address assignments on Wi-Fi connections in the Windows Mobile 6.5 operating system. It covers the underlying Windows Embedded CE networking architecture, the step-by-step DORA (Discover, Offer, Request, Acknowledge) process over wireless adapters, lease renewal strategies during mobile suspend states, and fallback mechanisms such as APIPA.

The Underlying Architectural Stack

Windows Mobile 6.5 is built on the Windows Embedded CE 5.2 kernel. Networking within this environment relies on the Network Driver Interface Specification (NDIS) 5.1 layer and a compact TCP/IP stack implemented primarily through system dynamic link libraries such as tcpstk.dll.

When a user connects to a Wi-Fi network, the device’s Wireless Zero Configuration (WZC) service or a hardware-specific supplicant authenticates with the Access Point (AP). Once Layer 2 (data link) connectivity is established, the operating system's Connection Manager notifies the TCP/IP stack to configure the network interface. By default, the adapter is set to dynamically obtain an IP address rather than using a static configuration.

The DHCP Lease Process (DORA)

Once the Wi-Fi link state transitions to "connected," the CE DHCP client daemon initializes the standard four-step negotiation over UDP ports 67 (server) and 68 (client):

  1. DHCP Discover: The Wi-Fi adapter broadcasts a DHCPDISCOVER packet across the local wireless subnet to locate available DHCP servers. Because Windows Mobile devices often prioritize quick connection establishment, the client uses an aggressive retry schedule if an immediate response is not received.
  2. DHCP Offer: Available DHCP servers (typically the local Wi-Fi router or access point) respond with a DHCPOFFER packet unicast or broadcast to the device's MAC address, reserving a candidate IP address, subnet mask, default gateway, and DNS servers.
  3. DHCP Request: Windows Mobile evaluates the first valid offer received and responds with a broadcast DHCPREQUEST packet. This notifies the chosen server that its offer has been accepted while signaling other responding servers to release their reserved offers.
  4. DHCP Acknowledge: The designated server sends a DHCPACK packet confirming the IP lease duration and operational parameters. The Windows Mobile TCP/IP stack then writes these values to the active adapter runtime configuration under the registry path [HKEY_LOCAL_MACHINE\Comm\<AdapterName>\Parms\TcpIp].

Handling Power States and Lease Renewals

Power management was a critical consideration in Windows Mobile 6.5. When the device entered an idle or suspended sleep state, the Wi-Fi radio was frequently powered down or placed into a low-power listening mode to conserve battery life.

  • T1 and T2 Timers: Under standard operation, the DHCP client attempts to renew its lease at the T1 interval (50% of the lease duration) via a unicast DHCPREQUEST. If unacknowledged, it attempts re-binding at T2 (87.5% of the lease duration) via broadcast.
  • Resume Behavior: Upon waking from a suspended state, the operating system queries the current BSSID (the MAC address of the connected access point). If the device detects it has reconnected to the same network, it attempts a shortened verification by sending a directed DHCPREQUEST for its existing assigned IP. If accepted with a DHCPACK, the connection resumes instantly. If the AP or network environment changed, or if a DHCPNAK (Negative Acknowledgment) is returned, the client immediately resets the interface and initiates a full DHCPDISCOVER cycle.

Fallback to APIPA and Static Alternatives

If a DHCP server fails to respond within the timeout window (typically 30 to 60 seconds), the Windows Mobile 6.5 stack invokes Automatic Private IP Addressing (APIPA). Following RFC 3927 guidelines, the client assigns itself an address from the reserved block 169.254.1.0 through 169.254.254.255 along with a 255.255.0.0 subnet mask. It verifies that the chosen IP is unique on the local link by broadcasting an Address Resolution Protocol (ARP) announcement. While in this state, the client periodically checks the background network in an attempt to discover an active DHCP server and obtain a routable IP address.