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.

The purpose of this post is to outline how to upgrade a Symbol 5×00 Wireless LAN switch. In the example provided we will upgrade a switch running v1.4.3.0-R12 to v2.1.1. This upgrade is a major upgrade in that it literally replaces the core operating system with Linux. The upgrade is done in two steps. The first step you upgrade to v2.1 and in the second step you upgrade to v2.1.1.

You’ll be using the CLI interface to perform the upgrade; there will be no need for the web Java GUI until after the upgrade is complete.

It’s advised to start out by backing up the switch configuration and then uploading that configuration to the TFTP server on the network. You’ll first need to delete the existing configuration file. (If the switch is a standby switch there is no need to backup the configuration file).

Now you can go ahead and download the new system image and accompanying files via FTP. I’ve already placed the system image on the FTP server. The following files will need to be downloaded from the FTP server (10.101.20.1); WS5000_v2.1.0.0-029R.sys.kdi, dominfo, PreUpgradeScript, WS5k_domfix.cfg. You can confirm that the file gets copied down by listing the directory contents using “dir”.

The next step is to execute the PreUpgradeScript and check if there is adequate space for the upgrade. You’ll need to enter “service mode” to execute the following commands. You can enter “service mode” by entering the command “service”. The password may either be “password” or the switch admin password.

If you receive the “OK” you can go ahead with the upgrade. It may be necessary (with Wireless LAN Switch 5000s) to run the “PreUpgradeScript freemem” prior to downloading the WS5000_v2.1.0.sys.kdi image. The 5000 switches only have 128Mb of flash space available.

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.

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;

We have quite a few Nortel Ethernet Routing Switch 5500s deployed throughout our organization. There’s a great new benefit in using the new hardware to help us test the cable plant remotely.

Here’s the text from the Nortel manual;

Testing cables with the Time Domain Reflectometer With Release 5.0 software, the Nortel Ethernet Routing Switch 5500 Series is equipped with a Time Domain Reflectometer (TDR). The TDR provides a diagnostic capability to test connected cables for defects (such as short pin and pin open). You can obtain TDR test results from the CLI or the JDM. The cable diagnostic tests only apply to Ethernet copper ports; fiber ports cannot be tested. You can initiate a test on multiple ports at the same time. When you test a cable with the TDR, if the cable has a 10/100 MB/s link, the link is broken during the test and restored only when the test is complete. Use of the TDR does not affect 1 GB/s links. Note: The accuracy margin of cable length diagnosis is between three to five meters. Nortel suggests the shortest cable for length information be five meters long.

Unfortunately this feature is ONLY available on the 5510, 5520 and 5530 switches. Using Device Manager you’ll find the option on the port settings (a tab to the right labeled “TDR”). You can also use the following CLI commands;

The following document is provided as a basic guide on how to configure the Motorola WS5100 Wireless LAN Switch with release 3.x software. You should use the initial username of “cli” at the login prompt. At the username/password prompts you should use “admin” and “superuser” respectively.

You should connect to the console port a serial cable (null) with 19200,8,N,1.

The example below will configure Ethernet 2 as a trunk port with the management interface in VLAN 200 (10.107.255.199/24) and the default gateway as 10.107.255.1. The order of the commands is very important when you start to trunk the interface.