Butch Evans Blog

It seems to be “all the rage”.  Mobile IP.  In reality, mobile IP, describes the ability for a user to move across a network without having to renumber his devices.  This definition holds true even if a user moves from one network to another.  In other words, a user is able to keep his IP address without regard to where his device exists on the internet.  That’s not exactly what I’m gonna describe here, but it is a very close approximation.

The solution you are about to read is real and tested….names (and IPs) may be changed to protect the innocent…

I need to say up front that this is not a “normal” cut/paste type tutorial.  There are several reasons for this, but the most important one is because of the complexity of the script.  This type of script is very highly customized for each network or set of networks that the mobile device will connect to.  Additionally, there are several options for the hardware configuration on the mobile device, which makes it impossible to account for in a static article such as this.  Finally, this type of configuration is one that I am actively selling.  If you are interested in a quote, feel free to contact me directly.  You can get my contact information from my consulting website.

Before we get into the technical discussion of HOW to accomplish this (seemingly) “magical” feat I want to talk about some of the uses for this type of technology.  I will begin with a short introduction to some things I have already done as a basis for this portion of the discussion.

In 2006, I got a call from a company in eastern Oklahoma asking for assitance with getting the police department online in their vehicles.  At first, this seemed simple enough of an idea.  Mikrotik provides a scripting host that would allow me to detect the AP we were connected to and configure appropriate IP addresses for that AP.  Getting to the internet was not the issue at hand.  What was needed was an approach that would allow internet access AND provide for other services inside the car.  A short list of some of the things that were required and what was accomplished includes:

• Webcam access from the police department so that the dispatcher can see the vehicle’s current view.
• VoIP phones in the car and even portable devices
• Access for a laptop AND PDA

There were other items on the list, but these were the “main” items.  Ok, so a simple AP in the car would allow for the laptop and PDA to access the internet..simple (still).  But VoIP in a mobile environment is HARSH.  It’s also a little difficult to allow for the webcam access for the PD if we never knew what the IP address of the car’s client was going to be.  I decided that we had to implement SOME form of MIP function and we needed to use Mikrotik to accomplish it, because that’s what I was familiar with and I knew that all the functionality was there, if I could make it work.  The final network configuration looks something like this:

The device on the left center called “Mobile Unit” is a Mikrotik device. The solution I came up with for the company in Oklahoma did not require access across multiple ISPs, but the functionality is the same in either event.  What this diagram shows is a mobile unit that connects wirelessly to a specific set of access points.  When it connects, the script, which we will discuss in a few paragraphs, will configure the appropriate IP addresses for the device and a VPN is established between the mobile unit and the VPN concentrator at the PD (in our case).  This allows the mobile device to have a specific PRIVATE IP, as the configuration for communications purposes includes the setting up of IP space “internally”.  This network configuration solved all the issues we discovered as we tested and tweaked for the full functionality called for by the customer.

Ok, so I probably didn’t fully answer the question I started out to answer.  Specifically, the quesiton is “how is mobile IP useful?”.  Some things to keep in mind are that with a MIP solution, VoIP calls should not be dropped when you are switching APs (and possibly ISPs).  That’s kinda tough, but the above solution makes it possible.  Dispatchers can view a static, private IP address for the camera and other equipment inside the police car.  In an ambulance, IP enabled healthcare equipment can be given static IP addresses, making communication with hospitals easier and potentially more reliable.  VoIP calls can now be routed out to the internet from a single IP address, therefore never losing connectivity, even if we do lose a few packets as we transition between APs.  There are many other uses for this technology, but you get the idea.

This type of solution is useful to municipalities of all sizes for the obvious reasons.  There is money available in the US through the Department of Homeland Security (managed by FEMA) for first responders.  This can dramatically reduce the direct cost to the city or county for building such a network.

As to the technical portion of the discussion, let me begin with an overview of how the different scripts work and the problems they have to overcome.  While it is possible to create a configuration for just a single “internet radio”, I’m going to describe the function of set of scripts designed to work with 2 internet radios.  This is a much more reliable system and is, frankly, a better solution than a single radio.  The overall idea is that radio1 connects to the best AP available and is configured to work on that connection.  This radio becomes our “active” radio.  The “inactive” radio begins a loop where it looks for the best signal available.  It will continue to scan looking for the best signal.  It will do this every 5-10 seconds.  Meanwhile, there is a script that is watching the signal level on the currently “active” radio.  The job of this script is to determine when the “active” radio’s connection is reaching a level that is unreliable.  If this script determines that it is in an unreliable state, then the script moves the network configuration and swaps which radio is active.  At this point, the network is running on the second radio and the first radio becomes the inactive radio searching for a “better” connection.  This allows us to use a protocol like 802.11x and have a very quick network switchover.

Another problem we have to solve is the reality that we don’t know what our IP address will be from one AP to another.  It is possible in Mikrotik to use cellular cards as well.  So, what we have to do is create a tunnel to the core of the network.  This tunnel can be created with a static IP address per user/mobile device.  By doing this, we create a private static IP, which can be used for internal monitoring and such.  It, also, allows us to provide internet access via this central system, which can be monitored or accessed directly.  The tunnel also provides security, as we can use something as simple as PPTP or as secure as OpenVPN.  This is very important in the sense that we want to protect the city’s data (in particular the ambulance and police department) as it goes over networks that are, at times, insecure.

