Meraki - Dallas freenet

Entrepenuership in action. If you want to see how another mesh deployment is going, cruise on over to http://www.dfwfreenet.org/ and see how they are doing. they have a great wiki and a node map up and running. So far they only appear to have 5 nodes up and running but I could see this going big. Support them by laying out a measeley $49 bucks for your own node and go to town!

Meraki Node - Management Details

The Meraki mesh node I got has been up for a week now and here are my thoughts. Well, first of all, It is pretty neat. 'nuff said. I had some questions that I posed to Ben Chambers of Meraki and here are the answers.

The first thing I wanted to know was why it beacons every 500ms instead of 100ms. Twice per second did not seem very much and considerably off the norm. Ben stated that, "As far as the beacon interval goes, the reason is basically that if you have a fairly high number of repeaters (say, 20) within range of each other, 10 beacons per second per node gets pretty excessive." This makes total sense to me.

The next question was whether there was a way to configure the node or at least monitor it. I was told that because it was a free node belonging to the Meraki "Free the Net" project I would not be able to configure it but I would be able to monitor it in a variety of ways:

1. I can see if it is up by associating with it and browsing to http://my.meraki.net/ where I would see a splash page. Click on each image to see a larger version of the image.
2. I can Select the "Advanced" link in the upper left and get a page that lets me run a throughput test to the internet.

3. I can select another link on the advanced page that allows me to set a static IP and some other functions.

4. I can also get to a page that is just for my repeater at http://sf.meraki.net/myrepeater/00:18:0a:01:10:b3 which looks like this:

5. I can also get more data from a more public view of the Meraki network from this URL http://sf.meraki.net/overview which shows me connected to another mesh node way over in Potrero Hill, at least a mile away.


6. I was also pointed to a site where there is XML data for Google earth. http://sf.meraki.net/earth . You must save the source as a KMZ file on you hard drive and open in Google Earth.

After which, it now looks like this in Google Earth. Notice the mesh links (I made them yellow, the better to see them with.)

Which now allows me to go down to sea level and see the line of site to the other link

Pretty impressive. My next step would be to get some Meraki Minis and connect them to the mesh and see how they work out. More fun for next time :-) Talk to you then.

My Own Mesh Node - Meraki comes through!

Here is the view from my roof of downtown San Francisco. Looks like a good place for a Mesh Node!


Last Thursday, Ben Chambers and Jessica showed up on my doorstep from Meraki Networks with APs in hand. I was psyched! We were about to hook up an outdoor node to the Meraki San Francisco trial.

They brought over a Meraki outdoor AP, a toolbox and a lot of cable and got right to work. We went up on the roof to check it out and find a spot to put it. Then we went indoors and talked about how/where to bring the cable in. The unit is powered by a proprietary POE (Power over Ethernet) injector which I plugged and hooked up to my switch.


Ben went back up onto the roof and connect the AP to a plumbing vent pipe. It came with what appears to be a 12dbi antenna (I will check and get back with the details).


It got link and pulled a DHCP address from my home router and started broadcasting the SSID FreeTheNet and we were done.














We chatted awhile and then they left. The were super nice and obviously loved their jobs. Later the unit started upgrading itself and is now running a newer OS than what it originally had. I checked that evening and found I was up on the website at http://sf.meraki.net/ but unfortunately none of my neighbors had a Meraki node close enough to attach to mine. I am going to drop in on Ritual Coffee later this week and get them to join the network as well as some of my neighbors.

Meraki Wireless Repeater Makes Extending WiFi Easy!

Meraki is now offering a great way to extend you WiFi network. Inexpensive repeaters. The Meraki Mini is a $49 (there is also an outdoor model for $99) AP you just put in your window and connect it to a MuniWiFi network or your own internet connection and then, according to their site, you just add more repeaters to make a mesh, "The more Minis that are out there, the bigger the network. And you can plug right into the repeater instead of going wireless."

I like this idea a lot. So much, in fact, that I use something somewhat similar myself. But is has a few drawbacks that are not mentioned on the website.

