Michael McNamara

I thought I would take some time to shamelessly plug a product that I recently purchased for my organization.

We are currently working through an issue that is affecting our Nortel 2211 Wireless telephones on our Motorola RFS7000 Wireless LAN Switch. In short it appears that the phone is resetting itself for unknown reasons. The problem is very intermittent and sporadic, hence it's very difficult to recreate. The vendors involved in the problem, Motorola, Nortel and Polycom (Spectralink) are all asking for wireless traces of the problem. In order to capture the problem we need four laptops; three laptops tracing on each of the wireless channels in the 802.11b 2.4Ghz spectrum and one laptop tracing on the LAN side of the RFS7000. Needless to say that is a lot of hardware to setup. And the wireless laptops really need to physically move with the wireless telephone as it moves through the building (wireless network).

Then I heard that CACE Technologies had a hardware solution that worked with WireShark and allowed for simultaneous packet capture on all three 802.11b channels. Using three AirPcapEx USB adapters I could use a single laptop to capture all three 802.11b channels saving me a lot of hardware and a lot of time trying to assemble/merge the different packet traces.

I've been using the solution for the past week and it seem to work well. It was perfect timing because WireShark v1.0 was released earlier this week. Even though it's a single laptop it can still be a bit of a logistical pain with the three USB adapters and the three antennas. I got some really interesting stares walking around the building with this octopus looking thing on top of the laptop keyboard.

Cheers!

A few years ago I had a request to design a public WiFi hotspot portal for the patients and visitors within our five major facilities. I did a fair amount of research and found a number of interesting commercial and open-source solutions. Unfortunately none of them really filled our requirements or caught my fancy. So I embarked on building/coding our own solution using a wide array of open-source software that was already available. Since I was most familiar with Perl at the time I chose to code the solution using Perl and Javascript (browser side) using Linux as the operating system of choice.

