THE BLOG ★ Ramblings on WiFi & stuff.

Is your CAT6 cable CAT6? Probably not. via @HackaDay →

Well, this sucks:

via HackaDay →

This is the part where [Blue Jeans Cable] earns our respect; like good scientists, they set out to replicate Fluke’s results. Sure enough, 80% of the Cat 6 cables they tested from big box stores etc. failed the specification. More surprising, many of them didn’t even pass the Cat 5e specification.

So, it's bad enough that 11ac APs are bringing up the throughput game, as well as the fact that any AP will typically have more throughput than a single device connected to a wired port - simply because one AP hosts multiple clients. But, now we're being told that cable manufactures aren't even meeting the bare minimum specification for CAT6 cabling?

I'm glad someone took the time to verify this. Just like wireless, or any networking hardware - you get what you pay for. Using trusted brands is a start, but wireless engineers should understand that a wireless install doesn't end with the AP. There's also the cabling infrastructure itself. It can be just as much a bottleneck as a crappy AP.

Going all 11ac? You're most likely not going to need +Gigabit ports, or two cables to each AP (for now), but you WILL need to up your uplink game. Gigabit uplinks probably aren't going to cut it. Also, TEST you cables! Or, better yet, have your cable installer test and VERIFY the cables for you.

One great tool for at least validating connectivity on an APs cable is Fluke's LinkSprinter. This little handheld tool checks for connectivity (Is there DHCP? A gateway? Internet access?), as well a PoE, and Link speed of the cable. It doesn't validate the cable for CAT6 specifications, so you'll need a real cable tester for that, but it at least insures that connectivity to the network is functional.

This is a good reminder to make sure your infrastructure can support your WLAN - all the way from the cabling itself, to the switch ports, the uplinks, the router/firewall capacity, and ISP.

Go read the article. It has some good links to Fluke's page on cable testing, and Blue Jeans Cable post on their test results.

♻︎ Today’s Quality Linkage

First thing's first: REQUIREMENTS

Estimated reading time: 2 minutes, 14 seconds. Contains 448 words

 

I was at a meeting today with a large Mechanical/Electrical Engineering firm who was in need of some wireless expertise. More and more they are getting asked to include wireless "designs" for building projects and are finding (as many do) that it's not as simple as it seems.

The discussion took many turns, but often came back to something like, "So, if we have a school with say 35 students per classroom how many APs do we need?" My answer would be, "it depends." What does it depend on? Their requirements.

How many clients (not users, but devices)? What type of clients (1 stream, 2 stream, 3 stream)? What applications will they be using (e-mail & web, video streaming vs. YouTube caching, voice, etc) What are the bandwidth requirements for their State testing? And more.