In my house we have one AP/Basestation/Router at the DSL D-marque and 3 WiFi repeaters throughout the house. I use the Apple Airport system so I have one Airport Extreme connected to my DSL router and 3 Airport Expresses connected using WDS (wireless distribution system) which mean none of my Airport Express units need a cable drop. It works really well, I can connect to any of the APs and surf the internet and I can stream music from my desktop or any connected laptop to any of them using Apple's AirTunes, even my Dell. The drawback is that every hop from the repeater reduces the bandwidth considerably as each device, with only one radio, has to spend half it's time talking to your laptop and half forwarding the signal. Wikipedia states, "...throughput in this method is inversely proportional to the number of "hops", as all traffic uses the same channel. For example, client traffic going through one relay station before it reaches the main access point will see at most half the maximum throughput that a directly connected client would experience." For me, this is fine as I only have 3Mb/s internet access but for larger mesh networks it begins to be a problem. Meraki suggests, "To boost the signal, connect every tenth one to the Internet." It is unclear from Meraki's documentation if the use separate channels or radios for the back haul.

The system also has a really great web-based management application called Dashboard which they give away for free. Dashboard allows the Network admin to monitor the network, change it's configuration and it has a built in billing feature if you wish to setup a hotspot or be your own neighborhood service provider.

The last really great thing about the Meraki solution is the ability to repeat the relatively weak MuniWiFi signal and project it into your home. This will allow users of these networks, especially one's in older homes with Lathe and Plaster or Stucco and chicken-wire construction to get a lot more signal strength and thus increased speeds. In fact, Meraki is already working in San Francisco to implement a Mesh network in and around my neighborhood. I have signed up for it and we will see where it goes. I will blog about it as it happens. Check it out at http://sf.meraki.net/

Anaheim Muni-Fi and Earthlink ready for Wi-Fi Phone Beta Testing - We need details!

The New Earthlink VOIP service is now ready for beta testing. Users in Anaheim may sign up now and get a free handset with the service during the tsting period according to Glenn Fleischmann over at WiFiNetNews

Good news for those of us watching the VoWLAN emergence but I have some questions:

It appears as if the service is tied to their phone. There is this quote in the release, "'What separates our Wi-Fi phone from others is its ability to work over EarthLink's municipal Wi-Fi networks,' said Steve Howe, EarthLink's senior vice president of voice."

• Does this mean that other SIP phones or dual band phones will not work?
  
• Is this an attempt to control the hardware and service.
  
• Has anyone tried using a different phone over the Anaheim network?

If this is true and we are locked into an Earthlink/Accton solution, it could spell doom for rapid adoption and raise the hackles of the "Free the Airwaves" folks.

Later on it also mentions that the Accton system is and ATA (Analog Telephone Adapter) based system. This would be similar to Vonage's home adapter. Again, more questions, can you use the handset while roaming about the network or just when in range of your own ATA base station?

Lastly (and in my opinion, most importantly), is it encrypted or are folks going to be able to sniff my call and play it back with VoiPong or something similar? Why do people always think of security last?

There are many questions we still have no answers to. If you know any, drop me a line.

RFID Tags for Apple devices. Wi-Fi Enabled Apple Remote, iPod and Other Peripherals

While setting-up wireless Wi-Fi network in your home now is much easier then it was few years ago, configuring all devices and establishing sufficient security protocols can still be pain in the … for average user. Now Apple has a solution how to make everything easy, automatic and secure - RFID tags.

The idea, described in Apple’s patent “RFID network arrangement” is simple. Put RFID transceiver into a network wireless base station such as Airport Express or Airport Extreme and put RFID tags on other devices that you want to connect to Wi-Fi network.

All network configuration information, including communication parameters, SSID info, radio channels, encryption keys, etc; can be stored in the base station. When RFID enabled network device is brought in to close proximity of the base station, RFID transceiver collects this information and writes it to read/write RFID tag on the network device. When this device is turned on, it reads configuration data and security keys from RFID tag and establishes secure network connection.

That’s it. From a user stand point - you just bring you Macbook within a feet of your Airport Express and the network is set up. You don’t even have to have a Macbook on at the time. RFID info to the tag can be read/written without additional power source. Then you turn your laptop on and it’s already on the network.

RFID tags also solve the problem of how to connect various “dumb” devices that don’t have appropriate user interface (like screen or keypad) for easy configuration:

• This may be the final piece in the puzzle to make Wi-Fi iPod a reality. Put WI-Fi chip inside, add RFID tag and that’s it. You take your iPod to your base station and then turn it on. Your iPod is another device on the network. Of course, passing Wi-Fi synchronization data to the iPod was already technically possible. But RFID tags make the process so much easier.
• One of applications mentioned in the patent is Apple Wi-Fi Remote for:
  

  “… controlling the operation of the iTunes music software provided by Apple computer… Such a remote control might have buttons for a variety of playback-oriented functions, such as play, pause, skip forward, skip back, volume control, etc, but such a device might not include an alphanumeric keypad or display device suitable to allow configuration of the device to operate over a wireless network. Using the teachings herein, such a remote control could be configured merely be bringing it into proximity with the computer or network base station…”

