Multi-Homed Network Routing in Windows Mobile 6.5

Windows Mobile 6.5 managed complex multi-homed configurations by combining a traditional Windows CE TCP/IP routing table with an abstracted policy engine known as the Connection Manager. When multiple interfaces—such as Wi-Fi, cellular data (GPRS/EDGE/HSDPA), Bluetooth PAN, or USB ActiveSync passthrough—were simultaneously active, the operating system relied on dynamic adapter metrics and destination-based network mappings to resolve routing ambiguities and maintain stable connections.

The Role of the Connection Manager

Unlike desktop Windows, where applications generally leave routing decisions strictly to the kernel's IP forward table, Windows Mobile 6.5 placed the Connection Manager (ConnMgr) at the center of all networking operations.

Connection Manager categorized destinations into logical networks (meta-networks), primarily:

  • The Internet: Public networks accessed via Wi-Fi or cellular GPRS/3G.
  • Work (Corporate): Private intranets reached via VPN, direct cellular APNs, or desktop passthrough.

When an application initiated a network request, it requested a connection to a specific meta-network rather than binding to a physical network adapter. Connection Manager matched this request against its configuration service provider (CSP) settings, dynamically spun up the appropriate interface (such as dialing a cellular data session or initiating an L2TP/PPTP VPN), and updated the system's underlying routing tables accordingly.

Dynamic Metric Assignment and Default Gateways

At the IP layer, Windows Mobile 6.5 was built on the Windows CE 5.2 networking stack (tcpip.dll). When multiple physical adapters obtained IP addresses and default gateways, the OS resolved conflicts using interface metric values:

  1. ActiveSync / Desktop Passthrough (RNDIS): Assigned the lowest metric (highest priority). When cradled or connected via USB, all non-local traffic was routed through the host PC's connection.
  2. Wi-Fi (802.11): Assigned a medium-low metric, preempting cellular connections whenever an associated Wi-Fi access point provided DHCP gateway configurations.
  3. Cellular Data (WWAN): Assigned the highest metric (lowest default priority), kept on standby or used primarily when no unmetered or higher-bandwidth connections were present.

If Wi-Fi disconnected, the TCP/IP stack dynamically shifted the primary default gateway (0.0.0.0/0) back to the cellular interface without tearing down active listening sockets, provided the application was resilient to IP address changes.

Policy Routing and Destination Mapping

In multi-homed setups requiring split-routing—such as maintaining an active cellular connection for MMS or enterprise access while routing generic web browsing over Wi-Fi—the system used explicit routing rules:

  • Static Route Injection: Connection Manager added host and subnet-specific routes to the IP routing table when a secondary interface was established. For instance, connecting to a corporate APN added specific Classless Inter-Domain Routing (CIDR) entries directly pointing to internal subnets, leaving the Wi-Fi interface as the default gateway for public traffic.
  • URL/IP Mapping Tables: Using the CMPolicy engine, the OS evaluated domain names and IP ranges. If a request matched an internal corporate pattern, the OS directed the packet through the adapter assigned to the "Work" network, circumventing the standard default gateway.

Multi-Homing Limitations and Socket Binding

While functional for consumer use, Windows Mobile 6.5 exhibited limitations in complex enterprise multi-homed environments:

  • Metric Collisions: If two adapters were assigned the same metric, the stack defaulted to the first adapter initialized, sometimes causing traffic to route across an unintended, slower interface.
  • Lack of Advanced Multi-Path Routing: The OS lacked native support for advanced multi-path policies or load balancing across interfaces.
  • Explicit Socket Binding: Advanced applications requiring simultaneous use of distinct interfaces had to bypass default routing logic entirely. Developers used the IP Helper API (iphlpapi.dll) or bound raw sockets directly to the specific local IP address of the target network adapter via the standard bind() socket function, ensuring traffic exited the intended interface regardless of the global routing table.