Mist Systems Unveils an Environmental Sensor that is also a Wi-Fi 6 AP

At Mobility Field Day 4, we heard from a few companies which are working hard to extend the capabilities of their AP’s well past only serving traditional 802.11 clients.
Mist Systems, a Juniper Company, was one such presenter, and they might have a fantastic new platform with their latest hardware, the AP43.

Mist Wi-Fi 6 AP Specs

The idea is simple. Most campuses have AP’s covering their entire environment. In many large environments, they share that ceiling space with other types of sensors or networks. These overlay networks may include building and security sensors, Zigbee control of lights or door locks, and test sensor networks.

In many ways, Mist has been a bit ahead of this curve. Their AP’s already included an IoT port, which enabled triggering devices like door locks or sensing through a variety of GPIO sensors.

Their new AP43 is a dual 5Ghz capable 802.11ax access point. It includes 802.3bz NBASE-T port to ensure the network port never becomes a bottleneck. That port also includes 802.3bt power capabilities so that it can pass power out of its secondary port, enabling it to daisy chain any 802.3af network device. The obvious candidate here is the BT11, Mist’s BLE sensor.

Further, each AP43 includes built-in sensors to provide temperature, humidity, barometric pressure, and angle/orientation. The inclusion of these sensors come with some unique engineering challenges. If Mist is successful in getting them to work appropriately, it could be a game-changer.

The biggest challenge when considering environment monitoring on an access point is heat. Anyone who has ever touched an AP that has been on for a while knows it can be hot. Thanks to the first law of thermodynamics, we know that all energy consumed by the AP that doesn’t get radiated as RF is instead transformed to heat. But that heat output isn’t consistent. It will vary based on the transmitter duty cycle or CPU load of the AP.

Additionally, that heat creates a micro-climate around the AP, which will lower the humidity percentage since warm air holds more water than cool air. Warm air is also less dense, which may affect the barometric pressure sensor.

The humidity/heat problem is further exacerbated by the fact that all water in the air is absorbing a small amount of the radiated RF power.

Finally, the ceiling can be many degrees warmer than in the same room at desk level.
These are challenges that I am sure Mist has taken into account, and the fact that they can work through them is impressive. Having environmental reporting built into the AP could make for a fantastic use case for building managers.

Moving down the list, the barometric pressure and orientation/angle sensor have some compelling use cases. By comparing atmospheric pressure among AP neighbors, Mist should be able to tell which AP’s are on the same floor in multi-floor buildings. This information could significantly impact 802.11k neighbor reports. By excluding AP’s which may be heard by the AP, but are obviously on a different floor, the chances of a client choosing a better roam candidate increases.

By comparing atmospheric pressure among AP neighbors, Mist should be able to tell which AP’s are on the same floor in multi-floor buildings. This information could significantly impact 802.11k neighbor reports.

Finally, the angle sensor can help identify AP’s mounted on a wall versus a ceiling. With that information and Mist’s ML backend, it should be able to better locate clients in RTLS environments.

These new sensors extend the AP capabilities well past the traditional use cases. Can Mist pull off the environmental monitoring? Can they adjust their neighbor report automatically based on elevation? I’m excited to play with these features in the future and get to the bottom of these answers and more.

Either way, it is clear that Mist has built the AP43 as a platform they can innovate with and I’m excited to see where they take it.

Take a look and tell me what you think:

Mist Systems Mist AI for AX – Wi-Fi 6 from Gestalt IT on Vimeo.

Arista announces acquisition of Mojo Networks

Today after the markets closed, Arista announced the acquisition of Mojo Networks. This is a very interesting development, and I am curious to see what Arista does with the technology.

You can read the press release here.

If you are asking “Who is Mojo Networks?” you clearly weren’t paying attention at MFD2 during the Mojo Networks presentation. Take a look at it here:

Mojo Presents at Mobility Field Day 2

You can see more at the Mobility Field Day 2 Event page:

http://techfieldday.com/appearance/mojo-networks-presents-at-mobility-field-day-2/

What do you think about this team up? Is this a good decision for Arista? How do you see it impacting the WiFi community?

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!

 

KRACK Attack Mitigation – A Call to Arms!

Ask any wireless engineer about the relationship with vendors who make the non-standard clients on their network and you’ll likely get a range of responses from quiet sobs to yelled expletives.

Problems ranging from bad driver or firmware updates, KRACKdevices which don’t follow the 802.11 standard, and long delays in problem resolution are all part of the experience.

Often we may say to a customer “These clients are causing problems and here is proof. You should look at replacing them.” While the vendor of those products are telling that same customer “Your network sucks!”

With that in mind, I want to consider a few things as we begin the KRACK Attack mitigation.

  • Check CERT’s Vulnerability Notes Database for the status of vendor updates. This is a pretty extensive list, and is worth following:
    CERT’s Vulnerability Database
  • Some vendors will be VERY slow to issue patches. It is absolutely essential that we as wireless engineers who have the ability to approve devices refuse any new client deployments without the appropriate patches.
    Bring the security team into the discussion, and ensure that as a united front, unpatched clients are refused!
    Those who work in a sales role should warn all customers away from vendors who are not actively communicating their patch strategy, with clearly defined release dates. We should not send money to any company that doesn’t see resolving this as one of their highest priorities. Those companies should wither and die.
  • Many large enterprises have specific budgets for IT security related expenditures. If the budget isn’t available from teams responsible for the devices, check with the security team. They may have a budget that can be utilized.
  • Communicate to the vendors this week. Ask about patching schedules for KRACK. Ask to be included in weekly updates on the status until patches are released. Make it very clear that you see this as a high priority and are not willing to accept a “Maybe, eventually” patch schedule.

As a group of wireless engineers, we cannot accept anything less than appropriate patches which clearly mitigate KRACK.

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.