• Extending your WI-Fi network. You can have RFID transceiver on Airport Extreme and RFID tags on Airport Express. Then you just sync them and plug Airport Express where you need extended Wi-Fi coverage.
• Wi-Fi enabled network printer and any other peripheral. Again, put Wi-Fi chip in it, slap RFID tag on, sync. Your printer is another device on the wireless network

Looks like Apple did it again. The basic idea is so simple and obvious in hindsight, yet it opens so many new possibilities that there will be lot of people wondering “Why didn’t I think of that earlier”.

Building a Voice Capable WiFi Network

Building a wireless network that supports data traffic is hard enough but trying to support VOIP over your WLAN (also known as VoFi) can be a nightmare. To make matters worse, when you ask your vendor how to make Voice work on your WLAN they explain you will need 2X-3X as many APs as you needed for data. "Sure I do", you respond. Confident that the sales person from your vendor just wants to sell you more APs. Or, better yet, you turn to your trusted VAR and he suggests another site survey. "Right, another one", you say, with that knowing look in your eye and a sinking feeling that you are being strung along. You feel like the guy who brings his car in for a tune-up and gets told he needs a complete overhaul.

Well, I have nothing to sell you and no agenda that I will benefit from by saying this but your infrastructure vendor and your VAR are absolutely correct. You probably will need more APs and you sure as heck will need another survey. Lets find out why, shall we?

Unlike Email and web access, slight lags or delays in traffic or small losses in connectivity will completely destroy calls. A person who has access to the Internet durring a meeting in a conference room is far less likely to lose his cool for small delays than when he is on the phone with an important client.

You see, wireless handsets are much lower powered compared to the access points they talk through. A typical AP is usually set to communicate at 100milliwatts (mw) whereas the typical handset is roughly 5mw. This makes it very easy for the handset to hear the AP but very hard for the AP to hear the handset when it is far away. Also they are far less resilient to fragmented packets, retries, packet loss etc.

So what can I do? Well the simplest thing to do would be to ensure that the handset is always at the same power as the AP. That means either increasing the power on the handset or, more likely, lowering the power on the AP. This will mean, of course, that you will need more APs to cover the same area.

For example here are 4 APs at 100milliwatts:

Here are the same APs but now set to 5mw instead, notice the gaps in coverage:


In order to compensate, we must add many more APs to fill in the holes, all configured to run at 5 mw:


As you can see, much better. Now, though, our main issue is channels. APs that overlap thier signal on the same channel take away from the usable bandwidth. We want to ensure we do not trample the signal from another AP so we must adjust the channel plan.
Also, remember we only have 3 channels to work from.

Cisco, at this point recommends the following:

That explains why I limited the seen signal to -67dbM making all the other signal fall off and appear grey.

In a week or two, we will discuss debugging Voice issues and setting MOS scores.

The Ripple Effect - Problems with Cisco’s Radio Resource Management (RMM)

(NOTE: This information is out of date. Cisco has changed their RRM calculations and have removed much of the information linked to in this post.)


Introduction:

In its Unified Wireless Network architecture, Cisco has developed patent pending technology for dealing with interference detection and avoidance, dynamic channel assignment, dynamic power adjustment, coverage-hole detection and correction, rogue detection and client load balancing. This system is known as RRM or Radio Resource management. The stated goal of which is to avoid problems in the fixed ISM band of 802.11b/g where only 11 channels are available to U.S. WLANs. This system, though sound in theory, has problems when applied to large WLANs in urban areas or locales that have heavily deployed WLANs such as Metro WiFi, skyscrapers, hospitals, universities and businesses near residential neighborhoods.

Background on Channel Overlap:

Anyone who has configured their own home access point (AP) knows they are allowed to choose a channel for the AP to transmit on. Since APs use Dynamic Spread Spectrum technology they actually utilize 5 channels per AP.

If an admin were to configure APs to use all channels in the 802.11b/g spectrum, a serious decrease in available bandwidth would occur and users would experience sever throughput loss. Thus an admin is restricted to only configure his/her APs to 3 non-overlapping channels; 1, 6 and 11. In some cases an admin may opt, out of necessity, to go for a slight overlap and configure a 4 channel plan consisting of channels 1, 4, 7 and 11.

