Geek Tools – Ventev VenVolt

Any wireless engineer who has spent time completing AP-on-a-stick (APoS) surveys has probably used the Terrawave MIMO 802.3af POE battery. It was a heavy lead-acid battery in a metal case, which promised six hours of use before needing a recharge. Most days it did deliver 6 hours when powering an AP with a single radio enabled. However, I often found that if you ran both AP radios, it would regularly give you less; usually running right around 5 hours with a charge during a meal break.

Did I mention it was heavy? Travel through airports and the TSA was a lot of fun too!

Now, Ventev has a new battery, the VenVolt. It’s sleek, orange, and much lighter. The VenVolt has a bunch of new features which make this an essential addition to any wireless engineer’s toolkit.5132514

  • The battery is now a lithium iron phosphate. That’s the weight savings that makes this thing easy to take on the road. It also ensures plenty of power delivery when needed and long-term stability of that power. Additionally, LiFePO4 battery chemistry is known for higher cycle life and better stability, which should relieve any concerns of a Samsung Note 7 style battery fires.
  • Better power delivery allows the VenVolt to efficiently deliver 802.3at power; a requirement for 802.11ac access points.
  • If 802.3at power wasn’t enough, Ventev includes a three amp, 15 watt, USB power port. That port can be used to trickle charge a laptop, or it can power my favorite tool, an Odroid, which I always use when surveying.
  • That power port wouldn’t be nearly as exciting for me without the final major upgrade, ethernet passthrough.

There are lots of “little” updates that should be mentioned as well:

  • A single switch! No more guessing which switch combination was needed for charging.
  • An LCD screen that shows charge status, voltage, and gives you some guess of the available runtime.
  • The case is ruggedized and has been drop tested to ensure reliability.

Let’s talk through my “new normal” setup with the VenVolt. I connect the AP to the “802.3AF/AT Out” port. There is no difference between that and the old heavy battery.
Next, I connect an ethernet cable between the “Ethernet In” port on the VenVolt and the ethernet port on my Odroid.
Finally, I connect a micro-USB cable between the Odroid and the USB port on the front of the VenVolt.
The magic happens due to the flexibility of my Odroid. A few jobs it runs:

  • iPerf, HTTP, Ping endpoint for any throughput/active surveys that I need to run.
  • TFTP Server – This is where I host boot or firmware files for the many various AP’s that I might use for surveys.
  • DHCP/DNS Server – Makes it easy for the TFTP Updates, client connections, etc.
  • Encrypted File Storage – This is where I store backups of survey files, any building drawings that I am given, or any specifics that I might need at a location.

One final note. The VenVolt is labeled “MK1”. To me, this is a suggestion that updates will come in the future, rather than the “one-and-done” approach of the Terrawave Battery. While I’m excited to see what may come in MK2, this is an excellent upgrade and a definite requirement for anyone who spends time doing APoS surveys.

There was an excellent session at WLPC, where Ventev employees Dennis Burrell and Mike Parry, along with Sam Clements discussed the development process for the VenVolt. It’s worth watching:

Relevent Links:

Ventev VenVolt

Ventev Infrastructure

Ventev Infrastructure supplied me with a VenVolt for testing and provided me the ability to give feedback. All written content provided here is my personal opinion, and has not been manipulated in any way by Ventev. I appreciate all companies who welcome constructive feedback!

 

Geek Tools – Cape Networks for more than just wireless

In case you missed it, a couple of weeks ago I wrote about my experience testing Cape Networks solution for wireless monitoring. You can find that post here. I first learned about Cape Networks at WLPC, and was able to have a conversation with them at Mobility Field Day 2 that you can watch here.

One point that continues to impress me about Cape Networks is the ability to test much more than WiFi.

It really comes down to the strength of the dashboard and the various tests that each sensor can run. The ability to test against internal and external systems is one example.

Screen Shot 2017-09-15 at 11.57.05 AM

Each sensor can test against web servers, iperf, or custom ports of your choosing.

Users can configure a test to run against predefined external websites like Adobe Creative Cloud, Microsoft Office 365, Dropbox, and others. But, the sensor can also test against custom websites, checking not just “Is it up?” but HTTP status codes and latency as well.

I’ve used this recently to help an outside vendor truly understand that “No, our network is not to blame” for the high latency their users are complaining about.

When all other external websites are seeing ~20ms latency, and your web application is averaging ~90ms over a period of weeks, guess what? YOU have a problem!

Screen Shot 2017-09-15 at 12.06.02 PM

Averaging 96ms of latency. Maybe that’s why the application is always slow?

Obviously, due to the nature of these tests being performed over WiFi, latency, jitter, and packet loss are all expected to be a bit higher, especially if they are performed during times of peak WiFi utilization. However, when you have tests to compare across multiple online services, it’s easy to notice standout patterns.

One feature request I would make to Cape Networks is this: Allow test to be ran across both the LAN and WiFi connections. If we can compare across these two mediums, we may also see additional information useful in diagnosing wireless issues.

