wifi

WN Podcast 031 – Surveys, Design & Teaching Tips with Ferney Munoz

Welcome to our new WiFi Ninjas Podcast episode!

Today we talk about WiFi design and teaching tips and some crazy, unconventional surveys using GPS & Segways in quite niche verticals like slums, city outdoors and mining. Welcome our special guest and a great teacher – Ferney Munoz!

Enjoy!

Tons of love x,

WiFi Ninjas

WN Podcast 030 – WiFi 6E – Our Wireless Salvation

Welcome to our new WiFi Ninjas Podcast episode!

Today we discuss new extension to the happy WiFi family – the WiFi 6E. Enjoy!

  • WiFi 6E
    • Stands for WiFi 6 “Extended”
    • Announced by WiFI Alliance on the 3rd Jan 2020
    • Not yet cleared by the FCC
  • Drivers
    • More need for capacity
      • CCI being major performance killer today
      • Vendors push for more bonding – practical to do so in 6GHz?
    • 8k, VR, AR, Enterprise Conferencing
    • WiFi boom in the industrial vertical (can’t blame them)
    • Ultra-fast broadband (300Mbps+) and fibre to the home are quickly becoming a norm, reaching 53% of properties in the UK in 2019. Both Ninjas have 50 down and 10 up. We’re embarassed sitting in the bottom feeding half of the population 🙂
  • Ofcom proposition for the UK
    • Ofcom is responsible for authorising use of the radio spectrum in the UK
    • Make the lower 6GHz band (5925-6425 MHz) available for WiFi
      • Including Very Low Power (VLP) outdoor use
      • Remove DFS from WiFi channels in the 5.8GHz band (5725-5850MHz, which is UNII-3, also referred to as Band-C)
        • “We made the 5725-5850 MHz band available for Wi-Fi use in 2017 and said we would keep the regulations under review. Our current analysis indicates that the band is very lightly used by Wi-Fi routers in the UK, which is in part due to the UK-specific requirement to implement DFS in this band, and that the interference risk to radars from indoor Wi-Fi use is very low. We are therefore proposing to remove DFS requirements for indoor use (up to 200mW) only from the 5725-5850 MHz band to increase use of the band and reduce congestion in other channels”
      • Ofcom consultation will be open until 20 March 2020
      • Ofcom believes that WiFi bands should be as globally harmonised as possible and intend to drive international discussions intending to promote the benefits of a simple regulatory regime
  • Broadcom launches world’s first WiFi 6E 6GHz chips
    • Intended for enterprise APs and residential networks
    • 4×4 dual band 160MHz support
    • 2×2 tri-band
    • 2×2 dual-band with ARM CPU
  • Intel apparently not far away from having their own 6GHz WiFi chipsets
    • Already demonstrated it at last MWC in Barcelona
  • No words from Qualcomm yet
    • Qualcomm still dominates WiFi 6 enterprise AP market
  • Regulators
    • FCC has not made its final decision as of Jan 2020
  • Numbers
    • 125 million WiFi6 smartphones have been shipped until now
  • New frequency
    • 1.2GHz wide new spectrum in the US
    • 500MHz wide new spectrum in the EU
    • Today in the UK we have 25x 5GHz (585MHz to be exact) and 4x 2.4GHz 20MHz (exactly 83MHz) wide non-overlapping channels
  • Newly proposed 6GHz band is approx. 3 times bigger than sum of total spectrum used today for WiFi in the US and almost doubles available spectrum width in the UK
  • This translates to:
    • New US Channels (5925MHz – 7125MHz): 59x 20MHz, 29x 40MHz, 14x 80MHz, 7x 160MHz
    • New UK Channels (5925MHz – 6425MHz): 24x 20MHz, 12x 40MHz, 6x 80MHz, 3x 160MHz
  • And this is how the new spectrum would look like:
    • From Aruba Chuck (thanks man):
  • Closer view at the new frequency in the UK:
  • Legacy support
    • IEEE decided that only WiFi6 will be operating in the 6GHz band
    • Totally legacy-free with ‘but’
      • No legacy devices, sure
      • Legacy support mechanisms are still there
      • It’s still ‘just’ WiFi6 – preamble uses most robust data rate, so 6Mbps, etc.
      • Should it have been WiFi7 instead?
      • No new logo / notification required
  • Challenges
    • Differences in available spectrum in US vs rest of the world
    • WiFi 6E will overlap with widely used UWB channel 5
      • Some UWB systems using channel 5 will most likely move to channel 1 in 3GHz band
      • Poor UWB – CBRS will overlap UWB channel 1
  • WiFi6E Overlap with other tech, like mobile broadband backhauls, broadcasting, local authorities, etc.
  • Conflict with Facebook that was planning to use 6GHz band for AR/VR (app is called Spark)
  • Adoption
    • Once cleared, it should be quick and mind bending
    • WiFi will contribute to 1 trillion dollars in economic value in the US
    • Major chipset vendors already have 6GHz ready
  • Some comments about 6e from experts and vendors
    • “Wi-Fi has become the most important wireless technology for American consumers and businesses, and is projected to contribute almost $1 trillion in economic value to the United States by 2023. As the application and overall demand for Wi-Fi continue to surge, access to the 6 GHz unlicensed spectrum will enable Wi-Fi to continue delivering the vast innovations and socioeconomic benefits it is bringing to the market today while helping to ensure Wi-Fi can meet the new promises of the 5G era and beyond.” – Chuck Lukaszewski, vice president of Wireless Standards and Strategy for Aruba, a Hewlett Packard Enterprise company
    • “Wi-Fi has changed the world, and we are excited to work with Wi-Fi Alliance to ensure Wi-Fi will continue changing the world. Wi-Fi 6’s growth into the 6 GHz spectrum is a game changer for two reasons – the availability of the additional channels and the ability to finally use 160Mhz for high bandwidth applications like AR and VR; this provides enormous opportunities to build new applications and experiences for both consumers and businesses. By standardizing on Wi-Fi 6E, Cisco Meraki and others in the industry can begin delivering next-generation wireless experiences to customers.” – Jayanthi Srinivasan, Director of Product Management, Cisco Meraki
    • “With every increase in available bandwidth, new devices and applications come along that leverage that space to provide experiences we never before imagined, yet quickly become part of the fabric of our everyday lives. Brand new Wi-Fi spectrum in the 6 GHz range will more than double available Wi-Fi frequencies and have a profound effect on Wi-Fi enabled communications. This additional bandwidth not only enables higher Wi-Fi 6 performance with less congestion, but also delivers sufficient spectrum to effectively deploy 80 MHz or 160 MHz-wide channels, severely restricted at 5 GHz. 6 GHz finally and legitimately provides the higher data rates required to drive virtual and augmented reality forward, giving users and organizations the ability to develop a whole new world of use cases.” – Perry Correll, Director of Product Management, Extreme Networks
    • “I’m not sure AR should be considered the main factor behind the WiFi6E new spectrum availability, but leveraging 160MHz channels in this new-generation, market shifting, brain smashing, WiFi ‘plus’, ‘pro’ or ‘premium’ band would certainly allow me to stream 16k 480Hz turbo-HDR videos from next-generation Netflix. Lol. Now, seriously – it’s a chance for a fresh start, so I really hope that lack of support for legacy PHY will be accompanied by alterations to the WiFi6E, so we can move on from using legacy mechanisms requiring us to use robust PHY rates for some WiFi transmissions. Fingers crossed.” – Mac, WiFi Ninjas

Matt, chicken, didn’t want to comment 😉

See you in 2 weeks!

Tons of love,

WiFi Ninjas

xXx

WN Podcast 029 – RTLS with Bob Friday

Welcome to our new WiFi Ninjas Podcast episode!

Today we discuss indoor RTLS with an industry legend Bob Friday. Enjoy!

  • What friction / hurdles are stopping indoor location from becoming a must have
  • Mist implementation of indoor RTLS using BLE
  • RF design for Mist BLE
  • Mist BLE vs competition
  • Mobile stations with app vs without app
  • Assets tracking
  • Is there still a place for BLE beacons
  • Location API – integration examples
  • Mobile SDK – integration examples
  • Apple’s adoption of UWB in the latest iPhones and what that means for the industry
  • Who are the early adopters of RTLS
  • As major market disruptors, who are you targeting?

Tons of love x,

WiFi Ninjas

WN Podcast 028 – Channel vs Spectrum Utilisation & Ghost Frames with Ben Miller – Part 2

Welcome to our new WiFi Ninjas Podcast episode!

This is the continuation of our chat with Ben Miller, where we’re discussing channel utilisation vs spectrum utilisation vs duty cycle, ghost frames and potential impact of setting minimum data rates too high.

Channel Utilization

  • What is it
  • Does lower % always mean a better RF?
  • Good vs bad channel utilisation
  • Does channel bonding affect channel utilization?
  • Shall we rely on channel utilization for tshooting?

Internet’s favourite: channel utilization vs spectrum utilization vs duty cycle

  • Real Time FFT [dBm]
    • Current spectrum utilisation
  • Spectrum Utilisation [%] = FFT Duty Cycle [%]
    • Spectrum utilisation over a short time period
  • Waterfall = Swept Spectrogram
    • RF Power over time

Tools

  • Tools of choice for channel / spectrum utilisation
  • Protocol analysis

And a very helpful screenshot from Joel’s presentation!

Tons of love x,

WiFi Ninjas

WN Blog 025 – Hidden SSIDs

Hey!

Welcome to our first blog post of 2020! Happy new year to all 🙂

We wanted to kick off this year’s first blog post covering how secure is a Hidden SSID. We have been into a few customer environments recently where they were hiding some of their SSIDs as they believed this was more secure.

Shout out to Mr. Andrew McHale for his explanation as to why we shouldn’t be hiding SSIDs:

“Some clients don’t probe for SSID’s, they rely on Beacons to decide what is available. If you hide the SSID in the Beacon then some clients won’t see SSID to connect to.