WLAN planning and Site Surveying:

Administrators need to then plan out their deployment so that each AP avoids overlapping its coverage with another AP on the same channel. APs must have their power adjusted to compensate for walls and coverage gaps that may ensue when a building is not a standard rectangular shape or when neighbors move in and configure their AP on a channel used by the organization the admin works for. This adjustment in power may increase or decrease the size of the cell of each AP and the additional adjustments to all the other APs will now be needed. Lastly, the admin must plan for areas where usage may change very dynamically such as in conference rooms and auditoriums. As one can see, this is really an art and a whole industry has evolved around designing wireless networks. Usually a Site Survey is needed to map out the existing neighbor APs as well as to plan where to place and map the new APs. Surveys are also recommended from time to time to adjust to changes that may happen around the organization as well as within it.

Cisco's Solution:

The Cisco Unified Wireless Network (UWN) architecture hopes to avoid this problem by sensing the types of problems that occur in WLANs and automatically compensating. Problems such as:

• A neighbor moving in next door or upstairs and implementing APs that overlap yours
  
• Coverage gaps that occurs when walls, cubicles and other furniture are moved, added or removed
  
• Loss in throughput when people, who are 78% water, move around in a company and group together in conference rooms or other areas (water attenuates or "blocks" radio waves)
  

Cisco has (had) a brief description on their website at HERE and a much more in depth description HERE

On that second page Cisco describes how this works under the section entitled, "Radio Resource Monitoring"

Management of an RF network requires strong visibility into the factors affecting the air space. Cisco lightweight access points are specially designed to not only offer service, but to also monitor all channels at the same time. This is a result of the extensive development work Cisco has performed on the 802.11 MAC layer as part of its split MAC architecture.

In addition to offering service, Cisco lightweight access points can simultaneously scan all valid 802.11a/b/g channels for the country of operation, as well as for channels valid in other geographies. This provides the highest level of protection-the system will discover rogue access points that might be imported from other countries, or a hacker that knows how to change the country of operation such that the rogue would be out of band and not detected by most WLAN intrusion detection systems (IDSs).

The Cisco lightweight access point goes "off-channel" for a period not greater than 60 ms to listen to these channels. Packets collected during this time are sent to the Cisco Wireless LAN Controller, where they are analyzed to detect rogue access points (whether service set identifiers [SSIDs] are broadcast or not), rogue clients, ad-hoc clients, and interfering access points.

By default, each access point spends only 0.2 percent of its time off-channel. This is statistically distributed across all access points so that adjacent access points are not scanning at the same time, which could adversely affect WLAN performance. This enables administrators to build a picture of what is happening in their WLANs from the perspective of every access point, and increases network visibility beyond what an overlay network can provide, eliminating the "hidden node" problem that can result when air monitors are deployed for every three to five access points.

I will not debate the issues around part time scanning in this article; many others have addressed that already. But I will address the next issue which is how Cisco responds once it has discovered any of the aforementioned problems.

When a station has something to say, it announces it to the media. An access point will allow the station to send its data if the medium is open. If not, the station will be told to wait to transmit until other stations using that medium are finished with it. This prevents two clients from transmitting on the same channel at the same time, which would result in corrupted frames.

With CSMA/CA, two access points on the same channel (in the same vicinity) will get half the capacity of two access points on different channels. This becomes an issue, for example, when someone reading e-mail in a café affects the performance of the access point in a neighboring business. Even though these are completely separate networks, someone sending traffic to the café on Channel 1 can cause data corruption in an enterprise using the same channel. Cisco wireless LAN controllers address this problem and other co-channel interference issues by dynamically allocating access point channel assignments to avoid conflict. Since the Cisco lightweight solution has enterprisewide visibility with its RRM tools, channels are "reused" to avoid wasting scarce RF resources. In other words, Channel 1 will be allocated to a different access point far from the café. This is much more effective than not using Channel 1 altogether, which is what other WLAN systems often do.

Later in the same document it describes a similar situation as Interference.

"Interference" is defined as any 802.11 traffic that is not part of the Cisco WLAN system, including a rogue access point, a Bluetooth device, or a neighboring WLAN. Cisco lightweight access points are constantly scanning all channels looking for major sources of interference (Figure 3).

