Tuesday, 21 May 2013

Aerohive BR200-WP 3G/4G Backup Testing


This is just a quick note about some interesting things I found out about the Aerohive BR200-WP today when I was having a look at our demo kit for a possible customer solution. 

The BR200-WP is a great little branch router/switch/AP platform. It boasts a single AP radio (5GHz or 2.4GHz, 3x3:3!!!) and has 5 x 1Gbps switched Ethernet ports (one is the WAN uplink). If you throw-in in the fact that its cloud managed and has all of the usual powerful HiveOS features (VPN, firewall, AVC, airtime fairness...etc,. etc.), you've got a great branch-router platform. (Oh yes, I forgot to mention that it has 2 x POE ports too!)

But in addition to the mass of great features outlined above, the BR200-WP has one more trick up its sleeve: 3G/4G backup. The unit has a USB 2.0 port which can be used to attach a 3G/4G dongle to provide WAN backup in the event that the main WAN link should fail. This was the area I was interested in taking a look at in my testing.

You'll have to excuse my ignorance in the area of 3G/4G backup in this article. There are probably a few things in here which may be very obvious to most folks, but I hadn't really come across them before.

I connected my BR200-WP up to an ADSL connection and gave it a basic configuration (via HMOL). This gave me an SSID to attach to and some basic Internet connectivity via a test wireless client. I configured the interfaces to (hopefully) provide a resilient WAN link.

My first action (like most engineers) was to insert my existing 3G dongle in to the USB port of the BR200WP and see 'what would happen'. Unfortunately, not too much did happen. I got the standard WAN (ADSL) connection up and working, but when I failed it, the 3G backup didn't kick in - back to the drawing board (well, time to read the manual actually).

After checking the datasheet, I realised that not all 3G dongles are created equal. Only certain models of dongle are supported for use with the BR200-WP. Apparently, different dongles use different command sets, which makes universal support tricky. So, I got on to Amazon and bought myself an unliocked Huawei E220 3G dongle. There are a range of 3G and 4G dongles that are supported by the BR200-WP, but I'll leave you to check them out on the datasheet (as the range of supported dongles will no doubt extend over time).