Now that we have that bit of generalization out of the way, let’s dig in a bit and look at some of the scripting and configurations.  Refer back to the network picture above if you need to visualize some of what we are discussing.  The VPN concentrator can be any type of concentrator, but I chose to use an X86 based Mikrotik for this purpose.  The reason I chose Mikrotik is because of the very simple configuration needed.  I’ll not go into the details of how to configure a PPtP server or OpenVPN server at this time, because it’s already pretty well documented at Mikrotik’s Wiki already.  The important thing about the VPN server is that it must have a static, public IP address so that our mobile clients can reach it whereever they are on the Internet.  This requirement assumes that the mobile client will be allowed to connect to an AP that is on another network.  The other requirement for the VPN concentrator is that it must be able to reach the private portions of the network.  For example, if this concentrator is for the police department, the computers in the PD would need to be able to connect to the remote IP space via this concentrator.  This is simple routing, but is worthy of mention.

Each mobile client will have what turns out to be very nearly exactly the same configuration.  The LAN (or vehicle) side of the mobile client will have a unique subnet assigned.  This is how the PD (in our example) will be able to differentiate between vehicles when they want to view the in car camera system.  This is not strictly required, as we could build this into the VPN concentrator in the form of NAT, but it’s just as easy to just make each vehicle unique.  The other part of each mobile client that will be unique is the credentials used to connect to the VPN server.  The reason for this is so that we will be able to automatically assign correct IP information to the tunnel and route the proper subnet to the vehicle.

The radio card(s) will have the same configuration on all client devices.  We will use the functionality of the connect-list to define the access points we are “allowed” to connect to.  This list will most likely be the same for each card, but it’s not an absolute necessity that both cards be configured to connect to the same APs.  In fact, they don’t even have to be in the same band.  Again, the details for how to configure the connect list can be found in Mikrotik’s documentation, so I won’t go too much in detail on that.  Here, however, is an example connect list:

/interface wireless connect-list
add connect=yes disabled=no interface=wlan1 \
security-profile=default signal-range=-85.120 ssid=testssid1
add area-prefix=mtarea1 connect=yes disabled=no interface=wlan1 \
security-profile=default signal-range=-85.120 ssid=testssid2
add connect=yes disabled=no interface=wlan1 \
security-profile=secureprofile signal-range=-75.120 ssid=securessid
add connect=no disabled=no interface=wlan1

I have alternated colors for clarity on each entry. This set of rules says that we can connect to one of 3 SSIDs on wlan1.  We can connect to SSID “testssid1”, “testssid2” or “securessid” (using security profile “secureprofile”).  It sets minimum signal levels for each access point as well.  The second one even specifies an area-prefix (the use for areas is documented as well).  Finally, the last line says, “If we can’t connect to any of the above, then don’t connect to anything else.”  In order to use the connect list, the wireless card should be configured as mode “station” with no SSID specified.  Although I didn’t specify it in any of the above specifications, we could specify MAC address of the AP as well.

Ok, so we have our limited list of SSIDs that we can connect to.  Our next task is to create the scripts that configure the network when we connect to a specific AP.  In our case, we are only going to detect the SSID and not be concerned about the MAC (the combination of MAC and SSID is commonly referred to as “BSSID”).  Here is a code fragment that detects the SSID and configures our IP space for that SSID:

:environment print
:if ( $ssid = “testssid1”) do={
/interface pptp-client disable PPtP_to_Office
:if ([:len [/ip address find  interface=wlan1]]>0) do={
/ip address remove [find interface=wlan1]
}
/ip address add address=10.10.10.10/24 interface=wlan1
/ip route set [find dst-address=0.0.0.0/0] gateway=10.10.10.1
/interface pptp-client enable PPtP_to_Office
:log warning “Set IP info for SSID testssid1”
}

The first line checks the environment and sets up some variables.  The second line looks to see if the current SSID is set to “testssid1” and, if so, runs the commands inside the {}.  If you read carefully, you should be able to figure out what each of those lines do.  One comment, however, is the enable/disable lines for the tunnel.  This is necessary so that we can “force” the tunnel to immediately reconnect.  In the full script, you’d have several sections similar to the above, one for each IP configuration you need.

The only task left is to determine when we switch.  There is an environment variable called “signal-strength” that gets set when you do the “:environment print” line in a script.  Most of my deployments check the value of this variable and switch when the strength of the active connection is below a certain point.  The actual value of that “certain point” is going to depend on your particular circumstance and environment.  The problem with the 802.11a/b/g protocols is that we will stay connected to an AP as long as possible.  It takes some time to associate, so we don’t want to keep switching between APs.  The problem is, however, that because of the sensitivity  of many of these radio cards, we can stay connected WAY beyond a “useful” connection.  That’s the reason we need multiple radio cards in our deployment.  This allows us to switch without waiting for the 802.11 connection time (and possible DHCP).

Either way, I hope you find this article useful in getting your mobile solution under way.  I really have tried to explain this in some detail, but because of the unique requirements of many networks, it is impossible to be “complete” in my description.  If you would like a quote on getting something like this functionality engineered, please don’t hesitate to contact me.  Again, you’ll find my contact information on my website. Thanks for reading and don’t forget, you are free to add your own comments.

This entry was posted on Thursday, September 18th, 2008 at 4:12 pm and is filed under Mikrotik. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.