If the amount of 802.11 interference a predefined threshold (the default is 10 percent), a trap is sent to the Cisco Wireless Control System (WCS).The Cisco Wireless LAN Controller will attempt to rearrange channel assignments to increase system performance in the presence of the interference.

Again I will refrain from diving too deep on interference sources as Cisco does not even have a way to detect much less respond to such non-803.11 interferers as Cordless phones, baby monitors, wireless cameras, DECT phones and headsets etc.

The Problem:

When you have a large number of APs implemented and you are covering a large area, the Cisco system will adjust to compensate for rogues, neighbors and interferers almost continuously. As you add more and more interferers in and around the WLAN, more and more adjustments must be made to compensate for these. As the compensations take place they run into adjustments coming the other direction from the other side of the building and you get a huge ripple effect that will in some cases cancel out adjustments and in others build up over adjustments. The WLAN starts to behave like a wave phase experiment.

Example:

Let us say that we are in a hospital in San Francisco where the average number of APs per block is around a hundred. The hospital has 20 APs per floor and 10 floors in the main building. That's 200 APs, which is quite a large number. This hospital, since it is in an urban setting has many neighbors, many of whom also have APs.

In a typical situation a neighbor to the hospital puts an AP on Channel 1. The Cisco architecture senses this and adjusts to compensate, moving APs from adjacent channels to ones farther away. At or around the same time but on the other side of the hospital, another neighbor appears but this time the AP is on Channel 11. A similar situation occurs there. At some point the two waves of adjustments meet or cross in the middle. This is made possible because the split MAC architecture of the Cisco UWN has many decisions made in its WLAN controllers. These controllers are distributed and can act semi-independently. By the time the wave reaches the other side of the hospital, the system realizes it is again being interefered and readjusts.

This wave or ripple action, because it moves across floors and up stories may go on forever. As more neighbors or interferers come on line more waves are sent out. The larger the implementation the worse the problem gets. The effect is readily visible and measurable to anyone with a WLAN analyzer. They will see MAC addresses hopping from one channel to the next on a second by second basis. They will also be changing output power continuously so the signal will be rising and falling.

Effects of the "Ripple"

The net effect of this phenomenon is a serious decrease in throughput and a large increase in latency. If you use your WLAN for applications that need low latency or high throughput such as VOIP over a WLAN (known as VoWLAN or VoFi) or you have low power handhelds such as the kind used for barcode scanning, this network is unusable. The VoFi traffic will be filled with jitter and conversations will be choppy at best. The handhelds will never be able to sleep or go to low power as they will always be probing for changes to the environment. If the system had been statically mapped to specific channels that do not change, the WLAN would have had problems, for certain, but these problems would be affecting just the few APs that face the neighbors. Now that all the APs are reconfiguring continuously, the whole WLAN is affected all the time.

WLAN STAs that are associated and attempting to pass data will continuously be probing for new channels and APs to associate with. The amount of roaming will go up dramatically. Roaming takes a few seconds to complete so the problem will be very serious for the end user.

Cisco even mentions this problem in one of their release notes for the CB21AG card found here: HERE

CSCse49324-CB21AG retransmission mechanism has problems with RRM in LWAPP network

A CB21AG client that is operating in an LWAPP infrastructure loses connection for small periods of time. When the AP is performing radio resource management (RRM), the AP goes off channel. During these periods, the AP cannot hear and answer ACK and RTS frames from the client. The client card initiates a scan for another AP, and network traffic for the client is affected.

Workaround: Increase the HwTxRetries value from 4 to 14 (registry entry) so that the client card continues to retry for the 20 to 30 milliseconds that the AP is off channel.

SpectraLink and other VoWLAN vendors specifically warn their customers not to deploy their Cisco UWN architecture with RRM enabled. When a WLAN needs to support voice, the requirements for stability increase dramatically.

Conclusion:

The idea behind automatically adjusting and configuring networks is a good one. Maybe sometime in the near future Cisco will program their controllers to avoid this type of effect but in the meantime, unless you have a pretty small network or are located far from interference sources and neighbors, admins are urged to complete a thorough site survey and statically map all their APs to a channel and resurvey from time to time.

Dilbert - The Knack

Got this from Adrian (thanks! I love you, Man!)

This is my mom and me when I was young. Adrian pointed out what a great voice the guy has.

How to Increase Your Wi-Fi Signal

OK, this guy is dorky and the tin-foil hat/antenna he made is so ghetto BUT his thing on carrier waves and the CAT 5 wrapped cell phone - pure genius.