There’s a million ways to do this on the wiki and the web but none of them fit my particular application.  Let me explain:

1.  The weak point in my network was an AirFiber 24 upstream from the tower I am connected to wirelessly.  This is the link that goes down in heavy rain causing an outage at our office to PROVIDER1.  We have a backup connection through a second provider that is slower but being 5GHz doesn’t drop in the rain, PROVIDER2.

The network is like this:

[MikroTik CCR1036-12G-4S]
—[RBSXT]—[RBOmniTikU-5HnD[—[AF24]—[PROVIDER1]
—[RBSXT]—[PROVIDER2]

2. Simple floating static routes with check gateway doesn’t help because on PROVIDER1 we never drop our 5GHz connection to the tower, it’s the upstream link that fails.

3. I tried recursive routes and it works but the failover was still lacking and seemed sporadic at best.

4. When failover did occur, the VOIP PBX would hold the connection open through the dead provider and some phones in the office wouldn’t work at all, rebooting the phone was the only solution. We tried a ton of solutions and never got it to work consistently.

The solution that works the best is as follows.  I am using a combination of static routes, firewall rules and Netwatch scripts. Here it is:

The Netwatch script watches 4.2.2.4 (a public DNS server). If it goes down:

• It changes the distance on the default router to PROVIDER1 to 20 making it inactive.  Now all traffic defaults through PROVIDER2.
• It emails me that the gateway has changed. Please not you must set up your email server IP, and any authentication in /tools e-mail first.
• It clears any connections to my VOIP gateway, thereby causing them to re-establish, interestingly calls do not drop!
• When pings return, it sets the distance on the default route through PROVIDER2 back to 1 making it the active route and then clears all connections to the VOIP gateway again.

/tool netwatch
add comment=CheckCon down-script="/ip route set [find comment=\"\
    PROVIDER1\"] distance=20\r\
    \n/ip route set [find comment=\"PROVIDER2\"] disabled=no\r\
    \n/tool e-mail send to=\"YourEmailAddress\" body=\
    \"Connection with PROVIDER1 Lost, Switched to PROVIDER2\" \
    subject=\
    \"Lost connection with PROVIDER1\"\r\
    \n/ ip firewall connection remove [find dst-address=\"\
    YourVoipGatewayIP\"]" host=4.2.2.4 interval=5s timeout=2s \
    up-script="/ip route set [find comment=\"PROVIDER1\"] distan\
    ce=1\r\
    \n/ip route set [find comment=\"PROVIDER2\"] disabled=no\r\
    \n/tool e-mail send to=\"YourEmailAddress\" body=\
    \"Connection with PROVIDER1 Regained, Switched back to PROV\
    IDER1\" subject=\"Regained connection with PROVIDER1\"\r\
    \n/ip firewall connection remove [find dst-address=\"\
    YourVOIPGatewayIP\"]"

Next we need to ensure we can only ping our test host through the PROVIDER1 connection.  This is done with a static route through PROVIDER1:

/ip route add 
comment="Force test pings through PROVIDER1" dst-address=4.2.2.4 /
gateway=199.21.228.153

Next we need to comment our default routes.

/ip route
add comment=PROVIDER1 distance=1 gateway=199.21.228.137 scope=\
    11
add comment=PROVIDER2 distance=10 gateway=209.112.225.65

Next we need to ensure that no pings to our test ip go through PROVIDER1 only:

/ip firewall filter add chain=output comment=/
"Drop pings to 4.2.2.4 if they go through PROVIDER2" \
dst-address=4.2.2.4out-interface=ether2 action=drop

As I write this it is pouring rain outside and I have observed it go down 3-4 times and even with people on the phone, calls continue and we haven’t lost the network. I am loving this!

Good question, one I was also asking myself when I set up a large Mikrotik CAPsMAN network. A moving laptop would hang onto a -85 signal when a -70 was available.  It did not make sense.  So, after some research I found some ideas to help you.

When you are walking between access points (assuming they have the same wireless SSID name and same security), you may find that your wireless client, that is your laptop like a mobile phone is still sticking to the distant device and will not roam to the nearest device.

How roaming works:

Roaming is purely a client decision. The wireless client is responsible for deciding it needs to roam, and then detecting, evaluating, and roaming to an alternative AP. WLAN standards bodies (such as IEEE) and industry bodies (such as Wi-Fi Alliance) do not specify when a client should roam, or how the client roams.

So, roaming or not roaming, it is totally decided by your wireless client’s roaming algorithm. Different wireless client vendors’ roaming algorithms are also different and are not generally published.

Resolution:

There is no role played by AP in this client roaming process. So, your best option is to configure your wireless client to achieve fast roaming for you.  Some NIC vendors give some mechanism to control this roaming behavior, specifically Intel.

PC Users

In Intel, it is known as roaming aggressiveness and this setting allows you to define how aggressively your Wi-Fi client roams to improve wireless connection.

Here are the configuration methods on Intel WNIC:

You can go to control panel -> network and internet -> network connection and choose the wireless connection. Right click the wireless connection and choose properties. Click configure and choose Advanced and choose roaming aggressiveness.  Typically there are 5 options. Here are the explanations of these five options:

Lowest: Your wireless client will not roam. Only significant link quality degradation causes it to roam to another access point.

• Medium-Low/Medium-High: Allow Roaming.
• Medium: Balanced setting between not roaming and performance.
• Highest: Your Wi-Fi client continuously tracks the link quality. If any degradation occurs, it tries to find and roam to a better access point.

Mac Users

It is still possible on the Mac, just not as elegant.  Open a terminal window and type the following command all on one line then Enter.  You will need the administrator password of course since this has to run as the root user:

sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport prefs joinMode=Strongest

This should get your device to drop a weak AP when a stronger signal is available. This will work with any AP setup, Ubiquiti, MikroTik, etc.  Happy roaming!

This is a letter from Patrick Leary at Telrad, I thought worth sharing.

We all know LTE has first been created for the needs of giant mobile operators first. That means the LTE enhanced packet core (called the EPC in LTE-speak) includes a host of features fixed operators may NEVER need, like translating diverse 3G backends into a standardized LTE core. Who wants to pay for that? Not me and certainly not you. As well, being mobile centric first, LTE out of the box EXCLUDES certain things fixed operators like and use, such as Layer 2 services.

Being the first and so far ONLY company out there in the LTE space mainly focused on the fixed space, Telrad is the tip of the spear trying to innovate and idealize the solution for WISPs and other local and regional fixed-focused operators. It has been a struggle. EPC are things that can run deep into 6 figures and we had to find a way for the economics to make sense for your models.

Complicating this, because we use an SDR platform, Telrad is able to do something no other vendor on the planet has done: offer the EPC as a hardware-less, software feature EMBEDDED into each base station as an option. That’s super cool, meaning smaller operators won’t need to shell out for a full centralized EPC. But, that also means we’ve made our lives more difficult because options are another SKU to manage.

We now think we’ve got it as refined as possible and here’s the key to what we’ve done:

Dividing up the EPC functionality to allow for operators to purchase ONLY the features you need, and allowing that granularity to be applied to EITHER the embedded or the centralized EPC models.

So what’s been made granular (and priced much smaller per function)? These are things that in the traditional LTE world are often found as individual appliances. Our centralized core can include them all in one appliance for 1/10th or less of what traditional EPCs can cost. Now we’ve even made it MUCH more affordable than even that, by taking the subsets of EPC functionality and providing them as distinct SOFT modules that can be purchased ala carte into either the embedded or centralized Telrad EPCs. Here are examples:

– Don’t want AAA or need Radius? Fine. We now have a feature called iHSS, which allows MAC level authentication.

– Want to use your Radius, but NOT use our implementation? Don’t get iHSS. Instead get the IWK module, which enables internetworking with an external Radius AAA server.

– Planning ONLY to do best effort or apply a single policy across all subscribers? Fine, no need to have the PCRF functionality of an EPC.

– Want to implement distinct and varied service flows and other QoS services? We’ll offer iPCRF as a module.

These are examples. If you used all the functionality, it would still not cost you any more than how things were first initially priced, even if purchased in pieces, so there is no nickel and diming. The difference is, if you need LESS, you’ll be investing less.

Those of you with firm LTE quotes on the table? We’ll need to revisit them, as the numbers will drop. Those with only estimates at this point? That’s worst case and we’ll get you revisions as you get nearer to pulling the trigger.

One last thing….and it is another big one. With LTE comes the entirely new NMS. Better, lighter, simpler, less cost. I’ll be doing another mail on that as soon as I can.

Java Home Directory Fail Issue on Ubuntu – RESOLVED

For those of you who’re building your Ubuntu from scratch or even if you did like me and install UniFi on an AirVision NVR, , you might or might not get this after installing UniFi Controller

*Setting Java Home….fail

If that do happen, this might be because since the new Ubuntu, the name of the Java homedir changed according to the CPU architecture used and UniFi is using a hard-coded variable for the Java path in its startup script for some reason. You should change the homedir by editing the init script. (We won’t get into much detail about what is init)

1. Open the init script
sudo nano /etc/init.d/unifi

2. Scroll down with your arrow key, look for a variable called
JAVA_HOME=/usr/lib/jvm/java-6-openjdk

3. Add your instance architecture type after that string.
For example, I’m using amd64bit in my instance, the string should become
JAVA_HOME=/usr/lib/jvm/java-6-openjdk-amd64
DO NOT touch anything else.

4. After the edit just enter Ctrl-X and it will ask you wheter it should save or discard the change. We of course want to save it. Press Y, and press ENTER to save it with the same file name. The nano editor will close

5. Do this string to restart our UniFi Controller.
sudo service unifi restart

6. You suceed when you see
* Starting Ubiquiti UniFi Controller unifi [ OK ]

This one nearly made me tear my hair out. Option 43 is a vendor specific option that many vendors use to tell their devices the IP address of a server they need to access. Ubiquiti UniFi uses it and so does in this case Ruckus. I tried setting the value using a hex generator to no avail and after an email through a friend from a Ruckus engineer, we now have a tool!

Try THIS link to access the tool. I have not yet confirmed it works with Ubquiti UniFi but will try it next. It has the proper syntax for the raw option and Cisco as well.  I think it likely will. Enjoy!

Obviously there are more detailed instructions on the Ubiquiti site but I just needed a trunk port and a few access ports on my Ubiquiti EdgeSwitch so this is a much for my own documentation as it is for you my valuable customers!

1. Connect the Admin Computer to a switch port, then navigate to 192.168.1.2 in your web browser.
2. Note: Make sure that PoE is disabled on this port prior to connecting your device.
3. Under Switching > VLAN > Status, click Add the vlan to the the EdgeSwitch.  You can also add several vlans at once using a range like this:

4. Assuming I want port 1 to be a trunk port, while still under Switching > VLAN > Port Configuration, select 2 from the dropdown menu for VLAN ID.

5. Then select Ports 0/1 (the trunk port) and apply the following configuration:

6. Then select Port 0/23 (the access port for UVC belonging to  VLAN2) and apply the following configuration:

7. Next, navigate to Switching > VLAN > Port Summary, select All from the Display rows dropdown menu. Then select Port 0/23, click Edit, then apply the following configuration:

8. Finally, click the Save Configuration button at the top-right of the screen to apply the active configuration to the boot configuration, then follow the prompts that appear.

  That’s it!