I needed to provide a public WiFi hotspot across our existing corporate wireless infrastructure at our five major sites. It obviously needed to be secure from our internal network, it needed to be 100% automated (there were no resources available to support this offering) and it needed to work (there's a surprise requirement). We also needed to keep internal (corporate) laptops and wireless devices from connecting to the unencrypted network and circumventing current Internet access policies.

Because of security concerns I decided to only allow HTTP (TCP 80) and HTTPS (TCP 443) traffic from the public wireless network. I also tabled any ideas of content/URL filtering from the original design. Instead we would reliable on Blue Coat ProxySG/ProxyAV appliances and Websense to perform content filtering and AV scanning of the traffic in a later upgrade.

How did we do it?
We carved out an ESSID ("public") from our Motorola Wireless LAN infrastructure at each facility. We setup the wireless network without any encryption or security so as to minimize any end-user difficulties in connecting to the wireless network. We took CentOS and built a WiFi portal server/gateway/firewall/router using an HP Proliant DL360. We essentially turned our Linux server into a cheap and very efficient firewall/gateway for the WiFi Hotspot. We connected one NIC of the Linux server to the wireless WLAN and the other to our internal network. This allowed use to use the Linux server to provide IP addresses to the wireless devices through DHCP. It also allowed use to have the Linux server provide DNS for name resolution. And most importantly it allowed use to use IPtables to provide firewalling between the wireless network and our internal network. This solution also allowed us to implement bandwidth shaping/throttling to prevent the public WiFi Hotspot wireless users from utilizing too much of our Internet link (DS-3 ~ 45Mbps).

Once a device associates with the wireless network the Linux portal server will issue the device a DHCP address from the 192.168.16.0/20 network. When the user opens their web browser they will be redirected to the Linux portal web server and the registration page as it appears below;

Once the user clicks on the "I AGREE" button the Linux server will kick off the "register.pl" script to check the IP/MAC address and decide if they should be granted access. If they are granted access they will be redirected to our Internet homepage after which they'll be free to surf to any URL. If the user is denied access they will be directed to an error page.

It is also possible that the user may attempt to register multiple times due to their web browser caching the portal page contents as the contents of a legitimate Internet website. Example: A user opens their web browser to www.cnn.com and is greeted with the portal page. User registers that is then re-directed to www.acme.org. The user then types www.cnn.com back into the browser address bar, but instead of getting the legit content for the CNN website the user is greeted again by the portal page. The user not knowing any better clicks the “I AGREE” button for the second time in as many minutes. Previously this problem would have gone on and on over and over, now the system will detect that the user is already registered and will through an error alerting the user to “refresh” their web browser. In order to refresh the browser the user should just type in the URL of the website they are attempting to visit and click “Go” (or hit “enter”). If they are greeted with the portal page they should click the “refresh” button from the browser button bar. That will instruct the web browser to ignore any cached content and attempt to retrieve all the data direct from the source website.

Every night at midnight the firewall rules will be reset to the defaults. Requiring any that wishes to access the WiFi Hotspot to agree to the AUP again. This is done to prevent folks from continually sitting/camping on the WiFi Hotspot.

Initially I thought we might be able to use a VPN or GRE tunnel to connect the five public WLANs to a single Linux server. Unfortunately I was a little ahead of the times and VPN/GRE tunnels were just starting to be supported in the various wireless switches (Motorola in this case). So I decided to take an easier approach and installed five HP Prolaint DL360 servers, one for each site.

I'm very happy to report that the solution works very well and virtually supports itself.

The only issue that we've seen is the need to continually update the blacklist file to keep corporate wireless devices from connecting to the public network. Thankfully I've written a small Bash Shell script to help with that process.

I hope to write a more detailed account of how to set this up on my website sometime in the future. If your interested in hearing more or have questions please drop me a line.

Cheers!

Motorola's WS5000/WS5100 Wireless LAN Switches (v1.x,2.x software) allow you to provision a standby backup switch that would take over for the primary if some problem affected the primary Wireless LAN switch. This is a an active/passive solution, the primary will be active while the standby listens for heartbeats from the primary in a standby mode. If the standby stops receiving the heartbeats from the primary switch it will switch to an active mode and adopt the Access Ports and start providing service to the mobile units.

First we’ll telnet into the primary switch (sw16-wireless.reh.acme.org) and backup its configuration copying it up to the TFTP server. Second we’ll telnet into the standby switch (sw16r-wireless.reh.acme.org) and then download the primary switch configuration via TFTP and then restore the configuration into the system.

Let’s start with the primary switch;

[root@linux root]# telnet sw16-wireless.reh.acme.org
Trying 10.115.255.12...
Connected to sw16-wireless.reh.acme.org (10.115.255.12).
Escape character is '^]'.

When prompted for the “user name” use “cli".

user name:cli

Symbol Wireless Switch WS 5000 Series.
Please enter your username and password to access the Command Line Interface.

When prompted for the “userid” use defaults of “admin” and "symbol" for the password.

userid: admin
password: *********

Retrieving user and system information...

Setting user permissions flags..
Checking KDC access permissions...

Welcome...

Creating the Event list...
System information...

System Name : sw16-wireless.reh.acme.org
Description : WS5000 Wireless Network
Switch Location : Data Center
Software Ver. : 1.4.0.0-026R
Licensed to : Symbol Technologies
Copyright : Copyright (c) 2000-2005. All rights reserved.
Serial Number : 00A0F8658FC0
Number of Licenses : 30
Max Access Ports : 30
Max Mobile Clients : 4096
Active Switch Policy : Wireless Switch Policy
Emergency Switch Policy : Not defined
Switch Uptime : 00d:01h:01m
# of Unassigned Access Ports : 0

sw16-wireless.reh.acme.org>

Let’s start out by backing up the switch configuration;

sw16-wireless.reh.acme.org> save configuration sw16-wireless-reh.cfg
Saving running configuration in: sw16-wireless-reh.cfg
Saving wireless network management configuration ...

Let’s make sure the configuration file can be found on the file system;

sw16-wireless.reh.acme.org> dir
Date & Time Bytes File Name

Jan 25 18:11 15155 WS5000Defaults_v1.4.0.0-026R.cfg
Jan 25 18:35 18819400 WS5000_v1.4.0.0-026R.sys.img
Jan 25 17:05 6517 cmd_template.sym
Mar 28 12:24 16878 sw16-wireless-reh.cfg

Let’s upload that configuration to the TFTP server (10.101.20.1) on the network;

sw16-wireless-reh.acme.org> copy sw16-wireless-reh.cfg tftp://10.101.20.1/sw16-wireless-reh.cfg
Copying 'sw16-wireless-reh.cfg' from Switch to tftp://10.101.20.1...
File: sw16-wireless-reh.cfg copied successfully to 10.101.20.1

sw16-wireless.reh.acme.org>

The configuration file is now successfully on the TFTP server. We can now turn our attention to the standby switch. Let’s start by telneting into that switch (sw16r-wireless.reh.acme.org);

[root@linux root]# telnet sw16r-wireless.reh.acme.org
Trying 10.115.255.13...
Connected to sw16r-wireless.reh.acme.org (10.115.255.13).
Escape character is '^]'.

user name:cli

Symbol Wireless Switch WS 5000 Series.
Please enter your username and password to access the Command Line Interface.

userid: admin
password: *********

Retrieving user and system information...

Setting user permissions flags..
Checking KDC access permissions...

Welcome...

Creating the Event list...
System information...

System Name : sw16r-wireless
Description : WS5000 Wireless Network
Switch Location : Data Center
Software Ver. : 1.4.0.0-026R
Licensed to : Symbol Technologies
Copyright : Copyright (c) 2000-2005. All rights reserved.
Serial Number : 00A0F8658FC8
Number of Licenses : 0
Max Access Ports : 0
Max Mobile Clients : 4096
Active Switch Policy : Wireless Switch Policy
Emergency Switch Policy : Not defined
Switch Uptime : 00d:00h:11m
# of Unassigned Access Ports : 0

sw16r-wireless>

After we’re logged into the standby switch lets copy the primary switch configuration by TFTP;

sw16r-wireless.reh.acme.org> copy tftp system
Enter the file name to be copied from TFTP server : sw16-wireless-reh.cfg

Copying 'sw16-wireless-reh.cfg' from tftp://10.101.20.1 to Switch...
File: sw16-wireless-reh.cfg copied successfully from 10.101.20.1
Verifying configuration file...
Valid configuration. Completing verification.

Let’s just confirm that the configuration file appears on the file system;

sw16r-wireless.reh.acme.org> dir
Date & Time Bytes File Name

Jan 25 15:11 15155 WS5000Defaults_v1.4.0.0-026R.cfg
Jan 25 15:35 18819400 WS5000_v1.4.0.0-026R.sys.img
Jan 25 14:05 6517 cmd_template.sym
Mar 28 01:35 16878 sw16-wireless-reh.cfg

Let’s go ahead and restore the standby switch configuration from the primary switch configuration file;

sw15r-wireless.reh.acme.org> restore standby sw15-wireless-reh.cfg

This command will reset the system and boot up with the new configuration.

Do you want to continue (yes/no) : yes

Restoring Stand By configuration from sw15-wireless-reh.cfg

Do you want to change Interface 1 static IP address(10.115.254.11)?
Creating the Event list...
Enter (yes/no) : no
INFO: Static IP address not changed.

Do you want to change Interface 2 static IP address(10.115.255.11)?
Creating the Event list...
Enter (yes/no) : no
INFO: Static IP address not changed.

Shutting down database main thread...done.
Rebooting the switch...
Connection closed by foreign host.

The standby switch should reboot at this point and should retain its original IP addressing. There is one last step required to make the standby switch a “hot” standby. The standby feature must be configured and enabled on both the primary and standby switches. The order in which you enable the standby feature is critical, so start on the standby switch by issuing the following commands;

sw16r-wireless.reh.acme.org> configure
sw16r-wireless.reh.acme.org.(Cfg)> standby
sw16r-wireless.(Cfg).StandBy> set autorevert enable

Configuring Standby....
Status : Success.

Standby Management:

StandBy mode : Standby
Standby Status : Disable
State : Startup
Failover Reason :
Standby Connectivity status : Not Connected
Standby AutoRevert Mode : Enable
Standby AutoRevert Delay : 15 Minutes

Interface (Ethernet) 1
----------------------
StandBy Heart-Beat MAC : Auto Discovery Enabled
Heart-Beat status : Enable
Received Heart-Beat : No

Interface (Ethernet) 2
----------------------
StandBy Heart-Beat MAC : Auto Discovery Enabled
Heart-Beat status : Disable
Received Heart-Beat : No

sw16r-wireless.(Cfg).StandBy> enable

Enabling...
Status : Success.

Standby Management:

StandBy mode : Standby
Standby Status : Enable
State : Startup
Failover Reason :
Standby Connectivity status : Not Connected
Standby AutoRevert Mode : Enable
Standby AutoRevert Delay : 15 Minutes

Interface (Ethernet) 1
----------------------
StandBy Heart-Beat MAC : Auto Discovery Enabled
Heart-Beat status : Enable
Received Heart-Beat : No

Interface (Ethernet) 2
----------------------
StandBy Heart-Beat MAC : Auto Discovery Enabled
Heart-Beat status : Disable
Received Heart-Beat : No

With the standby configured properly go ahead and issue the following commands on the primary;

sw16-wireless.reh.acme.org> configure
sw16-wireless.reh.acme.org.(Cfg)> standby
sw16-wireless.reh.acme.org.(Cfg).StandBy> set autorevert enable

Configuring Standby....
Status : Success.

Standby Management:

StandBy mode : Primary
Standby Status : Disable
State : Startup
Failover Reason :
Standby Connectivity status : Not Connected
Standby AutoRevert Mode : Enable
Standby AutoRevert Delay : 15 Minutes

Interface (Ethernet) 1
----------------------
StandBy Heart-Beat MAC : Auto Discovery Enabled
Heart-Beat status : Enable
Received Heart-Beat : No

Interface (Ethernet) 2
----------------------
StandBy Heart-Beat MAC : Auto Discovery Enabled
Heart-Beat status : Disable
Received Heart-Beat : No

sw16-wireless.reh.acme.org.(Cfg).StandBy> enable

Enabling...
Status : Success.

Standby Management:

StandBy mode : Primary
Standby Status : Enable
State : Find standby
Failover Reason :
Standby Connectivity status : Not Connected
Standby AutoRevert Mode : Enable
Standby AutoRevert Delay : 15 Minutes

Interface (Ethernet) 1
----------------------
StandBy Heart-Beat MAC : Auto Discovery Enabled
Heart-Beat status : Enable
Received Heart-Beat : No

Interface (Ethernet) 2
----------------------
StandBy Heart-Beat MAC : Auto Discovery Enabled
Heart-Beat status : Disable
Received Heart-Beat : No

Then confirm that the primary has connected with the standby switch by issuing the following command and confirm that the “Standby Status” is “Enable” and that the “State” is “Connected”;

sw16-wireless.reh.acme.org.(Cfg).StandBy> show

Standby Management:

StandBy mode : Primary
Standby Status : Enable
State : Connected
Failover Reason :
Standby Connectivity status : Connected
Standby AutoRevert Mode : Enable
Standby AutoRevert Delay : 15 Minutes

Interface (Ethernet) 1
----------------------
StandBy Heart-Beat MAC : Auto Discovery Enabled
Heart-Beat status : Enable
Received Heart-Beat : Yes

Interface (Ethernet) 2
----------------------
StandBy Heart-Beat MAC : Auto Discovery Enabled
Heart-Beat status : Disable
Received Heart-Beat : No

sw16-wireless.reh.acme.org.(Cfg).StandBy>

That’s all folks.

I've worked primarily with Motorola (formerly Symbol) since the early 802.11b FHSS (Frequency Hopping Spread Spectrum) days. When 802.11b DSSS (Direct Sequence Spread Spectrum) came to the forefront I worked with the Symbol 4121/4131 Access Points (some of which were OEM'd for Nortel Networks at the time). The Access Points were very versatile and had a very extensive SNMP mib. I was able to write several Perl scripts to help manage the large number of Access Points that we had deployed at numerous locations and facilities.