Others will try listening to beacons first and only probe if they don’t see the SSID they’re looking for. This wastes time.

On DFS channels the client has to listen for a Beacon or Probe Response before it probes itself. Normally Vocera clients always probe for the specific SSID we have programmed it for. But on DFS channels, to save that probing time, if we hear a Beacon supporting our SSID we will forego probing on that channel. If you hide the beacon we have to apply that extra 15ms for probing and dwelling on that DFS channel.”

To summarise what Andrew was saying there is that we should not be hiding the SSIDs as it can have a negative impact on client roaming & association.

Let’s now do some testing and see how secure it is to hide an SSID & what steps we have to do to be able to find what the hidden SSID name is – if that is even possible of course 😉

For our tests today I will be using my Mist AP41 – connected back to my Mist Cloud dashboard. The SSID we will be trying to find is called “Matts_Hidden_SSID”. I will also be using the WLAN-Pi & Wireshark to capture wireless packets.

Here is how my SSID is configured on My Mist dashboard – we can clearly see the SSID name and that I have selected to hide the SSID.

MiSt 
Monitor 
Ma 
O), Clients 
Access Points 
switches 
Location 
Analytics 
Netw•ork 
Organization 
WIA NINJAS 
< Matts 
Hidden 
SSID 
Matts Hidden 
Labels 
SSID 
Security 
@ WPA-2/PSK with passphrase 
O 
WPA-2/EAP (802.1 X) 
Apply to Access Points 
SSID 
Aps 
Isolation 
AP Labels 
Specific APS 
WLAN Status 
@ Enabled C) Disabled 
Hide 
D No Static IP Devices 
Radio Band 
@ 2.4G and 5G 
O 
2.4G 
Band Steering 
O Enable 
Client Inactivity 
Drop inactive clients after 
Geofence 
O 
Open Access 
More Options 
Fast Roaming 
@ Default 
VLAN 
@ Untagged O 
Guest Portal 
Tagged 
O 
O 
Dynamic 
O 
1800 
O 
O 
O 
seconds 
No portal (go directlyto internet) 
Custom guest portal 
Forward to external portal 
SSO with Identity Provider C) Requires custom firmware 
Bypass guest/external portal in case of exception 
Contact Mist for Firmware 
D Minimum client RSSI (2.4G) O 
D Minimum client RSSI (5G) O 
Block clients having RSSI below the minimum 
Data Rates 
O 
Compatible (allow all connections) 
@ No Legacy (2.4G, no 1 1b) 
O 
High Density (disable all lower rates) 
prohibit peer to peer communication 
Filtering (Wired to Wireless) 
Broadcast/Multicast 
Custom Forwarding 
Custom Forwarding to Etho POE 
SSID Scheduling 
O Enabled @ Disabled 
QoS Priority 
Override QoS 
AirWatch 
O Enabled @ Disabled 
O 
Custom Rates 
WiFi Protocols 
WiFi-6 @ Enabled O 
WLAN Rate Limit 
Cl Limit uplink to 10 
O Limit downlink to 20 
Disabled 
Mbps

Next, let’s take a look at what wireless channels my AP is using in the 5GHz band so I can configure my WLAN-Pi to capture on those channels.

MiSt 
Monitor 
Ma 
O), Clients 
Access Points 
switches 
Location 
Analytics 
Netw•ork 
Organization 
WIA NINJAS 
Radio Management 
-92 darn 
AVG. NOISE 
Distribution 
Current Radio Values 
Name 
FRI, 09:16 AM 
site 
Matt Starling Home 
AVG. # NEIGHBORS 
MAC Address 
2.4 GHz 
5 GHz 
Optimize now 
0.0 0 
AP DENSITY 
AVG. # CO CHANNEL NEIGHBORS 
No. Clients 
Status 
Connected 
Channel 
Channel 
108+1 12 
0.1 
AVG. # APS PER CHANNEL 
Channel Width 
40 MHz 
1.00 
CHANNEL DIST. SCORE 
5 GHz Enabled 
17 dBm 
Channel 
5 GHz Overridden 
Power

We can see in the above image that my AP is using a 40MHz wide channel & occupying channels 108 + 112. So we need to configure my WLAN-Pi to use those channels.