The point was - just like they could not just "make up" an electrical, or engineering design out of the blue (How many people need to be in the space? What's the total power consumption required? Do we need HVAC in all locations?) - one could not just "make up" a WLAN "design" (Well, one could, but then you get what you get). That made total sense to them which was good.

I love explaining how wireless works and seeing their eyes light up. I love how it makes sense to them when I explain why they're not going to see 1.3GBs throughput, or adding more APs is not a default answer to a problem, how coverage & capacity are different things, how having a bunch of low-end single stream devices is not as efficient as have a bunch of 2, or 3 stream devices, etc.

The FIRST step to wireless network design, and the best way to avoid the BAD-FI, is to determine the REQUIREMENTS and EXPECTATIONS of the customer. Here just a few of things you should consider:
 

  • How many clients will be using the WLAN?
     
  • What are the types/capabilities of the devices? (# of streams, 5GHz support, DFS support, 802.11r/k/v support, etc.)
     
  • What applications will be using the WLAN and what are the requirements of those applications?
     
  • Is there a budget for the project?
     
  • Are there accurate, scale floor plans available?
     
  • What security and authentication types are you looking to support?
     
  • What the total bandwidth coming into your facility?
     
  • What is the time-frame for the project?
     
  • Aesthetics: Are external antennas ok? Do LEDs need to be off Should APs be inconspicuous?
     
  • Cable lengths: where are/is the MDF/IDFs located? More than 300ft from the APs?


These are a few off the top of my head, but you get the gist. DEFINE your customer's (or, YOUR) requirements and expectations BEFORE you design a solution.

Anything else and you're just guessing.

♻︎ Today’s Quality Linkage

Bigger ain't always better.

Estimated reading time: 4 minutes, 31 seconds. Contains 904 words

 

I was asked to come and troubleshoot a WLAN that was experiencing connectivity issues. All we knew was this was a brand-new installation and that it was the latest hardware available from this particular vendor.

The first thing I did upon arriving on site was scan the area as we walked around. Immediately I saw something that was troubling. All of the brand-new 802.11ac access points were broadcasting on 80MHz channels, and there were no DFS (Dynamic Frequency Selection) channels being used thus limiting their channel re-use options even more.

As you can see in the chart below there are only TWO 80MHz channels available for use without DFS channels (the entire UNII-2) :

5GHz Channels in the US

Even in a deployment as small as this one (they only had eight APs) using 80MHz channel is a non-starter. The WLAN was literally interfering with itself. Even enabling DFS channels would have been a difficult thing to make work, even then (theoretically) we could have 5-6 channels. However, channel 144 is ONLY usable by 802.11ac devices. So, typically, we don't use channel 144. Also, if TDWR (Terminal Doppler Weather Radar)  is within hearing range of the WLAN, those channels are not used. Now we're down to FOUR 80MHz channels. Four channels may work in a small environment, but then you have to consider WLANs other than yours.

Unless you are in a secluded area there will probably be other WLANs within earshot of your network. So, if any of the secondary-channels that make up the 80MHz channel that you are on are also in use by other clients, you will experience issues. In this case, the WLAN was in an office building that had other tenants with their own WLANs. So, using 80MHz channels in the scenario was the main cause of their problems. (Even if they were secluded usage of 80MHz channels would not be practical.)

The fix was simple. I enabled DFS on their controller and disabled 80MHz channel usage. This immediately dropped all APs (access points) to using 40MHz channels. And, with the use of the now available DFS channels, we had NINE channels to use among 8 APs. The point here is DFS gives A LOT more channels to work with - so it's worth using them.

I can't blame the customer for this. The installer should have known that 80MHz channels in an enterprise environment is not practical, or in this case, even viable. It was clear what had happened. The system defaults were left as-is, and there was little to no customization of the WLAN.

By default, 80MHz channels were enabled. 

By default, DFS was disabled. 

By default, all APs were set to transmit at maximum power.

This just shows the importance of knowledgable and experienced when deploying wireless networks. It's more than mounting APs and creating a few SSIDs. It's understanding how RF (radio frequencies) work, what its limitations are, and how to design around them.

One last note on using DFS channels. I have seen great success using them, but the reason DFS channels are not enabled by default is because they share spectrum with radar systems:

 

DFS is a mechanism to allow unlicensed devices to use the 5GHz frequency bands already allocated to radar systems without causing interference to those radars. The concept of DFS is to have the unlicensed device detect the presence of a radar system on the channel they are using and, if the level of the radar is above a certain threshold, vacate that channel and select an alternate channel.
 
- Aruba, an HP Enterprise Company

 

For this reason DFS is disabled by default on Aruba controllers (the system I was working on). If near an airport, a marina, or military installation, you should consider the possibility of radar events. A radar event occurs when an AP hears (or, thinks it hears) radar on the channel it's on. When this occurs the AP immediately switches to another channel (as per FCC regulation). This will cause all the clients on that AP to be disconnected. They will then probe for a new AP and reconnect. With a few events per month this may not be a big issue. But, if you have mission-critical applications (a hospital perhaps) radar events may not allow DFS to be an option. You may even need to go down to 20MHz channels so you can have more spatial re-use with non-DFS channels.

I recommend enabling and using DFS whenever possible. Then monitor your network for events. If they never occur, or are very infrequent then continue using DFS. If you see events that seem to be centered on certain frequencies disable just those DFS channels. 

Enabling DFS channels

Disabling 80MHz support

The easiest way to monitor for DFS events on an Aruba controller is from the CLI. SSH into your controller and use the following command:

(controller) # show log all | include Radar

Do this every few weeks. Then if all seems good - once a month, or so. If you're lucky enough to have an NMS (Network Management System) perhaps you could setup alerts for these events.

The four things I hope you get from this post are:

1. 80MHz channels are impractical for enterprise use.
2. Use DFS channels whenever you can (which should be most of the time).
3. NEVER take the default settings from manufacturer at face value.
4. When in doubt hire a professional.

 

* Originally posted on my company blog at CommunicaONE.com

UPDATE:

Thanks to my buddy, @tritterbush for pointing out that "disable "VHT." was incorrect. The better way to disable 80MHz is just to disable it in the ARM profile for that AP group.

 

 

♻︎ Today's Quality Linkage

LinkNYC's free gigabit Wi-Fi is here, and it is glorious

“After connecting to one of LinkNYC’s gigabit wireless hotspots, the futuristic payphone replacements that went live for beta testing this morning, I’m seeing download speeds of 280 Mbps and upload speeds of 317 Mbps (based on Speedtest’s benchmark).”

I'm eager to see how this looks when hundreds of people are connected to each of these APs. This was a speed test taken right when the Wi-Fi went live, not when it was in full use by the NYC metropoli.

I've some concerns about this due to stuff I've read and some pictures I saw on how the APs were installed - indoor Ruckus APs mounted upside-down. Regardless, I think this is awesome - getting free, FAST, wireless to the masses. Hope this works out.

Fierce Wireless: Work on LTE-U testing regime ongoing, but it's unclear when it will be finished

“A top executive from the Wi-Fi Alliance said the group is making progress in its efforts to create a testing regime for LTE-U technologies, with the goal of creating some common ground between the Wi-Fi industry and the cellular industry over the controversial technology.”

Looks like there may be some hope in the LTE-U Wars. Testing & validation of WiFi and LTE-U is important, but who knows how far this will go? The LTE-U stakeholders formed their own standards body, but working with the WiFi Alliance would help to validate, or in-validate the concerns of many of us in the wireless industry.

 

ZDNet: "These were the worst passwords of 2015, and they're only getting worse"

“The most common password of last year is “123456,” which sadly probably isn’t a surprise considering statistically there’s a good chance that’s your password.

Following that, it’s “password” and “12345678,” which just shows that you aren’t even trying anymore.”

And it gets stupider:

“Perhaps the most telling detail is how far some of the previously most-common passwords are rising up the ranks year-over-year.”

If you're using a password like this you get want you deserve.

I suppose the only thing worse is posting your passwords on a sticky note on your monitor? You could get the of these like my Mee-Maw uses!

I mean, Geez, we have PASSWORD MANAGERS now!

♻︎ Today's Quality Linkage