Have you found a non-WiFi use for the Cape Networks sensors? If so, tell me about them in the comments.

As a MFD2 delegate, I did receive a free sensor from Cape Networks and various stickers and other low value (but tasty) snacks. All other expenses for MFD were covered by Tech Field Day. I was not compelled to write about Cape Networks in any way other than personal user experience. My employers decision to purchase sensors was based solely on the user experience and ease of problem resolution.

Geek Tools: Ekahau’s New Sidekick

Today Ekahau went public with a new device that moves them from just another industry player to leading the wireless survey tool industry.

The Ekahau Sidekick answers a lot of questions that have been plaguing those of us who regularly do wireless surveys. To understand why it is such an important move for the company, you first need to understand a few of the pain points that comes with being a wireless engineer.

  • Some USB3 hubs create significant RF noise that can affect wireless survey results.
  • Many 802.11ac USB adapters have very poor consistency between devices.
  • Laptop batteries are often non-removable, requiring regular recharging when used for survey work.
  • How reliable is a 3×3:3 USB adapter when all antennas are internal without physical separation? (Short answer, they aren’t)
  • A laptop with 4-5 dongles connected to it is difficult to manage. I know many people who have snapped off a USB dongle in their career.

So, how does the Sidekick do it different?

  • It is a dual 802.11ac radio system with 3×3:3 radio chains and the appropriate antennas.
  • It has a very fast dual band spectrum analyzer with incredibly high resolution.
  • The device has it’s own 8 hour battery, and does not draw from the laptop battery.
  • Nothing to snap off and break. This thing is very rugged, and easily hangs from the hip as the engineer moves around.

So the big question is cost. The Ekahau Sidekick cost $2995US. The question of annual support was not answered during the presentation. This assumes the user already has an active license for ESS or ESS Pro.

Most importantly, by separating the hardware and drivers into a unique specialized unit, the Ekahau Sidekick can be used by those of us who use MacOS just as easily as those crazy few still using Windows. Drivers and firmware are no longer a concern.

Well done Ekahau!

You can find out more at: https://www.ekahau.com/sidekick

 

I received nothing to write this post. I am an active Ekahau user, and purchase licenses and support just like any other user. Hopefully, I will be able to convince my manager that he should fund one more purchase…

Geek Tools – Installing Spectools on WLPC Odroid

spectoolsscreenOne of the maker sessions from WLPC was setting up an Odroid for use as a network tool. It was a great session and I hope to see more of these at future WLPC’s. Once the videos are posted, you will be able to find the link here.

The first thing I wanted to try was installing Spectools on my Odroid to use with my Metageek Spectrum Analyzers. I have two Metageek Wi-Spy DBx’s and thanks to the 2017 WLPC bag, one Wi-Spy 2.4x.

The Wi-Spy 2.4x analyzer is supported in a much older version of Spectools. If you only own that one analyzer, simply run the following from the CLI:

sudo apt-get install spectools

On the other hand, if you want to use Spectools with a DBx, you must compile from the latest version. This takes a bit more work as it must be compiled from the source code. After fumbling around with it along with Jerry Olla we were both able to get it successfully installed and working.

Here are the directions which worked for both Jerry and I.

  1. Install the required prereqs:
sudo apt-get install libgtk2.0-dev libusb-dev build-essential

2. Clone the Spectools package:

git clone https://www.kismetwireless.net/spectools.git

3. Change to the Spectools directory:

cd spectools

4. Now, the fun part. The included config.guess will not recognize the Odroid. However, the distribution installed on the Odroid includes a MUCH newer version that will, so we need to copy it to the spectools directory:

cp /usr/share/misc/config.guess config.guess

5. Now we can follow the standard process to compile Spectools to operate on the Odroid.

./configure
make
make install

And with that, Spectools should now support the Metageek dbx. Install VNC, and you have an easily deployable sensor.

Up next, installing Websockets for wi-spy

GeekTools: SolarWinds Wireless Heat Maps

Ever changing environments are the biggest problem that wireless engineers face. A new site can be surveyed, and based on that, an ideal wireless design can be created for the space providing perfect signal, overlap, and SNR; the wireless engineer leaves the site, SolarWinds NPM Wireless Heat Mapsmoving on to the next assignment, and that perfect design last through the weekend. Now the engineer is located in a different state, working on a different project, and is getting calls from the customer.

“Hey, we have problems, and I need you to fix them.” the customer says.
“Ok, can you describe the problem for me?” the engineer ask. Secretly, the engineer is shocked the customer is calling for any reason other than to laude the engineers talent, foresight, and general awesomeness.
“None of our customers can connect in the waiting area.” states the customer with disapproval.

Generally, troubleshooting this type of problem is straight forward. A quick look for interferers, a check to ensure all equipment is still functioning, and a general eye for anything that has changed. As a nod to the possibility of a changed environment, a simple question is asked.