wlanpi@wlanpi: - 
as: w Ianpi 
Using keyboard—interactive authentication . 
Password : 
/ Ill I \ 
Welcome Co Debian Stretch with 
Armhian Linux 4 . I g. 66—sunxi64 
System load: 
Memory usage : 
CPU temp : 
Usage of / : 
0.00 0.00 0.04 
16 * of gg3MB 
330c 
of ISG 
syszem 
Up time: 
I g min 
.2s4.g.232 
sudo apt update 
s udo apt 
install 
Lasc login: Thu occ 3 2019 from 192.168.42.2 
wlanpi@wlanpi : —$ sudo iw wIanO sec channel 108 40MHz 
Usage : 
iw [options] dev sec channel 
[NOHT 1 HT40+lHT40-l 
SMHz 1 10MHz 1 80MHz 
Options : 
— — debug 
enable net link debugging 
wlanpi@wlanpi : —$ sudo iw WI ano sec channel 108 HT40+ 
wlanpi@wlanpi : —$

Now we have configured the WLAN-Pi to capture on those channels, I was ready to start capturing some packets.

Let’s take a look at some of the packets that were starting to come flooding in – I could see my other SSID “WiFi Ninjas” that I had not set to be hidden being broadcasted in the beacon frames but I could see that there was also another SSID coming from my Mist AP but we could not see the hidden SSID – still pretty secure at this point 😉 

*SSH remote capture 
File Edit View Go Capture 
651 
8a2.11 
Ila 
dam s.a 
802.11 
802. Ila 
dam 6.a 
802.11 
802. Ila 
dam s.a 
802.11 
802. Ila 
dam s.a 
802.11 
802. Ila 
dam s.a 
802.11 
802. Ila 
dam s.a 
802.11 
802. Ila 
dam s.a 
658 
802.11 
802. Ila 
dam s.a 
802.11 
802. Ila 
dam s.a 
802.11 
802. Ila 
dam s.a 
802.11 
802. Ila 
dam s.a 
802.11 
802. Ila 
dam s.a 
802.11 
802. Ila 
dam s.a 
802.11 
802. Ila 
dam s.a 
802.11 
802. Ila 
dam s.a 
802.11 
802. Ila 
dam s.a 
802.11 
802. Ila 
dam s.a 
802.11 
802. Ila 
dam s.a 
802.11 
802. Ila 
670 
802.11 
802. Ila 
Analyze Statistics Telephany 
Wireless Tools 
Help 
Apply a display filter 
Absolute Time 
Expr ession 
Spatial streams 
+ Management Fr ames 
Control Frames Data Frames 
Time as Formatted 
28.160416 
28.570037 
29.184500 
Delta Time 
a. 00BBB8 
a. 102371 
a. 000008 
a. 102480 
a. 102364 
a. 102382 
a. 000020 
a. 102493 
a. oooala 
a. 102333 
a. 102356 
a. 102367 
a. 000008 
a. 102484 
a. 102368 
Frequency 
R SSI 
-26 
- 26 
- 26 
- 28 
- 28 
- 26 
- 26 
- 28 
- 26 
- 26 
- 26 
- 28 
- 26 
- 26 
- 28 
- 28 
- 26 
- 26 
- 28 
-26 
TX Rate 
Data rate (M$s) 
Source 
Destination 
Broadcast 
Broadcast 
Broadcast 
Broadcast 
Broadcast 
Broadcast 
Broadcast 
Broadcast 
Broadcast 
Broadcast 
Broadcast 
Broadcast 
Broadcast 
Broadcast 
Broadcast 
Broadcast 
Broadcast 
Broadcast 
Broadcast 
Broadcast 
Protocol 
Length 
359 
362 
359 
362 
359 
362 
359 
362 
359 
362 
359 
362 
359 
362 
359 
362 
359 
362 
359 
362 
Colouring Rule Name 
Beacon 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Beacon 
MCS index I 
ss1D 
wiFi 
wiFi 
wiFi 
wiFi 
wiFi 
wiFi 
wiFi 
wiFi 
wiFi 
Bandnidth 
PHY type 
Tag 
652 28.262787 
653 28.262795 
654 28.365275 
655 28.365283 
656 28.467647 
657 28.467655 
659 28.570057 
660 28.67255a 
661 28.67256a 
662 28.774893 
663 28.774901 
664 28.877257 
665 28.877265 
666 28.979632 
667 28.97964a 
668 29.082124 
669 29.082132 
554a 
5540 
5540 
5540 
5540 
5540 
5540 
5540 
5540 
5540 
5540 
5540 
5540 
5540 
5540 
5540 
5540 
5540 
5540 
5540 
MHZ 
MHZ 
dam 
dam 
(2872 
6 Mist 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
79:32 
Ninjas 
Ninjas 
Ninjas 
Ninjas 
Ninjas 
Ninjas 
Ninjas 
Ninjas 
Ninjas 
Info 
Beacon 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Bea con 
Beacon 
frame, 
f rame 
f rame 
f rame 
f rame 
f rame 
f rame 
f rame 
f rame 
f rame 
f rame 
f rame 
f rame 
f rame 
f rame 
f rame 
f rame 
f rame 
f rame 
frame, 
su=3B11, 
SN=3a12, 
SN=3a13, 
SN=3a14, 
SN=3a15, 
SN=3a16, 
SN=3a17, 
SN=3a18, 
SN=3a19, 
sN=3a2a, 
SN=3a21, 
SN=3a22, 
SN=3a23, 
SN=3a24, 
SN=3a25, 
SN=3a26, 
SN=3a27, 
SN=3a28, 
SN=3a29, 
sN=3a3a, 
Frame 653: 
359 bytes 
on 
wire (2872 bits), 
359 bytes 
c a ptu red 
bits ) 
on 
Radiotap Header va, Length 32 
802. II radio information 
IEEE 8B2.II Beacon frame Flags: . 
IEEE 8a2.11 wireless LAN 
Fixed parameters (12 bytes) 
v Tagged parameters (287 bytes) 
ag: SSID parameter set: Boa Boa Boa Boa Boa Boa Boa Boa Boa Boa Boa 
Number: SSID arameter set a 
interface 
Boa Boa Boa Boa Boa Boa 
Tag Iength: 17 
Tag: Supported Rates 6(8), 9, 12(8), 
Tag Number: Supported Rates (I) 
Tag Iength: 8 
18, 
42 
17 
15 
al 
a2 
5e 
24(8), 
36 
2/ 
48, 
54 , 
Su p ported 
Su p ported 
Su p ported 
Su p ported 
Rates . 
Rates : 
Rates : 
Rates : 
Rates : 
• 6(8) (ax8c) 
9 (0x12) 
12(8) (0x98) 
(ax24) 
Su 
rted 
aza 
gala 
aa2a 
aaaa 
aasa 
aasa 
ana 
ana 
gaga 
aaaa 
aaca 
aada 
aaea 
a afa 
3122 
alsa 
3142 
alfa 
[Mbit/ sec) 
• •LG8 $ 
64 
al 
17 
7a 
14 
47 
04 
a2 
al 
32 
17 
al 
al 
al 
2f 
2a 
34 
35 
11 
28 
al 
88 
04 
ff 
dd 
15 
11 
al 
17 
74 
46 
al 
ff 
fa 
79 
17 
34 
57 
al 
32 
11 
04 
al 
ab 
a2 
al 
al 
17 
78 
04 
gf 
18 
24 
al 
02 
17 
64 
le 
al 
al 
16 
04 
27 
2a 
51 
le 
95 
2a 
bf 
00 
17 
ff 
72 
al 
al 
a2 
dd 
12 
17 
68 
2d 
04 
32 
18 
98 
34 
99 
23 
la 
42 
2a 
35 
24 
47 
al 
le 
a2 
04 
42 
43 
79 
48 
2a 
38 
17 
7f 
a2 
al 
32 
sa 
24 
al 
le 
84 
al 
ff 
al 
al 
62

How about if we filter on probe responses only? By using this Wireshark filter: wlan.fc.type_subtype == 0x0005

*SSH remote capture 
File Edit View Go 
152 
8a2.11 
8B2.11a 
dam 6.ø 
8ø2.11 
7øø 
8ø2.11 
8ß2. 
dam 6.ø 
7ß3 
8ø2.11 
dam 6.ø 
7ß5 
8ø2.11 
dam 6.ø 
833 
8ø2.11 
dam 6.ø 
936 
8ø2.11 
dam 6.ø 
964 
8ø2.11 
dam 6.ø 
975 
8ø2.11 
dam 6.ø 
978 
8ø2.11 
dam 6.ø 
98ø 
8ø2.11 
dam 6.ø 
:49.4øgø56 44.78ø149 
8ø2.11 
dam 6.ø 
:49.418688 44.789781 
8ø2.11 
dam 6.ø 
44.8ø4283 
8ø2.11 
dam 6.ø 
:49.443324 44.814417 
8ø2.11 
dam 6.ø 
8ø2.11 
dam 6.ø 
2469 
8ø2.11 
dam 6.ø 
8ø2.11 
dam 6.ø 
2477 
8ø2.11 
6.ø 
8m.11 
8ß2. 
Capture 
= ox0005 
Analyze Statistics Telephony 
Wireless Tools 
Help 
"Ian fc. type_subtype 
Absolute Time 
+ Management Fr ames 
Control Frames 
Da ta Frames 
Time as Formatted 
7.564445 
Delta Time 
a. øøøøøø 
13.7ø56ß2 
8.837292 
ø.ø16123 
ø.ø1ø13ø 
2.9435ø4 
1.64ø69ø 
ø.4356ß3 
ø.øøgsøg 
ø.ø14625 
ø.ø1ß247 
g. 592379 
ø.øøg632 
ø.ø145ß2 
ø.ø1ø134 
4.1ø4218 
1.578936 
ø.ø13265 
ø.ø14984 
a. ø1ß264 
Frequency 
R SSI 
-26 
- 28 
- 26 
- 28 
- 26 
- 26 
- 26 
- 26 
- 26 
- 28 
- 26 
- 26 
- 26 
- 26 
- 26 
- 28 
- 26 
- 26 
- 26 
-28 
TX Rate 
Data rate (Mb's) 
Source 
Destnaton 
Protocol 
Length 
356 
356 
353 
353 
353 
353 
356 
356 
356 
356 
356 
356 
356 
356 
356 
356 
353 
353 
353 
353 
Colouring Rule Name 
MCS index I 
Expr ession 
Spatial streams 
Tag 
5øø 21.27øø47 
2396 48.918635 
1894 ø6 
1899 ø6 
19ß2 ø6 
2474 
2479 
Frame 
: 52 
: 52 
: 52 
: 52 
3ø .1ß7339 
3ø .123462 
3ø.133592 
33. ø77øg6 
34.717786 
35.153389 
35.162898 
35.177523 
35.18777ø 
% .497571 
5ø.51ß836 
5ø.52582ø 
% .536ß84 
554a 
554ø 
554ø 
554ø 
554ø 
554ø 
554ø 
554ø 
554ø 
554ø 
554ø 
554ø 
554ø 
554ø 
554ø 
554ø 
554ø 
554ø 
554ø 
554B 
MHz 
MHz 
MHz 
MHz 
MHz 
MHz 
MHz 
MHz 
MHz 
MHz 
MHz 
MHz 
MHz 
MHz 
MHz 
MHz 
d 8m 
dam 
d 8m 
(2824 
54 , 
6 Mist 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
Mist 
6 
6 Mist 
Matt 
Matt 
Matt 
Matt 
Matt 
Matt 
Matt 
Matt 
Matt 
Matt 
Matt 
Matt 
Matt 
Matt 
Matt 
Matt 
Matt 
Le novo 
Len ovo 
iPhoneX 
iPhoneX 
iPhoneX 
iPhoneX 
Len ovo 
iPhoneX 
iPhoneX 
iPhoneX 
iPhoneX 
iPhoneX 
iPhoneX 
iPhoneX 
iPhoneX 
Len ovo 
iPhoneX 
iPhoneX 
iPhoneX 
iPhoneX 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Response 
Response 
Response 
Response 
Response 
Response 
Response 
Response 
Response 
Response 
Response 
Response 
Response 
Response 
Response 
Response 
Response 
Response 
Response 
Response 
ss1D 
WiFi Ninjas 
Matts Hidden 
Matts Hidden 
Matts Hidden 
Matts Hidden 
wiFi 
wiFi 
wiFi 
wiFi 
wiFi 
wiFi 
wiFi 
wiFi 
wiFi 
wiFi 
Matts 
Matts 
Matts 
Matts 
Ninjas 
Ninjas 
Ninjas 
Ninjas 
Ninjas 
Ninjas 
Ninjas 
Ninjas 
Ninjas 
Ninjas 
Hidden 
Hidden 
Hidden 
Hidden 
Bandwidth 
SSID 
SSID 
SSID 
SSID 
SSID 
SSID 
SSID 
SSID 
PHY type 
8ß2 
8ß2 
8ß2 
8ß2 
8ß2 
8ß2 
8ß2 
8ß2 
8ß2 
8ß2 
8ß2 
8ß2 
8ß2 
8ß2 
8ß2 
8ß2 
8ß2 
Info 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Probe 
Response, 
Response, 
Response, 
Response, 
Response, 
Response, 
Response, 
Response, 
Response, 
Response, 
Response, 
Response, 
Response, 
Response, 
Response, 
Response, 
Response, 
Response, 
Response, 
Response, 
su=2596, 
SN=287ø, 
SN=3ø51, 
SN=3ß52, 
SN=3113, 
SN=3166, 
SN=3175, 
SN=3178, 
SN=3179, 
SN=318ø, 
SN=3426, 
SN=3427, 
SN=3428, 
SN=3429, 
SN=3549, 
SN=3582, 
SN=3583, 
SN=3584, 
SN=3585 , 
FN=ø 
FN=ø 
FN=ø 
FN=ø 
FN=ø 
FN=ø 
FN=ø 
FN=ø 
FN=ø 
FN=ø 
FN=ø 
FN=ø 
FN=ø 
FN=ø 
FN=ø 
FN=ø 
FN=ø 
353 bytes 
on 
wire (2824 bits), 
353 bytes 
ca red 
bits ) 
on 
interface 
Radiotap Header vø, Length 32 
8m.11 radio information 
IEEE 8e2.11 Probe Res rise Flags: . 
IEEE 8e2.11 wireless LAN 
Fixed parameters (12 bytes) 
SSID arameter set: Matts Hidden SSID 
Tag Number: SSID parameter set (e) 
Tag length: 17 
SSID: Matts Hidden SSID 
Tag: 
Tag: 
Tag: 
Tag: 
Tag: 
Tag: 
Tag: 
supported Rates 6(a), 9, 12(a), 18, 24(a), 36, 48, 
DS Parameter set: Current Channel: 
CMbit/ sec) 
Country Information: Country Code 63, Environment Any 
Power Constraint: 
T PC Report Transmit Power: 21, Link Margin. 
RSN Information 
Q8SS Load Element 
: measurement Pilot 
8ø2.11e ccA Version 
Transmission 
aaaa 
aala 
aaaa 
aasa 
eese 
aasa 
aa7a 
ane 
aaga 
aaaa 
aaba 
aaca 
aada 
aaea 
a afa 
aløa 
a12a 
a13a 
a14a 
else 
64 
65 
17 
78 
ø4 
6e 
17 
64 
16 
ø4 
27 
213 
11 
95 
213 
bf 
17 
15 
11 
53 
dd 
17 
68 
2d 
ø4 
32 
18 
be 
11 
49 
34 
23 
la 
42 
65 
44 
ø4 
42 
43 
13 
61 
17 
15 
f2 
213 
58 
74 
38 
17 
øø 
7f 
aa 
øø 
74 
84 
ff 
ff 
62 
73 
12 
17 
713 
14 
47 
ff 
ø4 
32 
5b 
98 
al 
ff 
2f 
213 
35 
48 
24 
88 
04 
ff 
aa 
dd 
69 
17 
74 
46 
ff 
79 
64 
48 
ce 
32 
64 
le 
ac 
•Ma tts Hidd 
en SSID 
• acn

Ooooh not quite so secure anymore is hiding the SSID? 🙂 We can quite clearly see in the SSID parameters the SSID name now! This didn’t take too much effort either did it? There are a few requirements that we need to meet though to be able to see the probe response.

I associated to the SSID whilst capturing the packets but if a client does not associate during your packet capture you won’t see the probe response so you might have to send a de-auth or something like that but that’s for another blog 😉

To summarise then, hiding the SSID is not only not secure, but it can also have a negative impact on roaming – next time I go to a customer site that has the SSID hidden, I will be sending them to this blog 😀

If you are new to Wireshark we did another blog last year on some useful filters which can be found here: https://wifininjas.net/index.php/2019/05/29/wn-blog-002-wireshark-filters/

I also have set up my own custom profiles, using a colour profile, my own custom columns & have added known devices MAC address to name profile so that’s how you can see “Matt_iPhoneX” instead of my MAC address. If you want any help with how to set up your Wireshark like this feel free to give us a shout and we will help you.

Hope you enjoyed the blog post 🙂

x

WN Podcast 027 – Channel vs Spectrum Utilisation & Ghost Frames with Ben Miller – Part 1

Welcome to our new WiFi Ninjas Podcast episode! We are mega privileged to have Ben Miller on our show today, where we’re discussing channel utilisation vs spectrum utilisation vs duty cycle, ghost frames and potential impact of setting minimum data rates too high.

Podcast frames below.

Channel Utilization

  • What is it
  • Does lower % always mean a better RF?
  • Good vs bad channel utilisation
  • Does channel bonding affect channel utilization?
  • Shall we rely on channel utilization for tshooting?

Internet’s favourite: channel utilization vs spectrum utilization vs duty cycle

  • Real Time FFT [dBm]
    • Current spectrum utilisation
  • Spectrum Utilisation [%] = FFT Duty Cycle [%]
    • Spectrum utilisation over a short time period
  • Waterfall = Swept Spectrogram
    • RF Power over time

Tools

  • Tools of choice for channel / spectrum utilisation
  • Protocol analysis

And a very helpful screenshot from Joel’s presentation!

Tons of love x,

WiFi Ninjas

WN Blog 023 – Indoor RTLS with WiFi and BLE – Deep Dive

Hey! We’ve been busy lately testing some available RTLS solutions from a few different major wireless players and fell absolutely in love with the topic to the point, where we shake from overexcitement when thinking or talking about it 😊

This summarises how we feel:

Excited Ninjas

Steve Jobs once said, “people don’t know what they want until you show it to them”. He was right.

20 years ago, WiFi was “a nice to have”. 18 years ago, paper maps were at peak of their popularity, until GPS receivers got small enough to be put in the handheld devices. Is anyone not using Google Maps on their mobile? 15 years ago, not many people felt they needed a wireless headset, until Bluetooth was introduced. 7 years ago, NFC was a niche. Today, most of us use contactless payments using cards, phones or watches.

Indoor wireless RTLS is at the early adoption stage. Technology is available, we just need to make it more interesting and rewarding to use.

Satellite-based location positioning services are not always practical indoors. We could offer wireless RTLS functionality based on WiFi, BLE or soon, possibly, Ultra Wide Band (UWB). Modern smartphones have both WiFi and BLE radios built in. Additionally, new iPhones support UWB. Wireless vendors leverage cell of origin, trilateration, triangulation, angle of arrival, proximity and more with WiFi, BLE, UWB, GPS, NFC, mobile networks or any combination of those methods and technologies, offering different levels of accuracy and functionality. RTLS market is growing fast – according to Bluetooth.com, 1.7 billion devices will use indoor BLE RTLS by 2023, translating to even 500% increase in BLE RTLS implementations in some verticals!

So, what do we need to see the RTLS market explosion? We’ll be speculating, but our hearts tell us that indoor RTLS needs solve real challenges like indoor wayfinding or call for help and simply be more interesting not only for the business’ IT and marketing, but for everyone. We also need more skilled wireless professionals willing to embrace broader wireless technologies and emerging use-cases, like BLE and RTLS, on top of WiFi design, security and analysis skills, while not forgetting about programmability elements.

But enough of the babbling, let’s cut straight to the juicy content! Here is what we will cover in this blog:

Blog Structure:

  • Theory
    • RTLS Technologies
      • WiFi
      • BLE
    • RTLS Tracking Methods
      • Cell of Origin
      • WiFi Trilateration
      • WiFi Angle of Arrival
      • Mist vBLE Arrays and Probability Surfaces
    • RTLS Functionality
      • Presence & Analytics
      • Location
      • Engagement & Actions
    • RTLS RF Design
      • Design Tips
      • Examples
  • Demo Time!
    • Test Environment
    • WiFi Trilateration
    • WiFi Hyperlocation
    • Mist BLE Arrays
  • Location API
    • Challenge 1 (Meraki Location API): Do You Need RTLS RF Design for WiFi Location & Presence Analytics?
    • Challenge 2 (Cisco CMX Location API): Can You Leverage Enterprise Messaging Solutions to Benefit from Indoor RTLS?
  • Gotchas

Theory

RTLS Technologies

WiFi

  • Most popular tracking technology, as it also provides access to the network.
  • Can offer different levels of location accuracy, depending on the tracking method used (cell of origin, Trilateration, AoA, etc.).
  • Multiple element antenna arrays can substantially improve location accuracy – Cisco Hyperlocation is a great example.
  • Can be used to track associated and unassociated probing clients.
  • Associated is proffered, since stations are chattier (with their screen on at least).
  • Normally, WiFi based RTLS is based on RSSI/Location information from probe requests only, as probing client normally sends requests on multiple channels, and is therefore seen by multiple APs. This, however, results in very infrequent location calculation ranging from 10 seconds to 5 minutes (according to Cisco) but our own tests shown that modern unassociated stations don’t probe at all. Note, that happy (high RSSI/SNR) associated client probably won’t probe at all, and therefore its location could not be calculated with better accuracy than ‘cell of origin’ (see below) until its re-associating (roaming). Cisco has addressed this challenge with a feature called ‘FastLocate’. It uses a dedicated built in antenna array (4800) or a halo module (3600 / 3700) to scan multiple channels and get RSSI values from clients’ data packets across multiple channels without sacrificing performance of clients serving radio by going off-channel to do just that.
  • To track unassociated station, two conditions must be met: station must not use MAC randomisation (they normally do) and it must be probing. Not all unassociated stations are probing.
  • Client apps are optional and can be used to increase tracking accuracy, location calculation frequency and add engage or actions element. Note, that using mobile SDK in WiFi-based RTLS is challenging, as the application normally has no way of knowing the MAC address of the device it sits on.
  • On top of location analytics, WiFi is normally used to provide presence analytics (more info below).

BLE/vBLE

  • BLE relies on physical beacons, often battery operated; vBLE moves beacon role from BLE beacons to APs .
  • BLE is often used to offer proximity-triggered actions and vBLE can be used for location analytics on top or instead of WiFi
  • Client app is required for fast (sub-second with Mist) and accurate (1-3 metres) BLE/vBLE. Station listens to the BLE transmissions coming from the BLE AP (BLE APs are transmitting). Mobiles listens to all (directional with Mist) beams from all BLE APs in the area and sends RSSI values with beams ID to the server/cloud, where location engine will calculate station XY coordinates and send them to the station. Note, that mobile station can send that information using mobile network; device doesn’t have to be associated using WiFi for BLE RTLS to work.
  • Clients with no apps will be treated / located as BLE tags / assets. In this scenario, client is sending BLE transmissions to BLE APs (BLE APs are receiving). Mist uses its directional arrays to pinpoint asset tag transmission location with mind-blowing accuracy, all other vendors will typically rely on tag proximity to BLE radio built into the AP / anchor.
  • More BLE beams heard = better accuracy.
  • More element antenna arrays can substantially improve location accuracy – Mist BLE Arrays are a great example.
  • BLE seems to be very well suited for RTLS, as it doesn’t travel as far as WiFi, therefore offering theoretically better accuracy than WiFi. Note that both BLE (2.4GHz) and WiFi (2.4 or 5GHz) are using the same frequency (actually WiFi can even sit on a higher frequency with 5GHz, and therefore theoretically not travel as far as 2.4GHz) but BLE (Bluetooth LOW Energy) uses significantly lower power levels to operate.
  • XY coordinates are calculated for vBLE and are typically not calculated for BLE (proximity used instead, but there are exceptions to that rule!).

RTLS Tracking Methods

Cell of Origin

  • Simplest location technique.
  • Typically leveraging location of AP that clients are connected to but might be the AP that sees the probing or associated client with strongest RSSI.
  • Great for simple zone-wide accuracy.
  • Requires at least 1 AP per zone and careful RF design.
  • XY coordinates are not calculated.

WiFi Trilateration

  • Distance (lateration) based location technique using RSSI in 802.11, measured by either STA or AP/Sensor.
  • Adds more accuracy within a zone (tested with Meraki and Cisco) – 2-3m labbed (in perfect environment), 5-7m marketed, 7-10m real.
  • Real accuracy is lower than labbed and marketed, as it’s difficult to have LOS between 3x AP and STA everywhere. Also, cross floor leakage, atriums, walls and signal deterioration – all affect accuracy.
  • Note, that we normally use Trilateration in WiFi RTLS and it’s often confused with Triangulation.
  • Trilateration: requires 3 APs with known distance between them; uses RSSI (distance, lateration) to calculate intersection (client XY coordinates) between three circles (as shown above).
  • Triangulation: requires at least 2 APs with known distance between them; uses this baseline and multiple-element antenna arrays (that we typically don’t have in WiFi APs, with Hyperlocation being exception here) to calculate arriving signal angles to find XY coordinates of the client (as shown below).
  • XY coordinates are calculated.

WiFi Angle of Arrival

  • AoA (angulation) location technique using angle of incidence at which STA signals arrive at the receiving sensors.
  • Requires at least 2 APs / sensors / modules (at least 3 recommended for better accuracy).
  • Note, that AoA with three APs is in fact a tri-angulation.
  • Requires multiple element antenna arrays or antenna mechanical agility.
  • Cisco Hyperlocation uses a mix of WiFi Trilateration (RSSI), WiFi AoA and BLE
  • Cisco 3600/3700 Hyperlocation module has 32-element antenna array
  • Cisco 4800 built-in Hyperlocation has 16-element antenna array
  • According to Cisco, Hyperlocation module used with older APs and 4800 built-in array offers same levels of accuracy
  • AoA is more accurate than Trilateration (tested with Cisco Hyperlocation) – 1-3m labbed, 1-3m marketed, 1-5m real
  • Real accuracy is lower than labbed and marketed for similar reasons as discussed for Trilateration. Additionally, AoA requires extremely careful mounting and calibrating APs positions in maps services (height, azimuth).
  • XY coordinates are calculated.

Mist vBLE Array and Probability Surfaces

•aoo 
BEAMS 1 HEAR 
CLOUD
  • Unique to Mist.
  • Every Mist AP has 16 Directional Antennae Bluetooth Array – 8 reflectors and 8 directional antennas.
3-
  • Uses BLE concept, where Mist SDK on the mobile device is listening the beacons from the beams and sends the RSSI and device sensor information back to the Mist cloud through either WiFi or cellular. Mist also supports assets tracking.
  • Mist is not using standard Trilateration, but ‘Probability Surfaces’, where combination of listening to directed AP Beams and machine learning constantly evaluating Path Loss Formula (PLF) per device to calculate station location.
  • Extremely good accuracy: 1-2m labbed, 1-3m marketed, 1-3m real (mind blasting).
  • XY coordinates are calculated.

RTLS Functionality

Presence & Analytics

  • Typically relies on WiFi
  • Provides network level stats, such as:
    • Current visitors: devices count, dwell time, gender and age split, device types present
    • Avg. visit distribution: time of day, day of week, new vs repeat, duration, gender, age
    • Bounce rate (stayed vs bounced; enter and stay for longer than 3 min)
    • Conversion rate (converted vs passed; clients that passed the venue but didn’t enter)
    • Visitors engagement ratio (stayed connected over specified time)
  • We can leverage social media, mobile apps or splashpage forms to onboard WiFi clients and grab users’ details (be careful with GDPR!)

Location

  • Typically relies on WiFi, BLE/vBLE, GPS, Mobile, UWB, Ultrasounds
  • Provides zone/location level insight, such as:
    • Zone analytics & zone paths
    • Location on the map (dashboard or client app – blue dot)
  • Some location features can be leveraged directly through specific web user interfaces (CMX, Purple, Mist or Meraki Dashboards) but it’s generally more powerful and useful to get, manipulate, filter and visualise location data using API – output can be crafted to any business needs. Typically, the following attributes can be grabbed (or subscribed to if you’re using Mist Webhooks) via location API:
    • Client XY coordinates
    • Zone entry and exit events
    • Virtual beacon (Mist), beacon proximity (everyone else)
    • Raw tracked client’s data: RSSI, time, MAC, etc.
  • Zone analytics importance
    • Zone analytics is extremely valuable for businesses, especially retail, to understand impact of their actions (new displays, stands, brands, promotions, etc.) on paths users are taking and stats for each zone (dwell time, count, etc.)
  • CMX GUI – Zone Paths example:
A screenshot of a video game

Description automatically generated
  • Purple GUI Zone – Paths example:

Engagement & Actions

  • Uses Presence, Analytics and Location insight to create personalised user experience
  • Example 1:
    • Returning user that has opted in and has previously bought a pizza (tagged with ‘pizza lover’ tag) entering 1st Floor dining area after 3.15pm will get a 50% off offer delivered via App Push Notification (This would also require some CRM integration)
  • Example 2:
    • When user is in a proximity to a BLE beacon or a vBLE area, open wifininjas.net website in a loyalty app integrated browser
  • Example 3:
    • Zone A (sports cars) will use different Captive Portal than Zone B (donuts)
  • Example 4:
    • User uses app for indoor wayfinding – where am I and how can I find client X reception and how to get there?
  • Example 5:
    • User requires assistance in the shop (looking for a certain size of shoes to try); user can use the mobile app to ‘call for help’ and grab attention of staff; staff knows where to find a client calling for assistance as they also use location-aware mobile app

RTLS RF Design

Design Tips

  • APs should be located around zone perimeters to create a convex hull
  • Each client should be within convex hull of at least 3 APs with solid RSSI (-65dBm is OK)
    • It’s ideal for all tracking methods, even though AoA and Mist BLE require just 2 APs to work; still, more APs give better accuracy
  • Ideally, use dedicated radio or module for RTLS to maximise location scanning performance and minimise performance impact to client-serving radios
  • Ensure LOS is maintained between APs and clients (AP behind ceiling tiles is a no-no)
  • Don’t mount APs too high! Not more than 4.5m is OK
  • Validate secondary and tertiary signal strength in your favourite survey tool
  • Cisco specific:
    • Enter thick walls into Prime and ‘Enable OW (Outer Walls) Location’ in CMX to use it for calculation
    • Always use FastLocate functionality (leverage client data packets and probes to calculate location)

Examples

Note, that number of APs has tripled! Generally speaking, if the design is good for RTLS, it’s also good for any other use case (data, voice, most high-density scenarios, etc.). Sometimes some WiFi radios need to be put into non-client-serving mode as too much WiFi can be damaging to the performance of the network (topic for a different discussion).

Demo Time!

Test Environment

  • All APs were positioned quite nicely, LOS with a client maintained everywhere within a convex hull making it slightly unrealistically great (normally possible in lab environment only).
  • Laser tool was used to measure height of the APs.

WiFi Trilateration

Components

  • Tested with traditional Cisco and Cisco Meraki
  • We have deemed Meraki Dashboard unusable for RTLS (shows only point of association and overlays all clients from all floors on every floor map) so we’ve also used Purple as an RTLS Dashboard overlay with Meraki testing
  • Prime (or DNAC) is needed to create maps, place APs, set their height, azimuth, specify zones, inclusion & exclusion areas, walls, rails (wayfinding paths)
  • Theoretically CMX is not required if Hyperlocation is not in use and we could connect AireOS or C9800 WLC directly to the DNAS. Unfortunately, we couldn’t do it as:
    • Direct connection requires DigiCert CA Root Certificate that we don’t have on the WLC
    • C9800 code version 16.12.2 is required, but 16.12.1 was newest publicly available at time of testing

Accuracy

  • Theoretical expected accuracy of 5-7m
  • Better than expected accuracy when inside the convex hull (2.55m average; 2.69m 90% error distance)
  • Still good accuracy when on the edge of the convex hull (2.57m average; 3.38m 90% error distance)
  • Location Computation Frequency of 11-15 seconds (with screen on, associated and active device) is not enough to offer blue dot experience but it’s still good for basic RTLS functionality like simple, static wayfinding or zone analytics with zones sized accordingly to solution accuracy

Cisco Hyperlocation

Components

  • Prime or DNAC still needed for maps
  • Overall complicated setup, prone to user errors and bugs
  • CMX on-prem required to do all data crunching – it’s quite a lot of data to go through!
  • DNAS can be used to access presence, analytics and location data in the cloud if required
  • Note, that at the time of testing DNAS was lagging behind CMX and was generally slower and less accurate than CMX!
  • DNAS can also be used for many more things, like integration with 3rd party tools or Open Roaming integration (amazing idea that we feel will change the way we use public WiFi – let’s leave it for a future blog 😉)

Accuracy

  • Theoretical expected accuracy of 1-3m
  • Totally brain smashing accuracy inside the convex hull (0.73m average; 0.73m 90% error distance) for a non-moving client
  • Good accuracy at the edge of the convex hull (1.78m average; 2.03m 90% error distance) for a non-moving client
  • Note, that accuracy of mobile clients will depend on their speed of movement and since location computation frequency is 2.3-2.4 seconds at best, the distance travelled within that timeframe will be typically added to the calculated location error distance

Demo

Let’s look at the video showing CMX app, CMX Dashboard and Matt walking around my house 😉

  • Accuracy is generally really good!
  • Blue dot location update (location calculation frequency) of 2-3 seconds is not bad and should be enough for most indoor RTLS use cases.
  • We didn’t draw rails (wayfinding paths) in Prime so what we’ve seen here is raw XY calculations displayed on the map. Rails around the path Matt’s taken would snap him into it, making blue dot appear more accurate.
  • CMX has great zone path visualisations built in and it’s generally a rarity (Purple also has it built in and it’s as good; note that not everyone will leverage GUI-based zone paths analytics since we can use API and visualise it ourselves and integrate it with existing tools but it requires clearly defined requirements and solid skills and effort).

Mist: vBLE Array

Components

  • Yup, that’s it 😉 Class leading simplicity. We’ve had a lab running by lunchtime and never had a chance to play with Mist before!
  • All maps management, wayfinding paths, beacons and zones done easily in the Dash.

Accuracy

  • Less than 1m inside the convex hull.
  • Reliable sub second Location Computation Frequency when used with an app, making it difficult for other major WiFi vendors to compete with.

Demo

The video screams million words! Let’s take a look 😊

  • Absolutely mind-bending accuracy with quickest location computation frequency we’ve seen to date in indoor RTLS space!
  • It is expected to still use WiFi to get network-wide presence and analytics stats, despite using BLE for location.
  • Mobile app is required for the proper BLE solution to work (might not be a bad thing, since mobile app is required anyway to get the most of any indoor RTLS solution, despite the technology used).
  • Mist has no zone path visualisations built in (we only have basic zone analytics) – it’s expected to leverage API to access / visualise this data.

Accuracy Summary

Below is a quick summary showing results of our tests for different indoor RTLS solutions!

Location API integration with existing infrastructure – two examples!

Meraki API – Cell of Origin Example

Background

We have recently worked on project for a beautiful, listed retail store in London, where following a very successful design and implementation of Meraki data WiFi network in the store, retail RTLS topic has emerged. With RF design crafted for data, we have faced a very real challenge – would the existing placement, type and number of APs be useful for indoor Real Time Location Services with a zone-level accuracy?What would be the challenges, limitations and reasonable expectations in terms of RTLS usage and accuracy? Could Meraki API help achieve goals set by the business?

Challenges

RTLS was not in the original scope and, combined with a store physical environment, we have faced some challenges:

  • RF Design: the network was designed with data in mind. We didn’t have APs placed on the outside coverage zones’ perimeters, had just 1 or 2 APs per zone in most areas and proved with a detailed WiFi survey/assessment that zone accuracy leveraging WiFi trilateration should not be expected.
  • Physical Environment: the building was listed, APs/antennas mounting options limited, walls and ceiling mostly wooden, with very low attenuation. All three sections (east, west, central) had big atriums contributing to cross-floor RF leakage strongly. Building had 6 levels.
  • Vendor Choice: we had Cisco Meraki and Purple already in place. Purple leverages Meraki API and uses Meraki pre-calculated XY coordinates (this can’t be changed) to display users’ location on the map. With data design, we didn’t have enough APs per zone to rely on the Meraki XY coordinates. Trilateration requires min. 3 APs in a zone to work reliably. Normally, we would have just one best AP (strongest RSSI) in every zone, with additional two APs needed for trilateration being located in adjacent zones or even a floor or two away! This has contributed to wildly inaccurate location readings in Purple (approx. 22m 90% error distance, often on a wrong floor) and could not be relied on. Note, that network-wide WiFi-based Presence & Analytics stats were perfectly reliable.

Floor diagrams below show the difference in RF Design for Data (what we have) vs RF Design for RTLS (what we would need for WiFi Trilateration to work):

Expectations

Based on the additional very detailed survey (more than 100 test locations across multiple floors with 3 different device types: flagship Windows 10 laptop, Android phone and iPhone), where we temporarily installed several new APs on tripods, we concluded that achieving satisfactory and reliable zone-location accuracy  (10m 90% error distance) using WiFi trilateration would require to approximately double the number of APs. The business has decided not to install additional APs and knowing that a mixture of Meraki and Purple could not offer reliable location insights and that WiFi trilateration would not be practical to use at all (because of the design, regardless of a vendor), we looked for alternative solutions and new success criteria were defined:

  • Location analytics with zone accuracy was the new goal; access to zone-based stats & clients’ paths deemed critical.
  • Zone sizes were increased; sometimes a zone would be as big as a 30x20m open space, sometimes as small as 8x8m room.
  • Still use Purple for presence & analytics, guest splash page & social media integration.

Solution

We have gathered some facts: data & voice performance over WiFi, capacity, coverage and roaming were all rock solid across all WLANs (MAB/CWA for guests and EAP-TLS machine auth for corp) and for all test devices (company issued laptops, major OSes, newer and older phones). High density areas, like ground floor entrance hall, could get very busy during holiday periods (200+ associated devices in a small 15x20m area) and were covered by three high-gain dual-band sector antennas. 5GHz was almost free of channel contention with careful APs placement around atriums and use of properly tweaked RF Profiles: 20MHz channels width, limited max and min Tx power, disabled data rates of 11Mbps and lower. 2.4GHz was tweaked even more, with several APs having their radios off and max Tx power set to the level, where RSSI was generally lower on 2.4GHz than on 5GHz throughout the store and only OFDM rates were allowed. 2.4GHz was still considered best effort. Presence & analytics with Purple was spotless.

Switching focus to location zone analytics, we have confirmed with a detailed post-deployment survey, that our test clients were reliably associating with APs installed in the zones they were in. WiFi scans from unassociated devices taken in multiple spots in each zone revealed that we could use strongest RSSI reading from one best AP to accurately pinpoint the probing or associated device to the zone it was in. We concluded that we could potentially leverage two attributes to correlate WiFi devices with their current zones:

  • Associated devices only: use MAC address of the AP the device is associated with.
  • Associated OR unassociated probing devices: use MAC address of the AP that reports probing or associated device with strongest RSSI.

Two things to note:

  • WiFi MAC randomisation makes it impossible to track unassociated devices that use it.
  • New mobile platforms battery saving modes make those devices very quiet – they often won’t probe at all.

To further simplify our zone analytics calculations, we have decided to use just one attribute moving forward – MAC address of the AP that reports the probing or associated devices with strongest RSSI.

We have discovered that it is possible to get the RSSI attribute for every client seen by all near APs with Meraki API location data. Readings are provided every minute and contain RSSI values covering last 60 seconds. While it’s not very fast and could not be used for a blue dot experience, it is enough for our use case – historical view of zone paths and analytics.

Using strongest RSSI proved to be 95% accurate across entire building and 100+ test spots when correlating user (reporting AP) location with a zone.

Raw Data from Meraki API – note ap_mac, seen_time, client_mac and RSSI

As we know exactly which zone all the APs are installed on, we could easily generate reports showing clients paths with zone accuracy, time spent in each zone, number of clients per zone, etc. without relying on wrongly pre-calculated Meraki XY coordinates.

To automate the zone paths visualisation and zone analytics, client’s software development team has created a tool to do just that. At this point, imagination was the limit.

Conclusion

Sometimes we are limited by a solution functionality when trying to meet client’s requirements. In our example, Purple could only use Meraki pre-calculated XY coordinates and it was not practical or accurate enough (even for a zone-wide accuracy) to use with a data / voice RF design. Let’s answer our initial question. Do You Need RTLS RF Design for WiFi Location, Presence & Analytics? Short answer is “no” for presence & analytics and “it depends” for location. Presence & analytics provide us with network-wide stats, without the location awareness and therefore will not require RTLS design. Location, however, requires very careful RF design to provide different levels of accuracy. With a solid data RF design, where association and roaming trends are reliably predictable, we could expect solid zone-wide accuracy. Anything more accurate (trilateration, Hyperlocation, vBLE) would require more APs, detailed survey, RTLS RF design, careful placement of APs/antennas and pedantic maps services configuration with spotless APs positions, height and azimuth set.

Cisco CMX API – Location Analytics integration with WebEx Teams Chatbot Example

Background

At Natilik, we’re currently in the process of upgrading our showcase with Cisco DNA. The plan is to have full SDA Fabric, C9800-based Fabric Wireless, proper RF design with Cisco 4800 APs, CMX and DNAS in one part of the office and a mixture of AP43 with BT11 in the other part. We’d love to not only showcase Cisco Hyperlocation and Mist BLE Arrays in action, but also leverage the tech to offer indoor wayfinding with turn by turn navigation and onboard guests using Hotspot 2.0 (called Open Roaming by Cisco) for our visitors WiFi.

As of today, we don’t have the new showcase fully running yet, so all we have to play with is ‘standard’ corporate WiFi design for Voice and Data.

The above shows one out of the two floors we occupy. With current design, all we can use is Cell of Origin and, around reception, WiFi Trilateration. And that’s it. Location Calculation Frequency of 11-15 seconds is not enough to offer blue dot experience, but we thought it could still be good enough to solve some wayfinding challenges!

Challenge

We have Cisco AireOS Wireless with CMX, Cisco WebEx Teams and everyone has a corporate phone enrolled with Meraki MDM.

We would love to use the kit we have today to locate a colleague, zone or a meeting room by asking WebEx Teams chatbot about the location of person/location we’re after without the need to install the mobile application, as we can’t have a turn-by-turn indoor navigation just yet anyway.

Let’s imagine that Mac wants to find Matt (yeah, we don’t hold our hands all the time and sometimes attend different meetings on different floors, lol). How do I do it? How would WebEx Teams chatbot know about my or Matt’s location? How could it show or tell me how to find him? Is it really that helpful with approximately 10-12m 90% error distance accuracy? Can we still draw an indoor map showing where should Mac go to find Matt?

Solution

First, we had to set realistic expectations. We shouldn’t expect the solution to pinpoint user to his or her desk knowing, that calculated user location has 10-12m accuracy. Instead, we have decided to use zones that are big enough to account for that location accuracy.

Here are the zones we’ve created, ensuring that each zone has at least one AP. We’ve also considered expected AP association ensuring it all makes sense:

Now, we need to figure out what happens when Mac is asking WebEx Teams chatbot about Matt’s location.

Wait, what is a chatbot? Good question! Most modern enterprise messaging solutions allow to create custom chatbots with custom functionality. We are fortunate enough to have a proper coding nerd in our ranks, Darren, that finds coding chatbots as easy as you probably find putting your socks on. Darren has created NatBot (I wonder where the name comes from!), that can translate natural language with certain key words to specific actions.

To make it all fly, we’ll leverage Cisco CMX Location API, Cisco Meraki MDM API and a cloud map service (i.e. Mapwize) to visualise the results.

Finally, let’s look at detailed steps that are happening in the background when Mac is looking for Matt 😊

  • Mac Deryng asks NatBot via WebEx Teams: “Where is Matt Starling”?
  • NatBot notes who is asking and who is he/she looking for
    • Mac Deryng is asking
    • He’s looking for Matt Starling
  • Find correlation between names and corporate iPhones MAC addresses
    • NatBot leverages Meraki MDM API to find MAC address of Mac’s phone (MDM returns MAC address)
    • NatBot leverages Meraki MDM API to find MAC address of Matt’s phone (MDM returns MAC address)
  • Find location of MAC address on the map and correlate it with a zone overlaid on the map
    • NatBot leverages Cisco CMX Location API to find location / zone that Mac is in (CMX returns zone name)
    • NatBot leverages Cisco CMX Location API to find location / zone that Matt is in (CMX returns zone name)
  • Show results for Mac
    • NatBot displays zone name that Matt is in and displays a map of the floor, highlighting that zone
    • Additionally, NatBot displays a ‘map’ button
  • Mac knows which zone Matt is in, but he’s not sure how to get there; Mac clicks on the ‘map’ button in his WebEx Teams
    • NatBot builds a URL using specific Mapwaze syntax that contains start zone (Mac) and target zone (Matt) and opens that URL
    • Browser displays Mapwaze service, that uses pre-created zones, lifts, staircases and paths and shows exactly how to get from start zone to target zone

Sounds complicated? Watching this short video should clear things up!

Sky is the limit

This is just the tip of the iceberg and we have some more ideas about what to do next, once the new showcase is in! 😊 Here is the list:

  • Add integration with voice assistants – why type when can just ask a question?
    • Mac: “Alexa, where is Matt Starling?”
    • Alexa: “He’s in the toilet on the 1st floor. Take a lift or stairs, go right, and right again after 10 metres. You can also see the map on your screen”
  • Add integration with calendar
    • Mac: “Alexa, what’s my next meeting?”
    • Alexa: “Your next meeting is recording podcast with Matt. It’s in Fiennes meeting room on the 3rd floor. You’re also on the third floor. Walk out of the back office and take first left and look for second door on the right. You can also see the map on your screen”
  • Add full wayfinding functionality leveraging mobile SDK
    • Support both Cisco Hyperlocation and Mist BLE
    • Offer full turn-by-turn indoor wayfinding
  • Leverage mobile sensors to enhance the blue dot experience
    • Use phone accelerometer and compass to make the experience smoother
  • Offload indoor location with Hyperlocation to GPS and 5G
    • Why limit yourself to just inside?

Gotchas 

Lastly, here is some stuff that we think might save you some ball ache 😊

  • Location Computation Frequency for your mobile device will be affected when your screen is off or when your phone goes to sleep
    • Screen off (WiFi-based RTLS): typically doubles the time needed to calculate device location; normally your mobile will go to sleep after several seconds with screen off unless some apps running in the background require connectivity
    • Sleep (all methods): typically your device can’t be tracked when asleep; if apps are used, they would have to be excluded from battery saving modes for tracking to happen
  • NTP
    • Always use NTP – AoA won’t work when AP, WLC or CMX have even slight time differences
  • Components Compatibility
    • Always check compatibility matrix!
    • Newest software across the board (CMX, Prime, WLC) does not mean it will work (we’ve learned it the hard way)
  • APs Mounting
    • Mount APs carefully, especially if multi-element arrays are in use; make sure they’re level!
  • Maps Services Fine-Tuning
    • Set APs exact locations, height and azimuth in maps services! It MUST be spotless for the solution to work
  • Don’t mix Hyperlocation with non-Hyperlocation APs
    • Device associated with a non-Hyperlocation AP on will always be shown as ‘RSSI’ (and not ‘AoA’) in CMX, even if there are Hyperlocation APs nearby
  • Associate WiFi Clients
    • Modern devices won’t probe when not associated (with WiFi on), so tracking unassociated devices, in most cases, provide very little value (and even less with WiFi MAC randomisation)
  • Use Mobile Apps
    • Optional for WiFi, but can increase accuracy and sampling frequency; mandatory for BLE
  • Add C9800 to CMX as ‘Unified WLC’ using SSH, as opposed to ‘WLC’ using SNMP 

You’ve made it! This blog has almost 6000 words. Well done! 😊

With tons of love,

WiFi Ninjas x

WN Blog 022 – Distance Between 802.11 Radios – How Close Is Too Close?

We have recently come across few production networks, where distance between two APs or APs and a client stations was much closer than I was comfortable with.

Natural reaction was to suggest moving radios at least few metres apart. But why exactly? What happens when two or more transmitting radios are too close to one another? How would placing a laptop next to the AP affect wireless network quality?

Intrigued and eager to answer questions that, interestingly, no one was asking, I have decided to lab it up, research it more deeply and document my findings. I quickly realised that there is not one, but two issues potentially affecting wireless transmission, where distances between radios were too short. Let’s discuss Channel Leakage and Near-Field Interference.

Structure:

  • Channel Leakage
  • Near-Field Interference
  • Literature

Channel Leakage

Few months after a successful design and refresh of a WiFi estate for a financial institution in London, I came back to work on a periodic wireless survey and to assess if there is anything that would be potentially stopping them from introducing more agile working heavily relying on the new WiFi deployment.

I was told that there is a separate company that is working closely with my client in the same offices and that they use their own, separate WiFi network. They have decided to put their own APs next (few inches away) to our APs convinced that since it worked perfectly for my client, it would continue working when two overlaid networks operate simultaneously. This is how the new original vs new deployment looked like:

Having completed the survey, we have concluded that city centre location inside a multi-tenant building with multiple WiFi networks leaking from the outside and adjacent floors combined with two separate, overlaid WiFi networks contributed to very high CCI averaging at 10 or sometimes more. RF tuning across both networks has helped a lot with the contention but the overall quality of the WiFi was still not great. It felt slow despite having strong underlying infrastructure, little CCI and fast Internet pipe. Quick wireless capture has revealed excessive retransmissions rates peaking at 30% in some areas even when there were not too many clients (maybe 10 per radio, often less) competing for the airtime, channel utilisation peaking at 10% and with no obvious faults with the configuration.

Lab

Next step was to reproduce the issue in the lab, where I wanted to show how channel separation and AP-to-AP distance impacts percentage of retries in the wireless transmission.

Setup

  • 2x Cisco 3702i APs registered to C9800-CL WLC broadcasting separate BSSIDs on 5GHz only
  • 20MHz static non-overlapping, clean channels (100 & 104 and 100 & 140) and max Tx power (1) set
  • One mobile station associated to each BSSID, running external speed test in the loop
  • Ekahau Sidekick used for wireless captures

Tests

4 different tests were performed, each test involved wireless capture over 30 seconds and was repeated 5 times to minimise measurement errors:

  • Channels 100 & 104 (no channel spacing)
    • Test 1: APs 0 metres away from one another
    • Test 2: APs 3 metres away from one another
  • Channels 100 & 140 (200MHz channel spacing)
    • Test 3: APs 0 metres away from one another
    • Test 4: APs 3 metres away from one another

Conclusion

We can clearly see in Test 1, that close physical distance between radios combined with no channel separation resulted in 15.4% retries.

Introducing 200MHz channel separation (Test 3) without extending distance between radios has reduced retries ratio by about half, to 8.2%.

Moving APs 3 metres away from one another has further reduced the retries to 3.9% (Test2; no channel separation) and 2.3% (Test 4; 200MHz channel separation).

Unplanned channel leakage really is an adjacent-channel interference, even though our channels theoretically don’t overlap. ACI will naturally cause increased number of retries, and therefore decrease the throughput and contribute to the slow WiFi perception.

Note: we used flagship Cisco APs with great quality of components providing great RF accuracy. Using cheaper APs that pack cheaper antennas and radios would result in less stellar performance of spectral masks (algorithms applied to the levels of radio transmissions used to reduce main channel leaking to adjacent channels) and amplify the effects of intermodulation (signal modulation on two or more different, non-harmonic, frequencies), increasing effects of ACI and percentage of retries when reasonable channel separation and physical distance between AP radios are not maintained.

Near-Field Interference

Another distance issue that I have frequently seen in an enterprise environment is placing receivers too close to transmitters.

Let’s start with a quick definition of what near-field is in wireless.

Near-field is a 1 wavelength region, where electromagnetic field EM charges and electric charge effects are extensively produced, potentially negatively affecting quality of the received transmission within this region.

Near-field interference decreases drastically, in a logarithmic fashion, when the receiver is moved farther away from the transmitter. It is normally considered enough to be 1 wavelength away from the transmitter to negate the impact of near-field interference. Near-field also affects reflected signal for Rx antennas.

Based on the above, we can conclude that:

  • Radios should never be positioned closer than 1 wavelength apart from one another
  • Receive antennas should not be positioned closer than one wavelength to any reflecting obstacle due to reflection indicted multi-path phase cancellation

How far is 1 wavelength? It depends on the frequency. The higher the frequency the shorter the wavelength. Here are the wavelength calculations for our beloved 802.11 bands:

2.4GHz frequency wavelength = 12.5cm

5GHz frequency wavelength = 6cm

Now we know, that when we position 2.4GHz radios closer than 12.5cm away from one another (or 6cm in 5GHz) we would suffer from extensive near-field interference and that the situation would improve greatly when we start increasing this distance. Bear in mind, that unwanted channel leakage might contribute to packets corruption here too, so it typically is recommended to keep at least few metres distance between the radios!

Couple of examples, where near-field interference can affect quality of WiFi transmission:

  • Enterprise-class AP placed on a small desk with few people sitting around it and their laptops virtually adjacent to the AP; note, that external antennas can increase the negative effect of a near-field interference
  • Capturing wireless packets with a capturing device positioned to close to a client or an AP

We must remember that WiFi is not NFC! 😊

Lab

In this test I targeted impact of near-field interference on wireless receive quality, where receiver (AP in a sniffing mode) was within 1 wavelength of a transmitter (AP serving clients).

Setup

  • 2x Cisco 3702i APs registered to Cisco 3504 WLC and one test client associated to client serving AP
  • AP with blue LED is serving clients
  • AP with green LED is running as a sniffer and capturing packets on the same channel as the AP serving clients
  • Below tests are based on 5GHz, but in my tests I could have easily reproduced them across both 5GHz and 2.4GHz bands

Tests

It was enough to perform a very simple test here – check captured packets integrity in two scenarios:

  • Test 1: AP sniffer placed 60 centimetres away from a client-serving AP (more than 1 wavelength distance between radios)
  • Test 2: AP sniffer placed on top of a client-serving AP (less than 1 wavelength distance between radios)

Here are the results:

Test 1 captures, where APs are fairly far away from one another, are clean. Putting transmitting and receiving radios very close together (Test 2) results in corruption of almost all packets transmitted by client-serving AP.

Conclusion

When receiver is placed too close to transmitter (especially true when the distance is less than 1 wavelength apart), near field interference will cause packets to lose integrity and result in failed Frames Check Sequence (FCS).

Summary

As shown in the above tests, unwanted channel leakage can seriously affect the transmission quality over distances less than few metres, especially without proper channel separation on the neighbouring BSSIDs. Near-field interference can cause corruption of most of the transmitted frames, where distance between transmitting and receiving radios is less than 1 wavelength apart. Finally, after having a chat with my friend Nigel (Twitter @WiFiNigel), we have concluded that the Rx overdrive might also play a role in the frames corruption. Unfortunately, it is difficult to ascertain which phenomena impacts the frames corruption most using the home lab, so I’ll just conclude with this: don’t stack APs! 🙂 And put them away from strong reflectors. All above issues can be easily avoided by using good quality enterprise equipment, solid RF design and having a high-level understanding of how the distance induced interference can affect the quality of the wireless transmission.

Literature

WN Blog 021 – Getting Started with Python Coding

Hey!

Welcome to our very first blog on our journey to learn some coding.

I decided it was finally time to stop burying my head in the sand & to make a start with taking a dive into the world of coding.

This is my very first time trying to properly understand what is required to even make a start with learning how to code – so disclaimer, this is going to be a very simple first step into Python coding.

If like me you didn’t even know where to start, what version of Python to go with, what you need to write your first piece of code, any apps required, what training material should I look at first – then this blog is probably for you as I will take you through everything I have done to write my first piece of very simple Python code.

If you already have even an intermediate level of coding or Python knowledge – then this blog probably is not for you but you are welcome to read on anyway and if you have any useful feedback for anyone else about to embark on their first journey into coding, please feel free to leave some comments below.

Let’s start with what training material I have decided to go with. I reached out to a few people that I knew who was pretty good with coding for what they would recommend as a starting point. I will list out a few of the recommendations:

  1. Cisco DevNet learning labs: https://developer.cisco.com/learning/tracks/app-dev
  2. Learn Python the hard way: https://learnpythonthehardway.org/python3/?__s=2fqytpgbriphaxjuruo3
  3. Kirk Byers “Learn Python Course” – https://pynet.twb-tech.com/
  4. Udemy Python Videos – https://www.udemy.com/course/python-complete/

I took a look at all these options and they all seemed like a great place to start but I have decided to go with the Kirk Byers “learn Python Course” – you sign up to the course on his website and then when the course starts each week he will email you about an hours’ worth of videos to watch along with some exercises. Kirk comes from a networking background so even from the very beginning when he is teaching you the Python basics – it is still cantered around networking which I like.    

Moving on to which version of Python do I start to learn – version 2 or version 3? Great question I didn’t know either, so I reached out to some guys & they all said well it depends on your environment but if you are making a start now its probably best just to jump straight in with version 3. The way it was explained is that Python v2 is kind of like IPV4 & Python v3 is IPV6 – there will still be support for v2 till the end of 2020, but everything is moving towards v3.

Ok so now I made my decision to go with Python v3 you need to install Python on your device. You can download here:

Python Download: https://www.python.org/downloads/

If you are downloading Python for the first time, make sure when you are going through the installer you check the box “Add Python to PATH”.

Python Add to PATH

If you already have Python installed here are the steps to add Python to PATH:

Steps:

  1. Right Click on ‘This PC’
  2. Click ‘Advanced system settings’
  3. Go to the ‘Advanced’ tab
  4. Click ‘Environment Variables’
  5. Select ‘Path’
  6. Click ‘Edit’
  7. Click ‘New’
  8. Add paths to Python home (example: C:\Users\macd\AppData\Local\Programs\Python\Python38-32) dir and your .py scripts dir (example: C:\Users\macd\OneDrive\WiFi Ninjas\Mist API)
  9. Click ‘OK’
Python PATH 2
Adding Python to PATH after install

After you have downloaded the version of Python relevant to your operating system we now need to install some sort of tool/ application to use to write our Python code. There are quite a few out there such but the one that I have gone with and seems to be quite popular is an application called ATOM. You can download ATOM from here:

ATOM download: https://atom.io/

Once you have installed ATOM on your device, you can install additional packages & themes to make ATOM more relevant for what you are coding. I found some recommendations online for some packages to use on ATOM specifically for Python coding which I will share with you guys what I have installed – I will be totally honest I am not 100% sure what all of them do but some are pretty self-explanatory. 

  1. “Autocomplete-python” – Python completion for packages, variables, methods, functions, with their arguments.
  2. “file-icons” – Assign file extension icons & colors for improved visual grepping.
  3. “kite” – Python coding assistant featuring AI-powered auto-completion, advanced function signatures, and instant documentation.
  4. “python-autopep8” – Formats Python code using autopep8
  5. “script” – Runs code in ATOM.
  6. “linter-flake8” – ATOM linter plugin for Python using flake8.

There was also a recommendation to use the “Predawn” theme which styles the text in ATOM in a certain way that might make it easier for you to understand different aspects of the code.

Now that we have Python v3 installed and ATOM + the additional packages for an application to use to write Python code it was time to get started!

In ATOM your first line of code needs to be a “shebang” line (not sure if I have got that correct but it certainly sounded like shebang so I am going with it!). This tells your computer that you want Python to execute this program. The shebang line begins with #! but the rest depends on your operating system. I am using a Windows laptop, so my shebang line is:

Windows shebang line: #!/usr/bin/env python3

My very first piece of code was going to a super simple one where I wrote some “strings” where a user would then input some text & then that text would be “printed” out.

Staying on the networking theme I went with some basic IP information. Here is the code that I had written in ATOM:

ATOM Code

The “ip_addr” “sub_mask” & “def_gw” are my strings and the “= input” means that is what will be seen & what a user types into here are what will the be printed which is called out from the “print” lines. I saved this piece of code as “test1.py” in my one drive.

Now I wanted to run this piece of Python code that I had written on my laptop, you can do this directly from your Windows command prompt. When you launch the command prompt you will need to change the directory first, so it knows where to execute the Python code from. As my file was in my one drive this was the command line that I needed to enter.

Change directory: “cd C:\Users\mstarling\OneDrive\Python\Python Files”

Once the directory has been changed you can then execute your Python file by using this command.

Execute Python command: “python ./test1.py”

Which should look something like this:

:estl .py — Files — Atom 
Edit View Selection Find Packages eelp 
test2.py 
Python Files 
testl. py 
test2.py 
2 
4 
6 
7 
8 
S! python3 
ipßidr = input("Enter a IP addres: ") 
sub_mask = a Subnet Mask: ") 
def_gw = Input("Enter a Default Gateway: ") 
print(ip_addr) 
print(sub_mask) 
print(def_gw) 
icrosoft Windows [Version 18.8.17134.1138] 
(c) 2818 microsoft Corporation. All rights reserved . 
: \Users\mstar1ing d C: Files 
Users mstarlin OneDrive P hon P hon Files python . /testl . py 
Enter a IP addres: 18.18.18.18 
Enter a subnet mask: 255.255.255.8 
Enter a Default Gatewa 
. 18.18.18.1 
18.18.18.18 
255.255 . 255.8 
18.18.18.1 
: \Users\mstar1ing\OneDrive\Python\Python Files>_
ATOM Code & CMD

We can see here the code in ATOM, then changing the directory in my windows command prompt, then executing the Python file & I then entered some IP-SM-DG info which then got printed out! I know this is a super simple piece of code but within 1 hour of watching my first Python training videos, I was able to install everything I needed, write my first piece of code & then execute it – which I found very exciting!

I then wrote another piece of simple code which was a little bit more relating to us 😀

thon\Pythcn Files — Atom 
2 
4 
testl.py 
Welcome 
podcast = input("Enter your favourite wireless networking podcasters: ") 
prmt(podcast) 
icrosoft windows [Version 18.8.17134.1138] 
(c) 2818 microsoft Corporation. All rights reserved . 
: \Users\mstar1ing>cd C: \Users\mstar1ing\OneDrive\Python\Python Files 
Enter our favourite wireless networkin 
IFI Ninjas 
dcasters: WiFi Nin •as 
: \Users\mstar1ing\OneDrive\Python\Python Files>_
ATOM Code & CMD WiFi Ninjas

What you can see here is you could get creative with any kind of info you wanted to input here.

There you go guys, all the first steps that it took to get me off the ground and running with Python coding. Our aim is to really push on & learn as much as possible over the next year with coding & automation so we will do our best to keep you updated along our journey with anything we think might be useful to help you guys.

I hope you enjoyed the blog & I would recommend anyone thinking about taking the plunge into making a stat with learning to code to do it – as I strongly believe that going forward as a network engineer we will really be required to have at least some knowledge and coding skills as well.

Thanks!

X

WN Podcast 026 – RTLS – Part 2 – Real World Testing

Welcome to our new WiFi Ninjas Podcast episode!

This is the continuation of the RTLS discussion, focusing on real-world tests and demos!

Three things have changed since we recorded the podcast:

  • We’ve confirmed that you can draw wayfinding paths in Prime, called ‘Rails’ in a Cisco world!
  • We’ve discussed Mist presence and analytics network-wide stats that you can include in a report; new functionality has just been added, where you can see all that stats live! Big thing from Mist, thank you guys 🙂
  • We are discussing WiFi Trilateration (lateration, so distance based, without any special AP requirements – internal omni is OK) RTLS and NOT WiFi Triangulation (that is angle based and requires multiple antenna arrays or mechanically agile antennas)

With tons of love x,

WiFi Ninjas