Once I had my supported (E220) dongle, I switched my SIM card across to in to the E220 to try the 3G backup again. (Quick note: I didn't know you could switch SIMs around like this to put them in to a supported card. Prior to being told this, I spent a lonnnnnnng time looking at cell phone web sites trying to get a supported dongle-type to buy a new one - very embarrassing in retrospect

Unfortunately, I still didn't have any success when I failed the main WAN link and had to do a little more digging. Again, my ignorance of 3G backup shone through, and after a little Googling it became apparent that I had to configure the correct dial-up parameters in the BR200-WP for my 3G dongle provider. In my case, as I use Vodafone here in the UK, my parameters are:
  • APN: internet
  • Dialup number: ATD*99#
  • User ID: web
  • Password: web
These parameters will vary from provider to provider. If they aren't 100% correct, things won't work. I found a great site with the correct  strings for many 3G/4G providers and their various data plans here in the UK, which you may find useful if you are going through a similar exercise:

http://www.mobilez.org/support/apns/uk/

Now that I had the correct type of dongle and the correct dial strings etc., I was ready to roll! I'm pleased to report that things actually worked pretty smoothly once I had this all figured out. I fired up my test wireless client and connected to the Internet via my usual DSL connection. Then, I failed the DSL connection and after a few seconds, the 3G link kicked-in and I carried on working.

I took a screen shot of the AP configuration so that you can see how I had it all configured to provide the 3G WAN backup. I've highlighted the important areas with red boxes:



Just to run through the 5 highlighted areas:
  • WLAN interface: not really related to 3G backup at all (sorry), but still very interesting. I found out that the way you switch between 2.4GHz and 5GHz is by changing the radio profile - that isn't immediately obvious (I never even realised you could switch to 5GHz until I read the data sheet!)
  • Eth0 - Set this interface to a priority of primary (this is the default) - this will ensure that the WAN link connected via this port is used for all traffic during normal (non-failure) operation
  • USB - Set the priority to Backup1 (this is the default) - this will ensure that this interface is used when the main WAN link (Eth0) fails
  • Wireless USB Modem Settings - Connect As Needed: this will ensure that the 3G link only comes up when the WAN links fails, rather than being permanently dialled up.
  • USB Modem - ensure that the various 3G modem strings are entered as per your 3G provider requirements
One area that I struggled with was getting the 3G dialler parameters (APN, User ID etc.) correct. This was quite difficult and time-consuming to resolve by the usual method of making a change via HMOL and then pushing the change out. So, I improvised slightly and connected my console cable to the BR200-WP. I made a few small config changes to the BR200-WP configuration via the CLI to test the effect of various changes in real-time. I used the following CLI commands:

usbmodem modem-id huawei_e220 apn internet
usbmodem modem-id huawei_e220 dialup-number ATD*99#
usbmodem modem-id huawei_e220 dialup-password web
usbmodem modem-id huawei_e220 dialup-username web

Once I'd got them right via the CLI, I configured them on HMOL and pushed out the final, correct config. Making CLI changes isn't really generally recommended, but in this case, it saved me a lot of time!

One other area I became very familiar with when trying to get this going is the debugging available from the CLI of the AP. If you're trying to set this up and are having difficulties, it's well worth enabling some debugging to see what's going on. I used the following command (which gives you more information than you really need):

debug console all

This gave a log on my terminal screen of everything going on, but allowed me to see the BR200-WP attempting to dial up the 3G connection when the WAN link failed. Here is a partial dump of the log showing a successful fail-over to the 3G connection, which may be useful (I've changed a few IP addresses etc. for security reasons):

2013-05-21 16:49:42 info    registering with PM for pid=2576 name=[mod_name_pppd_mod_id_64] cmdline=[/sbin/pppd noaccomp nopcomp novj nobsdcomp noipdefault noauth defaultroute replacedefaultroute usepeerdns lock crtscts persist ah-pppousb linkname usb_modem0 ipparam 115200 /dev/ttyUSB0 user web password web connect  USE_DIALUP_NUM=ATD*99# USE_APN=internet /sbin/chat -t5 -v -E -f /etc/chatscripts/3g.chat]
2013-05-21 16:49:42 notice  pppd[2576]: pppd 2.4.3 started by root, uid 0
2013-05-21 16:49:43 info    chat[2583]: abort on (BUSY)
2013-05-21 16:49:43 info    chat[2583]: abort on (NO CARRIER)
2013-05-21 16:49:43 info    chat[2583]: abort on (ERROR)
2013-05-21 16:49:43 info    chat[2583]: report (CONNECT)
2013-05-21 16:49:43 info    chat[2583]: timeout set to 5 seconds
2013-05-21 16:49:43 info    chat[2583]: send (AT&F^M)
2013-05-21 16:49:43 info    chat[2583]: expect (OK)
2013-05-21 16:49:43 info    chat[2583]: AT&F^M^M
2013-05-21 16:49:43 info    chat[2583]: OK
2013-05-21 16:49:43 info    chat[2583]: -- got it
2013-05-21 16:49:43 info    chat[2583]: send (ATE1^M)
2013-05-21 16:49:43 info    chat[2583]: expect (OK)
2013-05-21 16:49:43 info    chat[2583]: ^M
2013-05-21 16:49:43 info    chat[2583]: ATE1^M^M
2013-05-21 16:49:43 info    chat[2583]: OK
2013-05-21 16:49:43 info    chat[2583]: -- got it
2013-05-21 16:49:43 info    chat[2583]: send (AT+CGDCONT=1,"IP","internet"^M)
2013-05-21 16:49:43 info    chat[2583]: timeout set to 10 seconds
2013-05-21 16:49:43 info    chat[2583]: expect (OK)
2013-05-21 16:49:43 info    chat[2583]: ^M
2013-05-21 16:49:43 info    chat[2583]: AT+CGDCONT=1,"IP","internet"^M^M
2013-05-21 16:49:43 info    chat[2583]: OK
2013-05-21 16:49:43 info    chat[2583]: -- got it
2013-05-21 16:49:43 info    chat[2583]: send (ATD*99#^M)
2013-05-21 16:49:43 info    chat[2583]: expect (CONNECT)
2013-05-21 16:49:43 info    chat[2583]: ^M
2013-05-21 16:49:43 info    chat[2583]: ATD*99#^M^M
2013-05-21 16:49:43 info    chat[2583]: CONNECT
2013-05-21 16:49:43 info    chat[2583]: -- got it
2013-05-21 16:49:43 info    chat[2583]: send ( ^M)
2013-05-21 16:49:43 info    pppd[2576]: Serial connection established.
2013-05-21 16:49:43 warn    mDNSResponder: interface change, mdnsd refresh interface list and service!!!
2013-05-21 16:49:43 info    kernel: [systop]: initializing AH dev for ifp ppp0!
2013-05-21 16:49:43 info    kernel: [mpi]: drop unsupported event 0x5 from ppp0
2013-05-21 16:49:43 info    pppd[2576]: Using interface ppp0
2013-05-21 16:49:43 notice  pppd[2576]: Connect: ppp0 <--> /dev/ttyUSB0
2013-05-21 16:49:44 info    pppd[2576]: CHAP authentication succeeded
2013-05-21 16:49:44 notice  pppd[2576]: CHAP authentication succeeded

2013-05-21 16:49:44 warn    pppd[2576]: kernel does not support PPP filtering
2013-05-21 16:49:47 warn    pppd[2576]: Could not determine remote IP address: defaulting to 10.x.x.x
2013-05-21 16:49:47 info    amrp2: receive kevent KEVT_IF_CHG type IF_UP from ppp0 index 20
2013-05-21 16:49:47 warn    ah_dcd: Interface ppp0 is up.
2013-05-21 16:49:47 info    ah_dcd: access interface ppp0 is up now
2013-05-21 16:49:47 info    capwap: CAPWAP receive kevent KEVT_IF_CHG, eventid = 16, size = 36
2013-05-21 16:49:47 info    kernel: [mpi]: drop unsupported event 0xd from ppp0
2013-05-21 16:49:47 info    kernel: [mpi]: ppp0 notify kevent KEVT_IF_CHG, type IF_UP(1)
2013-05-21 16:49:47 info    capwap: receive event vpn report responce capwap: eventid = 103: length = 30
2013-05-21 16:49:47 info    capwap: CAPWAP: receive vpn report responce capwap event!, length:30
2013-05-21 16:49:47 info    kernel: [mpi]: socket is closed, pid(-4135), protocol(0)
2013-05-21 16:49:47 info    ah_vpn: <IKE>  update share memory default gateway parameters 0.0.0.0, ifname
2013-05-21 16:49:47 info    kernel: [mpi]: socket is closed, pid(-4136), protocol(0)
2013-05-21 16:49:47 info    ah_vpn: <IKE>  update share memory default gateway parameters 0.0.0.0, ifname
2013-05-21 16:49:47 debug   ah_brd: WANFO: Added event BACKUP_WAN_CONNECTED
2013-05-21 16:49:47 debug   ah_brd: WANFO WANFO SM Engine: @ state:NOWAN + event:BACKUP_WAN_CONNECTED [0x3]

So, there you have it, a quick look at setting up the 3G backup on the BR200-WP. 

It's worth bearing in the mind the limitations of 3G connectivity as a backup medium. You're realistically limited to downstream connectivity speeds of around 2 to 4 Mbps, depending on your signal strength, with upload speeds being just a few hundred kbps. It's not going to provide you lightning connectivity, but it will keep you going. It will be fascinating to see how a 4G connection performs, potentially providing several tens of mbps in each direction (providing you can get the coverage!). The possibilities for the BR200-WP certainly increase significantly if a good cellular WAN speed can be achieved.

References:

Sunday, 19 May 2013

Top 10 Things a WiFi Installer Does Not Want To Hear...


Here are the top 10 things (IMO) you don't want to hear from a customer when you arrive on site to install a new WiFi network (I compiled this rather quickly in a flippant moment - please don't take it too seriously...):
  1. Our networking guy, who was going to be helping you today, isn't available, I'm afraid he's... (choose from the following):
    • On a late shift
    • Off sick
    • On leave
    • Over-slept
    • Double-booked
    • Left the company
    • Had a baby
    • Buying a radiation suit
  2. Oh, you wanted POE ports for those APs?
  3. Our goods-in department has definitely received the kit, they're just not sure which part of the hospital it went to...
  4. Oh, we thought you were bringing the kit with you. No, we haven't received anything.
  5. You know that 500-person call-center where you said we might have issue with personal hot-spots? The good news is, we've introduced a policy of 'no personal hot-spots' in that area! As a sweetener, we gave all of the operatives a bluetooth headset, mouse and keyboard each. We also threw in 5 new microwave ovens for their rest area, together with 10 new security cameras to monitor all that new gear.
  6. We've changed out minds. We'd really like to be able to run video and voice across the network as well. Can you squeeze that in whilst you're here?
  7. Our CEO has a new iPad and he'd really like to be able to use it on the wireless network. I know it wasn't in scope, but it's really important...
  8. Well, the salesman said it would support <insert unsupported feature here>.
  9. We've decided we would like a bit of coverage outside of the building after all (the CEO is a smoker). Can you move a couple of APs a bit closer to the windows near the smokers area?
  10. The cabling guy has assured us that you'll have no issues with 120 metre cable runs...
I'm sure there are plenty of others... :)

Nigel.

Tuesday, 7 May 2013

5GHz - 3 Missing Channels in Europe

Last year, I put up a posting which highlighted the fact that here in the UK (and I suspect all of Europe) we often have 3 channels missing from our allocation of unlicensed channels in the 5GHz band.  Looking at many manufacturer data sheets, channels 120, 124 and 128 are often shown as not being supported. This is despite the fact that they are allocated for use by local regulatory bodies (OFCOM here in the UK).

I recently posted a question about this on a partner forum of a major WiFi vendor that I deal with and finally got a definitive answer on this. In this post, I'll share my findings.

The reason that these particular channels (120 - 128) receive special treatment is that they occupy frequencies that are used by weather radar systems. WiFi systems have to be very careful not to interfere with those systems during their normal operation. Therefore, WiFi equipment has some additional checks and tests imposed on it to make sure that it does not inadvertently cause any interference.

In the ETSI region (Europe), the standard EN 301 893 dictates that any channels operating in the frequency range 5.6GHz to 5.65GHz must wait an additional period of time before using a channel. For most DFS-affected channels, a WiFi device must wait for 60 seconds to verify that no radar is present before commencing operation. However, on the channels in the 5.6GHz to 5.65GHz range, the device (i.e. Access Point) must wait 10 minutes! The table below (taken from Annex D of the standard) details this requirement:


Due to this 10 minute wait period, it seems that many manufacturers have chosen to withdraw support for the channels affected, which are 120, 124 and 128. This makes perfect sense now - who would want an AP to be allocated to a channel and then wait for 10 minutes before it can use it..?

I'm pleased to have finally got to the bottom of this particular grey area, but it seems like bad news for WiFi usage in Europe generally. With the anticipated sharp uptake in 5GHz usage around the globe, as 802.11ac starts to roll out, the loss of 3 channels is quite a chunk of spectrum to lose.

In the UK we have 19 unlicensed channels to use on 5GHz for WiFi. Losing 3 of those channels is a 15% loss in spectrum. This is at a time when we really need to be increasing spectrum availability to cope with the additional channel bonding opportunities that  802.11ac provides to increase WiFi speeds.

Hmmm....let's hope some additional spectrum turns up in the near future.

References:
Update: I've now created a white paper which details 5GHz usage for WiFi in the UK. Find it here