“Has anything at the site changed? the engineer queries.
“Of course not” is the answer the customer provides, voice now dripping with disappointment.

Thus, the engineer continues to dig further.

Large enterprise organizations who deploy Cisco hardware generally keep maps for each facility in Cisco Prime. Smaller organizations without the budget or time to assign to Prime can find themselves looking for a different solution.

SolarWinds has a new solution that is part of NPM 11.5 and it is worth investigating. They now offer wireless heat maps. The simplicity of setting up the heat maps makes it easy for under-staffed shops to use the tool effectively. Import the floor plan, set scale, and then drag the AP’s supplied by the Cisco WLAN Controller onto the map into the correct locations. Once the AP’s are placed, the software makes a best-guess of wireless coverage. This is a standard but flawed practice.

The issue lies in physical placement of the AP’s within their environment. The AP’s are all at ceiling height, above cube walls, water features, whiteboards, and many other sources of signal degradation. The clients are on a much lower plane, and therefor see a different footprint.

SolarWinds solves this issue by allowing an engineer to place known clients on the map, and then use those to further improve the heat map. This provides a tool that can be used to understand what is happening at standard client heights, where signal matters.

“Oh look, now I see a huge null in the coverage.” the engineer says. “Are you sure there haven’t been any changes near the AP I placed by the receptionist desk?
“Oh, that’s right. We hung the sign this weekend” says the customer.
“That large metal sign that was in the shop area last week?” ask the engineer.
“Yeah, that’s the one, We suspended it from the ceiling right over the receptionist. It looks awesome. That wouldn’t cause this problem would it?”

The engineer proceeds to bang his head against the desk with a dull thud, thud, thud.
*Names have been changed to protect the identities of those responsible*

Watch SolarWinds discussing their wireless heat maps at Network Field Day 9 here: (Heat map discussion starts at 19:40)

-I participated in Network Field Day 9 as a delegate. As part of that participation, the cost of all travel and accommodations were covered. Additionally, some companies chose to give delegates small gifts for their participation. These accommodations do not in any way constitute a requirement for coverage, good or bad. In short, I am an opinionated jerk,  I was invited despite that, and anything I write is purely my own opinion. Special thanks to Tech Field Day, for the service they provide to engineers and vendors. If you would like to be a delegate at a future event, you can learn more here.  

Geek Tools – SSH and Telnet on OS X

Since I made the switch to a Mac in my day job, I’ve had two major frustrations. The first is the lack of Visio for OS X. The second one, was a little more major. I needed a replacement for MRemoteNG. I’ve searched for options and grown weary of reading the general post of “why would you need a specialized SSH tool, when it is built into the terminal of OS X?”

That statement is usually offered by a web developer who might have SSH connections to 3-5 servers on a daily basis. They live in a very specific world, and have a hard time understanding anything outside of that world. Feel bad for them; don’t hate them.

In the world of network engineers however, we may connect to 50 or more devices in a day, and may have logins to thousands of devices over an enterprise network. In that environment, there is a real need for the ability to bookmark devices.

After searching for options, I found one option that worked to some extent. This SSH workflow for Alfred is excellent. However, since I use a hosts file from someonewhocares.org to block a lot of advertisers and trackers, the index was never very useful.

After considering this problem from all angles, I finally had an “AH HA!” moment, and the simplicity of the solution made me equal parts giddy and disappointed that it took me so long to resolve. I created a file with a similar layout to a hosts file, in-fact I even named it hosts.txt. Each row of the file list a hostname, and an IP address. Since this file is purely text, you could add anything to each line that you wanted. 

#site1
device1 10.0.1.1 description
device2 10.0.1.2 unique protocol info
device3 10.0.1.3 more information
device4 10.0.1.4
#site2
device1 10.0.2.1
device2 10.0.2.2
device3 10.0.2.3
device4 10.0.2.4
device5 10.0.2.5
#site3
device1 10.0.3.1
#site4
device1 10.0.4.1
device2 10.0.4.2

But how does this help us manage thousands of devices you ask? It doesn’t, but grep does. If we pass a search string to grep along with the file name, all matching hosts show up. Yes it is simple, but it is useful because of that!

In my file, I created a site heading by starting the line with an octothorpe. I use this so that I can search for sites. This looks like:

grep ^# hosts.txt
#site1
#site2
#site3
#site4

I can also search for all devices at a location using a statement like:

grep ^#site2 -A6 hosts.txt
#site2
device1 10.0.2.1
device2 10.0.2.2
device3 10.0.2.3
device4 10.0.2.4
device5 10.0.2.5
#site3

In this case, I am telling it to start at “#site2” and show the next 6 lines. Since the 6th line is the next site, I know that I am seeing all of the devices from site 2.

Finally, if I know part of the hostname, I can simply search on it, and it will display.

Hopefully this gives you a better way of managing huge networks from terminal.