The Mobility Client attempts to find the
fastest IP interface that has a route to connect with the Connection Manager.
All available IP interfaces on the computer are examined for the advertised
speed of the interface and the routing characteristics of the interface.
When no usable IP interface is found, the connection process waits
until one becomes available. The window that displays shows the status
of the connection in the bar at the bottom of the window. The message Opening
Connection indicates that the
client is looking for a valid local IP interface to use. If no local IP
interface is found then after two minutes, an error message displays. After
a local IP interface is found the Mobility Client creates a host route
using the local IP interface to force traffic destined for the Connection
Manager to flow over the specific interface.
The Mobiliity Client then attempts to connect to the Connection Manager
using UDP. A UDP packet containing the text WECM-ECHO is sent to the Connection
Manager and if a response is received, the log-in flow begins. The UDP
packet is set to the maximum size of the MTU reported by Windows minus
space for headers. Setting the packet size is done to root out any black
holes in the network between the client and the Connection Manager.
The status bar of the connection window is updated with the protocol being
attempted and the network interface being used. To the right of that
is the number of packets sent and received. If no response to the UDP packet
is received in three seconds, the size is decremented by 100 bytes and
it is retransmitted. A maximum of four UDP packets are sent and if
no response is received, the client attempts to connect via HTTP.
The primary use of HTTP is an attempt to get a connection established in
network environments that do not forward UDP, such as certain WiFi hotspots
or hotel networks. The Mobility Client attempts to open a TCP connection
to the Connection Manager. If the client fails to establish a TCP connection,
then the connection attempt fails and the users see messages that the connection
failed and timed out. If a TCP connection is successful, an HTTP POST is
sent and a specific HTTP reply is expected. If an unexpected reply is received,
a message indicates that the reply was unexpected and offers a link to
investigate the situation before retrying the connection. This situation
can occur when users must first accept terms using a browser before being
granted access to the network.
In this case, the user clicks the link to launch a default browser and
enters the opt-in information. Users would also see this dialog when
the Connection Manager is not configured to use HTTP and a Web server is
running on the same system as the Connection Manager. Or, if the client's
configuration has the wrong address for the Connection Manager and the
target system is running a Web server.
After the Mobility Client can communicate to the Connection Manager using
either UDP or HTTP, it attempts to authenticate the user. The status bar
of the connection window indicates that it is logging on and the two bars
above the graphics change to the color green. The number of packets sent
and received are updated as the authentication phase is completed and after
authentication completes, the connection window closes.