HP Procurve MSM410 – Our Wireless Winner

(1 votes, average: 5.00 out of 5)

Loading...

I have been writing about our difficulty in trying to find a reliable, manageable and secure wireless networking access point for our company. After failures with Cisco and Bluesocket, I was beginning to think that there were really no enterprise-class devices around anymore.  We checked out Netgear, DLink, Motorola and 3Com, but nothing stood out.  Finally, we decided to check out HP and look ath the devices from their acquisition of Colubris Networks.

Selecting the MSM410

As one of our criteria, we wanted an access point that we could mount on the ceiling.  I would also have liked external antennas, but it was not critical.  The MSM410 had all of the features that we were looking for and a very easy to use web-based management interface.  The device seems to be a small Linux variant using Apache and custom device drivers for the wireless network.  While our environment is fairly small (approximately 18000 sq ft.), we have been using two access points for coverage.  We decided that we would continue with two devices and we would purchase the HP power injectors even thought we already had some Cisco injectors that meet the 802.3af standard.  This was more of a defensive move because a lot of vendors in this area do not like the mix-and-match approach and will sometimes balk when it comes to debugging or replacing parts under warranty.

Installation and Testing

The inital configuration of the units were annoying to say the least.  I connected the injector to a power source and attached the Ethernet cable to the access point along with a console cable (one of the nice features of the box).  I waited a long time and still nothing was visible on the console.  Everything looked fine, but no luck.  So, I started chasing down the manuals and documentation.  To my great surprise, the console port is inactive when shipped from the factory.  It is also disabled if you reset the device to factory standard.  This makes things tough since the network interface does not use DHCP to obtain a network address, but rather uses a static IP address of 192.168.1.1/24.  This means that you have to get an Ethernet cross-over cable; attach it between your PC and the device; configure the NIC on your PC with a static IP address in that same network and then bring up the web interface.  From there, you can activate the console which I highly recommend since it is easy to make a mistake during the configuration which makes the device inaccessible.  In that case, you have to reset to factory, reconnect the PC and start over which is extremely frustrating.

When we looked further into the packaging, we noticed that the device does not come with a ceiling mount kit.  The instructions stated that these must be supplied by the user.  I found some T-bar clips for a pretty good price and ordered a couple pairs.  In the meantime, I placed the units on top of a couple cubicle walls below where I wanted the ceiling mounts.

With a notebook computer running AirMagnet WiFi Analyzer and a Blackberry Bold cell phone, I connected to the wireless network and began testing signal strength and quality throughout the building.  I have found that testing with both devices is necessary as the cell phones do not get as good a signal as notebooks and my users don’t know or care about differences, they just need a reliable and available network.  I also really like the MSM410 display which shows the connected devices along with their signal-to-noise ratio to help troubleshoot and diagnose the environment.  Everything looked very good and I was hopeful that we would have success when users started to arrive on Monday morning.

Well, my hopes were dashed very quickly when everyone started complaining right from the get go.  Connections were intermittent and unusable which did not match any of my testing.  Watching the two devices, we quickly saw that users were getting associated on one device and then immediately disassociated and associated on the other device.  This ping-pong activity was very noticeable on most devices but not all.  We contacted HP technical support and they quickly determined that we were using an old version of firmware and sent us an upgrade.  We upgraded the devices from 5.3.1.0-01-7143 to 5.3.4.8-01-7783-A and things started to settle down very quickly.

During our time with the HP technicians, they asked some very good questions.  First, why did we have two devices given the size of our building?  When we told them it was a Cisco recommendation, they told us we would have to bring down the power on the antennas even more than we had already (40%) and monitor the situation.  Their recommendation, however, was to use 100% power on a single unit that was centrally located and unobstructed by lighting and metals.

 After a few days, we were still not out of the woods as we still had people jumping between units, so we decided to take the advice from H-P and change the installation.  With the arrival of the ceiling T-bar clips, I completed a ceiling mount in the center of the building and set the antenna to maximum.  We tested the entire facility with cell phones and notebook computers and did not find any dead zones or bad areas.  We held our breath as users began to come online.  We had not told anyone of the changes, but the compliments started coming in as users associated and stayed associated as they moved through the building and docked and undocked their notebooks; moving seamlessly between wired and wireless connectivity.

Success?  Not Yet, Unfortunately

While things are going very well right now, we cannot claim victory just yet.  We send all of our SNMP traps and syslog information to our network management system Zenoss.  After a couple days, I noticed a critical warning from the MSM410.  Upon further investigation, I saw that it had gotten a SIGUSR1 signal from some piece of software and a watchdog timer problem caused the unit to reboot.  We contacted HP and they asked us to set the syslog information to “debug” level and see if it happens again.  Well, a few days later it did happen again.  All of the log information was supplied to HP and after about a week they asked us to upgrade the firmware again to version 5.3.5.8-01-7933.  This was applied and we are now getting an error which says, “ar5416GetPendingInterrupts – received PCI FATAL interrupt.”  The data has been supplied to HP and we hope to get this thing working well, very soon.

It has been a very difficult few months trying to get an enterprise wireless solution for my company and we are fairly pleased with this product, despite its problems, and the level of service and support we have received from HP.  I am also hoping that it will serve us well as wireless networks move from 802.11g to 802.11n as this device is capable and ready to support that protocol.

Article by Steve Van Domelen

Steve has written 47 awesome articles.