Symbol was the industry's first company to design a switched-wireless networking architecture, pioneering the thin or lightweight Access Points (or Access Ports as they would come to be known as). The Symbol WS5000 Wireless LAN Switch was driven by LynuxWorks operating system. Later software releases of the WS5000 and later the WS5100 would use an internally developed version of Linux (I know their using Linux I'm just not 100% sure who's developing it for them). The primary wireless design constraint with the Motorola WS5100 is the maximum 48 port Access Port adoption limit. The hardware can only support 48 simultaneous Access Ports in a single switch. At one hospital we have over 200 Access Ports and over 18 WS5100s deployed, 9 primary WS5100s and 9 standby WS5100s .

Motorola has just recently released the RFS7000 Wireless LAN Switch that promises to support up to 256 Access Ports. I won't go into all the features, I'll let you find that out from Motorola's web site. Motorola's recent Wi-NG software release (v3.x) also offers clustering options allowing around 2,500 Access Ports within a single cluster. In previous releases you needed to have a primary and standby WS51000 for every switch, with clustering you can now have N+1 redundancy within the cluster. The new software also sports a very Cisco like command line interface which is great step up from the previous CLI interface in their v2.x software release. Network administrators will also be happy to know that the same version of software will now run on all "Motorola Wireless LAN Infrastructure", including the WS2000, WS5100, RFS7000 and AP5131. I've worked with all three types of thin Access Ports currently available from Motorola; the AP100 (802.11b), the Ap200 (802.11a/b), and the latest AP300 (802.11a/b/g). We've deployed these Access Ports using Nortel ES460, ERS5520 switches providing Power over Ethernet (PoE).

The web based console on the early (v2.x software) releases was a Java based application that was horrible to work with from a configuration and troubleshooting perspective. It was slow and would continually crash and lockup. In order to alleviate this problem I wrote a web based application so our network engineers and help desk could monitor the wireless network without having to launch the Java application. I wrote the application in Perl at the time because that was the language I was most familiar with and the most comfortable. The application uses SNMP to query the wireless LAN switch and then outputs the data to the user.

You can find the source code along with some additional details on my website under the Perl section. The application will only work against v2.x software releases. Motorola completely re-designed their software in their v3.x software release along with the associated SNMP mibs.

I just recently started looking a Meru Networks as an alternative solution to Motorola.