Broadcasting the SSID is like putting up a sign that says, “Potion of Connectivity”, “Ethernet of Enchantment”, “Dark LAN Arts” - an open invitation into the WizardFi speakeasy. But if one decides to “hide” the SSID, it’s like taking down the sign. Even though the Wi-Fi network is still there, the name doesn’t show up automatically on devices searching for a new Wi-Fi connection. If someone wants to join the hidden Wi-Fi network, they need to know the exact name to type in, along with the credentials.

While hiding your SSID is a way to make your Wi-Fi network less visible to nearby devices, hiding the SSID increases friction for people who are trying to find and connect on purpose. Hiding the SSID just removes the name from the advertisements.

Why hidden SSIDs are not a security feature

Imagine your Wi-Fi network is like the hidden speakeasy. You might think if you don’t tell anyone about the speakeasy or put up a sign, then nobody will know it’s there, and it’ll be safe. But if someone really wanted to find the speakeasy, they could just walk around looking, and they might find yours.

When people talk about hiding the SSID, it’s like not having a sign with the establishment name on your building. The building is clearly still there, but with an empty string for the SSID. The SSID is the name of your Wi-Fi network. You might think if nobody can see the name, they won’t be able to join or get in, but that’s not really how this works. Just like someone can still find your speakeasy by looking, there are tools that let people see all the Wi-Fi networks around, even the “hidden” ones. Once they find the network, hiding the name doesn’t keep them out. Rather, it is good security that keeps them out.

What really keeps your Wi-Fi safe is using a good lock, which in Wi-Fi terms is like using a strong password, encryption, and key management (like WPA3). Even if someone knows your Wi-Fi is there, they can’t get in and patronize your speakeasy without knowing the proper credentials.

There are also other problems introduced by hiding SSIDs on processes like roaming between access points, device setup, and even privacy concerns!

Discovery of hidden SSIDs

Technically, hidden SSIDs can be discovered through:

• Active probing with the SSID name
• Passive monitoring of probe requests
• Performing a deauth attack and then monitoring management frames when devices re-associate.

Impact of hidden SSIDs on device setup

Virtually every device requires manual configuration steps to connect to hidden networks, which is very frustrating for the majority of users. The SSID has to be typed in as an exact match. Additionally, some devices may simply not support hidden networks. Some IoT devices don’t have provisioning that supports hidden networks.

Impact of hidden SSIDs on privacy

When devices are configured to connect to hidden Wi-Fi networks, what ends up happening is that the device will constantly broadcast probe requests containing the hidden SSID(s) whenever the device is not in the vicinity of the network.

So, if your network name, “MagicMushroomLab”, is hidden at home, and you go to the office, your network name, “MagicMushroomLab” is constantly advertised by your device to everyone! Your device is broadcasting your “secret” network name everywhere you go.

Hiding your SSID reduces privacy compared to visible networks.

Impact of hidden SSIDs on roaming

Let’s say you have a bunch of toy stores (which are like Wi-Fi access points) in a big mall, and you love visiting them to see if they have new toys. Now, imagine if some of these storefronts decided to become invisible - now they’re still there, but you can’t see what the store is as you walk by.

If you know exactly where one of these invisible stores is, you can go straight to it, confirm the store is your target by looking, and then enjoy what’s inside. But, if you’re just aimlessly walking around looking for a specific store, you’ll miss the store at first until you determine the store is, in fact, hidden. Your ability to find the store takes longer.

In a Wi-Fi network, when your device (like your tablet or phone) is moving around, the device tries to connect to the strongest signal so you can keep watching cat videos or playing video games without interruption. This is like you moving from one toy store to another in the mall, looking for the best toys. Normally, your device can see all the Wi-Fi access points (the toy stores) that are broadcasting their names (SSIDs), so the device knows where to switch to (roam to) get a better and stronger connection.

Wi-Fi roaming occurs when a device automatically switches its connection from one access point to another within the same network to maintain connectivity as the user moves around. The device monitors signal strength and other metrics in its green diamond about nearby access points. When the current connection becomes poor, the client will attempt to transition to a stronger access point without dropping the connection.

However, if some access points are hiding their SSIDs (they’re the invisible stores), your device doesn’t immediately see them as options to connect to, even if they might have the strongest signal at your current location. Your device needs to be specifically told where these hidden toy stores and access points are and actively look for them, which is like knowing exactly where the invisible toy store is in the mall. The device has to do this every time the device needs to roam. The process to find toy stores and roaming candidates takes more time and is inefficient!

Hidden SSIDs complicate the roaming process becuase clients cannot see the access points in passive scanning procedures. Hidden SSIDs force clients to actively probe for specific network names rather than passively listen for beacons. This is inefficient for roaming decisions because of the additional time it takes to discover hidden access points which can cause brief interruptions in connectivity during real time applications!

This makes it harder for your device to smoothly switch (roam) between multiple access points, like in a business, small and large offices, or across a school campus, because your device can’t quickly identify the next available connection point without constantly actively probing. Hidden SSIDs can slow down the process of switching to the best connection, causing interruptions or delays in whatever you’re doing online, especially real-time latency-sensitive applications like voice and video streaming.

Summary

While hiding SSIDs might seem like it adds security, hiding SSIDs actually makes the Wi-Fi experience a bit more complicated and less smooth, especially when moving around.

In summary, hiding SSIDs creates a false sense of security while adding more problems and creating multiple issues! Hidden SSIDs are “security” through obscurity and do not solve a real security problem. Friends don’t let friends hide their SSIDs.

↑ Top

That’s a link on 2.4 GHz, 5 GHz, and 6 GHz in the same Multi-Link Device (MLD) which is a feature of Multi-Link Operation (MLO) introduced in Wi-Fi 7. MLO is the main feature in the IEEE 802.11be specification and Wi-Fi 7 certification program.

Here is a screenshot showing the clients perspective:

Commands used here:

• tmux to split panes
• iw dev will show you if there is an MLD.
• sudo wpa_supplicant -i wlp3s0f0 -c wpa3_mlo.conf to run the config in the bottom right pane.

Minimal wpa_supplicant config for WPA3-Personal (wpa3-sae):

ap_scan=1
p2p_disabled=1

network={
    ssid="<ssid>
    scan_ssid=1
    key_mgmt=SAE
    ieee80211w=2
    psk="<passphrase>"
}

Here is the AP perspective using show ap association mlo:

Let’s talk specifics. How many spatial streams (SS) or radio chains does the Intel BE200 have? The Intel BE200 is a 2 SS client and has two Rx/Tx chains. Most modern clients are 2 SS. There are certainly some products that have more, but the most common device these days are 2 SS for a number of reasons worth their own blog post.

When operating as a single-radio multi-link device, Wi-Fi 7 clients can listen for control frames and contend independently on different links by splitting Rx chains. This means the BE200 can listen simultaneously on different links with separate Rx chains.

The feature I just described is called Enhanced Multi-link Single-Radio operation or EMLSR for short. This is an MLO feature which enables dynamic switching between multiple links with a low-cost and power conscious implementation.

When the EMLSR client receives certain control frames, the client can switch all chains to a single link in the MLD to Tx/Rx data frames.

I’m going to repeat this again. EMLSR can only Tx/Rx data frames over one link at a time. EMLSR mode “switches” between links. EMLSR does not aggregate the links.

So, how did I do this test?

First, I configured one SSID with tri-band operation and enabled MLO. When creating a new network in the Central WebUI, during the first step, expand “Advanced Settings” and “Miscellaneous”. Scroll down and toggle “Enable Multilink Operation” to enabled. This will apply mlo-enable to the wlan ssid-profile <profile> in the running config.

The version of code tested was AOS 10.7.0.0 90579 and the AP was managed by Central. 10.7 is the first version to support Wi-Fi 7 and requires Central.

Second, I configured the client. This required getting Linux Kernel 6.11 on the client. At the time of writing 6.11 was still in development without a stable release. When using 6.10, the client would not form a MLD.

Installing the latest kernel is easy on Ubuntu using the Ubuntu Mainline Kernel Installer (mainline). I used rc7.

The supplicant was wpa_supplicant compiled directly from source using git clone git://w1.fi/hostap.git. This will put you at the latest development version possible.

You can also get MLDs to form with v2.11 of wpa_supplicant. Grab and install with wget https://w1.fi/releases/wpa_supplicant-2.11.tar.gz and extract with tar -xvzf wpa_supplicant-2.11.tar.gz

You’ll need to install some dependencies. These should do the trick:

sudo apt install libssl-dev build-essential checkinstall pkg-config dbus libdbus-1-dev libdbus-glib-1-2 libdbus-glib-1-dev libreadline-dev libncurses5-dev libnl-genl-3-dev libnl-3-dev libnl-route-3-dev

Navigate to the wpa_supplicant directory and make sure to copy defconfig to .config.

cd wpa_supplicant
cp defconfig .config

Enable Wi-Fi 7 build configuration.

Use your favorite editor (I use neovim btw) uncomment the build configuration line with CONFIG_IEEE80211BE=y to enable Wi-Fi 7 features at the wpa_supplicant configuration level. At the time of writing, the wpa_supplicant code is still an experimental work in progress.

After this, we can do the standard make, sudo checkinstall or sudo make install steps. make install or checkinstall will install and should replace the current version. sudo checkinstall --install=no will create a package without installing.

If you want to speed up make, throw all your cores at make with make -j$(nproc). make will need to complete without errors before proceeding to the next step. If you run into errors, you need to figure those out before trying to install.

For the ThinkPad fans out there. You’ll probably know that the M.2 slot on the T450s is A keyed. For the Wi-Fi nerds out there, you’ll recognize that the Intel BE200 is E keyed. Meaning the BE200 doesn’t fit in an A keyed slot. In other words, the notch is in a different place for E key versus A key slots. delock has a nice post on different M.2 keys.

How did I solve that?

I cut the A keyed notch away to fit the E keyed Intel BE200 in the ThinkPad T450s. I used my Benchmade 535 Bugout EDC knife to do the job.

Word of caution. Be very careful if you go down this route. It’s easy to destroy the slot. I did need to use tweezers and some compressed air to clear the slot free from debris created by removing the notch with the knife. Good luck!

Update: I haven’t had issues with slow boots or resume from suspend with this setup.

↑ Top

Motivation for WPA3-SAE

One of the problems with WPA2-Personal (WPA2-PSK) is Pre-Shared Key (PSK) security scheme. The scheme is solely based on the complexity of the provisioned password (thus a longer and more complex password is “better” when using PSKs) and also involves sending password-derived data over-the-air (OTA). In other words, the PSK approach is non-robust and is prone to offline dictionary attacks. All the attacker needs to do is capture the handshake which them to allows them to crack or guess the password by trying numerous possibilities offline. Once the password is cracked, the attacker can decrypt captured data.

WPA3-Personal addresses problems of WPA2-Personal by using a protocol called Simultaneous Authentication of Equals (SAE).

Simultaneous Authentication of Equals

SAE authentication uses finite field cryptography to prove knowledge of a shared password

Simultaneous Authentication of Equals (SAE) was originally defined in IEEE Std 802.11s™-2011 for WLAN mesh security. 7 years later, in 2018, the Wi-Fi Alliance (WFA) introduced WPA3.

SAE introduces a more secure handshake mechanism that mitigates the risks associated with PSK and does not require a long complex password to provide “better” security.

SAE utilizes a mechanism called a Zero Knowledge Proof (ZKP) which ensures that even if an attacker captures the handshake, the attacker cannot perform an offline dictionary attack to guess the password. This is because the ZKP requires interaction (mutual authentication) with the Access Point (AP) for each guess of the password.

Additionally, because interaction is required APs can implement rate limiting and other countermeasures to thwart online (active) dictionary attacks. This provides a significantly better defensive advantage than WPA2-Personal (WPA2-PSK)

Note that the terms WPA3-SAE and WPA3-Personal are interchangeable and refer to the same thing. I’ll use WPA3-SAE going forward.

Zero Knowledge Proof

A Zero Knowledge Proof (ZKP) is a cryptographic method where a client (the prover) can prove to the AP (the verifier) that a password is true, without revealing any information beyond the validity of the password itself. This means the client can demonstrate they know a password without actually disclosing the password itself.

A classic example of a Zero Knowledge Proof is the “cave” analogy, where a prover (client) claims to know the password to pass through a magical door in a circular cave. The verifier (AP) can repeatedly ask the prover (client) to emerge from either side of the cave, proving they can pass through the door without ever revealing the password. This is the essence of ZKPs: verifying the truth of a claim without knowing the actual content of the claim.

The Zero Knowledge Proof (ZKP) implemented in SAE is called the Dragonfly Key Exchange by author Dan Harkins and is defined in RFC 7664. Importantly, Dragonfly is an unpatented ZKP and is such that vendors across the Wi-Fi industry could implement it without the risk of lawyers and patent wars. Dragonfly is a Password Authenticated Key Exchange (PAKE) that provides mutual authentication with forward secrecy and prevents offline dictionary attacks.

Password Element (PWE)

In this key exchange, the Password Element (PWE) plays a key role functionally serving as the shared secret between two devices attempting to authenticate with each other without relying on a Pre-Shared Key (PSK) like we did with WPA2-Personal.

In Dragonfly, both the client and the AP convert the provisioned password to an element. During the commit phase, they both negotiate the shared key. After the commit phase, the confirm phase confirms the peer negotiated the same key.

The PWE is derived from a user-provisioned password and is used in conjunction with other parameters and operations during the authentication process as described above.

What you need to know is that the PWE is a transformed representation of the password that facilitates secure authentication between devices without exposing the original password itself.

Hunting-and-Pecking (HNP)

How do we get an element from a password in an unpatented manner that the industry can use and implement?

The original method to derive the PWE was via a looping mechanism called hunting-and-pecking (HNP) where the verifier (AP) does an interactive search to select a random element from a predefined set and perform operations to check whether the selected element meets the desired criteria.

Basically, hash the password (and some other stuff) and get a number. That number is then used to see if the equation for the elliptic curve produces something valid. If not, try incrementing, hash again, and try again.

Once the verifier (AP) finds an element that satisfies the requirements, the verifier (AP) uses the element to derive the Password Element (PWE). Conceptually this seemed sufficient during protocol design.

It turned out that security researchers quickly found that the implementation of hunting-and-pecking (HNP) for Password Element (PWE) derivation was not robust. Mathy Vanhoef and Eyal Ronen found some vulnerabilities coining them Dragonblood.

The HNP method is a simple process that ended up leaking information. Primarily the number of times taken to find a valid element. This presented a dictionary partitioning attack where each connection attempt shaves down the number of possible passwords. A dictionary partitioning attack divides up a large dictionary of possible passwords into smaller subsets called partitions. The attacker then tests the partitions one by one, rather than trying each password individually. The idea is to identify which partition contains the correct password by observing the response to each subset. A dictionary partitioning attack is effective against APs that do not properly implement rate-limiting and lockout.

The solution to this problem is to loop a bunch of times even if the element is found on the first try, making guessing much harder. However, vendor implementations of the Dragonfly Key Exchange were also vulnerable to a side-channel attack. An attacker with device access could determine if the device found the element or not regardless of the number of loops.

Additionally, there was a side-channel attack against Brainpool curves, which are a set of elliptic curves defined over finite fields. Brainpool curves are often used in cryptographic applications due to their efficiency and security properties. Attacks against Brainpool curves are typically around exploiting information leaked through side channels (hence side-channel attack) during the execution of the cryptographic algorithm. Attackers analyze the side channels to potentially deduce information about the operations being performed, like deriving shared secrets. The attack on Brainpool curves was largely possible because code implementation were not written in constant time, which is fundamental in cryptographic algorithms to mitigate side-channel attacks.

The next few sections will provide some background on constant time coding and Brainpool curves.

Constant Time Coding

Let’s talk about constant time coding. Imagine you have a magic toy chest that holds many toys of different sizes and shapes. Next imagine you want to find your specific favorite toy. Let’s say your magic toy chest has a rule that no matter how many toys are inside, your toy will be found in the same amount of time. Thus, if you have 10 toys or 1000 toys in the chest, the chest will find your special toy in the same amount of time. That’s like constant time.

In code, when something is done in “constant time”, this means no matter how much data we must work with, the same amount of time is taken to do the thing.

Why is constant time coding important? Imagine the magic toy chest requires guessing a secret word to operate. Suppose you have a sneaky friend who is trying to open your toy chest to steal one of your toys. If the chest takes longer to say “Nope, your guess is wrong” when the guess is closer to the secret word, your sneaky friend might figure out the secret word by paying attention to how long the toy chest takes to answer.

This analogy illustrates a side-channel attack where the sneaky friend exploits indirect information - the time the chest takes to respond - to infer the secret word. Your friends’ method of listening to how long the chest takes to respond mirrors an attacker observing the time it takes for a device to process each key exchange attempt. Like your friend observing the response timing of the chest to narrow down the correct secret word, an attacker could determine if a device successfully found the correct element in the Dragonfly Key Exchange based on processing times, even without directly seeing the number of attempts or the exchanged data. The unintended leaking of information through processing times allowed attackers to indirectly infer the correct passphrase through the side-channel attack.

Vendors must implement SAE with constant time coding to protect against side-channel attacks.

Uniform Execution Paths

In addition to execution timing, constant time coding also must ensure that the execution path does not vary based on input.

Imagine you’re navigating a maze to get to a treasure chest, and you have an observer watching from above, trying to guess the path you’ll take based on your movements.

In a non-constant time scenario, the path you take changes depending on the secret instructions you received before entering the maze. If the instructions are complex, you take longer routes with more turns; for simpler instructions, your path is shorter and more direct. The observer could deduce the complexity of your instructions based on these variations in your path.

In a constant time scenario, no matter the instructions, you always take the same amount of time and follow the same path to reach the treasure chest, performing some dummy loops or turns if necessary to make up the time when the instructions are too simple. To the observer, your path and the time it takes are always the same, making it impossible to infer anything about your secret instructions. This uniform execution path, much like in constant time coding, ensures that no external patterns or variations give away the secret, protecting the treasure chest (or password) from being inferred by watchers.

Vendors must implement SAE in a way that avoids conditional branches based on the password. The algorithm should not make decisions based on different password values that lead to different execution paths. For example, this means avoiding if-else conditions that depend on the passphrase contents.

Brainpool Curves

Now that we’ve covered constant time coding and uniform execution paths. What on earth are brainpool curves? Imagine you have a very big, squishy playdough ball. You can squish, stretch, and shape the ball into all sorts of shapes. In computers, cryptographers like to play with something similar, but instead of playdough, they use math to create special shapes called curves. These curves have special and precise rules about how they look.

A Brainpool curve is a special type of curve that cryptographers agreed to use for creating and keeping secrets safe. Just like you might have a secret handshake or secret language with a friend, computers use these curves to make sure their secrets can be shared without anyone else finding out. Brainpool curves are just one set of these curves that are known to be particularly good at keeping secrets. These curves make sure that when you send a secret over a technology communications medium, the secret is as safe as if you were to put the secret in a locked chest.

The security provided by Brainpool curves can be undermined by side-channel attacks, such as those that analyze the time it takes to perform cryptographic operations. Constant time coding ensures the operations take the same amount of time to execute, regardless of input values. If the execution time or execution path varies with different inputs, an attacker could potentially use the differences to infer secret keys.

Hash-to-curve (H2C)

The solution to making the SAE mechanism for PWE derivation resistant to side-channel attacks was to find a way to directly obtain an element without hunting and pecking (HNP). A patent-free hash-to-curve algorithm from the Internet Research Task Force (IRTF) was found that could directly obtain an element, given a password. The algorithm is the Simplified Shallue-Woestijne-Ulas (SSWU) method¹ first defined in draft-irtf-cfrg-hash-to-curve which was later replaced by RFC 9380: Hashing to Elliptic Curves.

This hash-to-curve (H2C) PWE derivation method produces a valid point on an elliptic curve satisfying the criteria by the curve’s equation. Hash-to-curve is implemented in constant time which solves the side-channel attacks on hunting-and-pecking (HNP) and works with all of the curves used by the Dragonfly Key Exchange.

Hash-to-element (H2E)

WPA3-SAE was then modified to address Dragonblood, replacing HNP with H2C, remove unnecessary looping, and implemented in constant time to combat side-channel attacks.

The Wi-Fi Alliance ended up branding hash-to-curve (H2C) as hash-to-element (H2E). Cryptographers refer to the approach as hash-to-curve (H2C). The Wi-Fi Alliance labeled it as hash-to-element (H2E).

In the context of WPA3-SAE, the direct hashing, hash-to-curve cryptographic technique is called hash-to-element (H2E). This means you will see most Wi-Fi folks refer to H2C as H2E.

>>> H2C == H2E
True

How is H2E advertised?

So, how does the AP interoperate with clients that support WPA3 and HNP, but are not updated to support H2E?

In the legacy bands of 2.4 GHz and 5 GHz, AP vendors are mostly allowing the use of either HNP or H2E. Some vendors like Cisco make this configurable allowing administrators to disable use of HNP in legacy bands. Others like Aruba do not expose knobs and handle PWE options automatically.

Note that HNP is not allowed in 6 GHz or with Wi-Fi 7 connectivity. I’ll touch on that a bit later.

Beacons and Probe Responses

The AP advertises hash-to-element (H2E) capability through Beacons and Probe Responses with the RSN Extension IE (RSNXE).

Authentication

Clients indicate which PWE method they are using during the first message of the SAE commit exchange. If the client sends status code 126 in the authentication frame, the client is using H2E for PWE derivation.

Client support for H2E

The majority of client vendors began supporting H2E in 2021.

• Android 12+
• iOS 16+
• Linux wpa_supplicant v2.10+
• macOS Ventura+
• Windows 10 21H2+
• Windows 11+

If this list is inaccurate or you have more specific information about when clients started supporting H2E, please shoot me an email so I can update this post.

Wi-Fi Alliance Role in H2E

The Wi-Fi Alliance decided to make H2E mandatory for certified devices in the following bands of operation and Wi-Fi iterations. This is because the vulnerabilities highlighted by Dragonblood demonstrate without proper protocol implementation and countermeasures in place, attackers could potentially exploit side-channel attacks to compromise Wi-Fi security.

Wi-Fi 6E

Because there are no legacy (Wi-Fi 5 or older) clients in 6 GHz and Dragonblood went public prior to the unlicensing of 6 GHz, when using WPA3-SAE in 6 GHz operation, APs and clients must use H2E. HNP is not allowed.

Wi-Fi 7

Wi-Fi 6 (802.11ax) and Dragonblood were released in the same year. So, the next iteration of Wi-Fi with version 7 presented the opportunity to make H2E mandatory for the next generation of certified devices. When using WPA3-SAE with Wi-Fi 7 in any band of operation, clients must use H2E to obtain the PWE. HNP is not allowed.

Conclusion

The transition from hunting-and-peeking (HNP) and adoption of hash-to-element (H2E) for PWE derivation in WPA3-SAE represent a step forward in improving Wi-Fi security. The WPA3-SAE protocol with H2E and the protocol properly implemented is resistant to side-channel attacks, providing users with better confidence in the integrity of their Wi-Fi networks. In this era of increasing security concerns, protocols like WPA3-SAE play a critical role in safeguarding Wi-Fi communications. The transition to hash-to-element for PWE derivation shows how the Wi-Fi industry finds ways to improve when necessary.

Thanks to Guillaume (GG) and Colin Vallance for reading drafts of this and providing feedback.

↑ Top

The Reduced Neighbor Report is an Information Element used by multi-band APs to inform clients about neighboring BSSIDs and SSIDs.

Objective

The primary objective of the Reduced Neighbor Report (RNR) is to enable clients to discover BSSIDs and SSIDs in 6 GHz by scanning only 2.4 GHz and 5 GHz.

Industry Ready

One of the ways the industry is making this happen is through the Wi-Fi Alliance. The test plan for Wi-Fi 6E includes out-of-band discovery and expects the Reduced Neighbor Report to be present. This means the Wi-Fi Alliance is testing APs for out-of-band discovery behavior. The Reduced Neighbor Report is also a Wi-Fi Optimized Connectivity feature.

Common Misunderstandings

Some bloggers in the WLAN community have stated the Reduced Neighbor Report (RNR) is from 802.11k-2008, but that is not entirely true. 802.11k introduces the ability for clients to explicitly request a neighbor report and then receive a response with roaming candidates of neighboring APs. The Reduced Neighbor Report (RNR) we see in current implementation does not require a specific request-response cycle. 802.11k also does not contain the definition for the RNR Information Element (IE).

What is true is that the idea of the Reduced Neighbor Report (RNR) comes from 802.11k-2008, but the actual definition (IE 201) is not until later, between the 2012 and 2016 rollups. The amendment that first defines the RNR IE is 802.11af-2013 (TV White Spaces).

While 802.11k does not define the RNR IE, 802.11k is still useful for out-of-band discovery. 802.11k can inform clients of 6 GHz neighbors in the neighbor report response. This means you should consider enabling 802.11k on both out-of-band and in-band SSIDs on 6 GHz capable APs. In most cases, you should deploy dual-band SSIDs on 5 GHz and 6 GHz. When the client connects on 5 GHz, the AP can inform the client of 6 GHz neighbors in the neighbor report response and through the RNR IE.

The Reduced Neighbor Report IE is automatically advertised in every beacon and probe response in 2.4 GHz and 5 GHz on capable APs. Note that some vendors are even adding the Reduced Neighbor Report in 6 GHz.

Does this mean that the Reduced Neighbor Report completely solves discovery of 6 GHz networks? No, it does not. The RNR IE is only a helper for what is often the first step of 6 GHz discovery. The RNR is like a seed. After parsing the RNR, a 6 GHz capable client will have to take action and switch its radio from out-of-band to in-band and either actively (probe) or passively (listen) discover on the target channel.

RNR Information Element

The Reduced Neighbor Report (RNR) Information Element (IE) carries some key details about the BSSIDs and SSIDs in 6 GHz:

• BSSID
• SSID via Short SSID (one-way 4-byte CRC of the SSID in 6 GHz)
• Operating class (see Annex E Table E-4 in IEEE 802.11ax-2021 or later for 6 GHz operating classes)
• Operating channel
• BSS Parameters
  • If OCT is recommended
  • If the neighboring SSID is the same or not as the current frame
  • If the neighbor is using Multiple BSSID (MBSSID)
  • If the neighbor is the transmitted BSSID or a non-transmitted BSSID (a MBSSID construct)
  • If Unsolicited Broadcast Probe Responses are active or not
  • If the neighboring BSSID and SSID are co-located or not
• 20 MHz PSD

Please note this list is not exhaustive. Wi-Fi 7 also extends the Reduced Neighbor Report by adding Multi-Link Device (MLD) parameters. Those won’t be covered in this post.

Capable clients can use information from the RNR data to seed discovery of 6 GHz networks.

Here is an example of how the RNR data from 2.4 GHz and 5 GHz scans can be visualized with lswifi -rnr:

FAQ:

Q. Which management frames carry the RNR?
A. Beacons and probe responses.

Q. Will my dual-band 2.4 GHz and 5 GHz AP use the RNR?
A. You will likely need a 6 GHz capable AP.

Q. Does the RNR help for 6 GHz only SSIDs?
A. Yes. A 2.4 GHz or 5 GHz RNR can point to a different SSID in 6 GHz.

Q. Does the RNR speed up 6 GHz discovery?
A. It can. The RNR includes a channel indication and Target Beacon Transmission Time (TBTT) offset which can tell the client exactly which channel to look for and when.

Q. Why would a client parse beacon frames from SSIDs that it doesn’t care about?
A. How does the client know whether or not it cares about a beacon frame or probe response frame without first parsing the frame to determine whether to ignore? The majority of 6 GHz clients will use out-of-band scans to seed 6 GHz discovery.

Q. How is the RNR configured?
A. Automatically on capable APs. Typically on SSIDs with operation on 2.4 GHz and 5 GHz. On a 6 GHz capable multi-band AP, along with an SSID on 6 GHz, enable an SSID on 2.4 GHz or 5 GHz radio.

Q. Do I need a 6 GHz NIC to detect RNR frames?
A. No. “Legacy” NICs can detect the RNR through existing scans and frames seen in 2.4 GHz and 5 GHz. Try lswifi -rnr in air space with multi-band 6 GHz APs present to see for yourself.

Thanks to Keith Miller for reading drafts of this and Adrián Granados for the additions to the misunderstandings.

↑ Top

Table of Contents

• Choosing between iperf2 and iperf3
• Dependencies
• Download source
• Make
• Run!
• Explore the arguments
  • Quick start for client mode
  • Usage examples

:cat:

Choosing between iperf2 and iperf3

While iperf3 may seem like an upgrade over iperf2 based on version numbers alone, they’re different tools with different strengths.

Why does this matter?

Networking testing at gigabit and beyond speeds requires threading to fully saturate interfaces.

Without adequate threading:

• You may not fully utilize the available bandwidth
• Test results may not reflect actual performance
• Multiple CPU cores may remain untapped

iperf2 and iperf3 are both actively maintained tools. While iperf3 recently added threading support, iperf2 offers a few benefits over iperf3 for high-performance networks. For more detailed feature comparisons see the official iperf2 comparison documentation.

Here’s the rub.

Sometimes the iperf2 version provided by the system package repositories is outdated. Here is how we can compile iperf2 from source.

Dependencies

Open a terminal emulator (either the included one or something like iTerm2).

1. Install Homebrew following ths instructions on their webpage.
2. Install dependencies required to build and make iperf2.

brew install gcc automake

If you were on something like Debian, you’d want these depends:

sudo apt-get install build-essential g++ automake autoconf

Download source

Go to https://sourceforge.net/projects/iperf2/, click on the Files tab, and download the .tar.gz file for your desired version.

In the original post, I used 2.1.9. Here are some of the download URLs:

• 2.1.9: https://sourceforge.net/projects/iperf2/files/iperf-2.1.9.tar.gz/download
• 2.2.0: https://sourceforge.net/projects/iperf2/files/iperf-2.2.0.tar.gz/download
• 2.2.1: https://sourceforge.net/projects/iperf2/files/iperf-2.2.1.tar.gz/download

Place the zip file somewhere on your machine like ~/Downloads.

Enter that directory in your terminal.

Extract and enter the directory using tar -xvf <archive> like so:

cd ~/Downloads
tar -xvf iperf-2.2.0.tar.gz
cd iperf-2.2.0

Make

If you’ve not already entered the directory from the previous step, do so now.

1. Run ./configure to configure the for our machine:

./configure

1. Compile iperf2 with make:

make

1. Install iperf2

sudo make install

1. Verify install:

Run which iperf and iperf -v:

which iperf
/usr/local/bin/iperf

iperf -v
iperf version 2.2.0 (10 April 2024) pthreads

Run!

On first run, you will likely need to allow iperf to accept incoming network connections when running in server mode (with -s).

MBP M2 (iperf2 v2.1.9):

MBP M3 (iperf2 v2.2.0):

What do you think is being testing here when the server and client is on the same machine? And wow, the M3 is way faster than the M2. 125% increase!

Explore the arguments

Quick start for client mode

iperf -c <IP> -i 1 -w1M -P4 -t 60

Explanation:

• -c <IP>: This specifies that iperf should run in client mode (-c) and connect to the server at the specified IP address.
• -i 1: This sets the interval (-i) for reporting the results. In this case, iperf will display intermediate results every (1) second.
• -w1M: This sets the TCP window size (-w) for the test. Here, 1M (1 megabyte) specifies the size of the TCP window. The window size controls how much data can be sent before receiving an acknowledgment.
• -P4: This specifies the number of parallel (-P) client streams. With -P4, iperf will use 4 parallel streams to test the network. This can help in assessing the network performance under concurrent loads and can provide a more accurate measure of the overall bandwidth.
• -t 60: This sets the time (-t) duration of the test. Here, 60 specifies that the test will run for 60 seconds.

So, the command above will run an iperf client that connects to the server at the given IP address, using 4 parallel streams, with a 1 second reporting interval, a TCP window size of 1 megabyte, and a test duration of 60 seconds.

Usage examples

Basic Parameters

• -s: Run in server mode.
• -c <host>: Run in client mode and connect to .
• -p <port>: Specify the port number to use (default is 5001).

Test Duration and Interval

• -t <time>: Specify the time in seconds to run the test (default is 10 seconds).
• -i <interval>: Set the interval for reporting results (default is 1 second).

Bandwidth and Transfer Control

• -b <bandwidth>: Set the bandwidth to use for the test. You can use suffixes like K, M, G (e.g., -b 100M for 100 Mbps).
• -n <bytes>: Specify the amount of data to transfer (e.g., -n 100M for 100 MB or -n 1000G for 1 TB).

Data Transfer Modes

• -u: Use UDP instead of TCP.
• -l <length>: Set the length of the buffer to use for each packet (default is 8 KB).
• -f <format>: Set the format for reporting bandwidth (k for kilobits/sec, m for megabits/sec, g for gigabits/sec).

Additional Options

• -V: Enable verbose output.
• -R: Reverse the direction of the test, so the server sends data and the client receives.
• -S <tos>: Set the Type of Service (TOS) or Differentiated Services Code Point (DSCP) for the UDP packets.

Client Options

• -w <window>: Set the TCP window size.
• -Z <TCP compression algorithm>: Set the default congestion control algorithm (I tried reno, cubic, and bbr on the M3 and they all performed the same in the localhost test).

For a complete list, take a look at the iperf2 manpage.

↑ Top

Table of Contents

• Why should I care?
• Do I have to follow these rules?
• General Style
• Wi-Fi
• Frequency and Channel Bandwidth
• Power
• Throughput
• Resources and Rationale

:cat:

Why should I care?

The International System of Units (SI) is a globally recognized system of measurement that provides a standardized way to measure and communicate various physical quantities such as length, mass, time, and electric current. Wi-Fi is a technology that uses radio waves to provide wireless network connectivity between devices.

Using the correct SI units is important for international communication and standardization. Wi-Fi is a global technology used by people around the world (and in space!), and having a common system of measurement ensures that everyone is using the same standards and terminology. This can help prevent confusion and promote efficient communication and collaboration across borders.

Overall, while understanding the SI units for Wi-Fi may not be essential for everyone, it can be a useful skill for those who create content for those who work in IT.

Do I have to follow these rules?

No, you don’t have to, but you should. Your writing style will be more correct if you follow these rules.

General Style

Rules:

• Units are printed in lower-case letters unless they are derived from a proper name, in which case the first letter is a capital letter. Like giga which the symbol is G where an example is 1 Gbps.
• The numerical value always precedes the unit symbol (unit of measurement) and a space is always used to separate the unit from the number. Recommended to use a non-breaking space to separate the unit and number.
• The unit, if not included in SI, should follow branding guidelines (Wi-Fi for example) or commonly accepted conventions (dBm for example).

Wi-Fi

Correct:

• Wi-Fi
• Wi-Fi 4
• Wi-Fi 5
• Wi-Fi 6
• Wi-Fi 6E
• Wi-Fi 7
• Wi-Fi 8

Wrong:

• wifi
• WIFI
• WiFi
• WiFI
• wifi 1
• wIFi 2
• Wi-Fi 3
• wifi6
• WiFi6
• wifi6e
• wi-fi
• Wi-FI
• Wi-Fi 6e
• Wi-Fi6e
• wifi7
• WiFi7
• wifi8

Frequency and Channel Bandwidth

Correct:

• 1 Hz
• 20 MHz
• 40 MHz
• 6 GHz

Wrong:

• 1hz
• 1 hz
• 20mhz
• 40MHZ
• 40 MHZ
• 6ghz
• 6Ghz
• 6GHz

Power

Correct:

• 1 W

Wrong:

• 1w

Throughput

Correct:

• 10 Mbps
• 20 Gbps

Wrong:

• 10mbps
• 10 mbps
• 10 MBPS
• 20GBPS

Resources and Rationale

Check out these links for further reading to understand the rationale behind this post.

• International System of Units and SI Brochure: https://en.wikipedia.org/wiki/International_System_of_Units
• NIST: https://physics.nist.gov/cuu/Units/checklist.html
• dBm: https://en.wikipedia.org/wiki/DBm

Thanks to Colin Vallance for reading drafts of this.

↑ Top

• Symlinking the airport utility
• airport channel locking procedure

:metal:

Symlinking the airport utility

First things first. Let’s make it easy to find the hidden but included airport utility by creating a symbolic link to a directory on the PATH environment variable.

Symlink the airport utility to /usr/sbin.

sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/sbin/airport

airport channel locking procedure

1. Disassociate

2. Set target channel with the airport utility

   sudo airport --channel=120
   

   Confirm with-

   airport -I
   

3. Associate

Fingers crossed the Wi-Fi NIC connects to the target channel. I’ve tested with some success on macOS Ventura 13.2.1 on an Intel-based MacBook Pro. Let me know if it works or doesn’t.

After a few years of development, I released a lightweight Wi-Fi scanner for the Windows¹ command-line interface.

It provides some information about nearby networks that built-in tools do not provide. This includes RSSI, dissection of some information elements, and more.

Sharing Knowledge Is Important

Many have graciously passed on knowledge to me. This is the primary reason why I decided to share this project with others and make the source code available. You can find the code on my personal GitHub joshschmelzle/lswifi account.

Naming Things Is Hard

I called it lswifi because all the other clever names on Python Package Index (PyPI) were already taken. This was probably the only thing I regret. Not properly reserving the names that I wanted when I discovered they were available. I even rented a domain for a year which expired before I released this project. Oops.

How to Dissect 802.11 Information Elements

This project has taught me a lot about different information elements found in 802.11 beacon and probe response frames across different vendors.

From the vendor attributes containing AP names, to the RSNE containing security information, to WMM and EDCA values.

Parsing out these information elements with code was an incredibly valuable learning experience.

Python Packaging

I learned how to package scripts into sharable tools. This was absolutely required to get beyond code that only runs on my machine.

I started this project back when Ken Reitz was the primary maintainer of requests and adapted my packaging approach based on his. Requests is now maintained by the Python Software Foundation (PSF).

I uploaded lswifi to PyPI. This means you can download it with pip install lswifi.

The console scripts entry point is named lswifi. On install a command-line wrapper is created around the entry point. By default when you run lswifi it will respond with a list of nearby networks.

C:\Users\josh>where.exe lswifi
C:\Users\josh\AppData\Local\Programs\Python\Python38\Scripts\lswifi.exe

After install, you should be able to type lswifi and hit enter after installing. If that doesn’t work. Likely the Python scripts directory is not in the PATH environment variable.

How to Decide What to Support

lswifi is built with Python and requires Python 3.7 or higher. I want to be able to use some of the features in 3.7 like dataclasses and improvements to stdlib packages like asyncio.

I will only support Windows 10 even if it might work on older versions of Windows. I no longer have access to anything running an older version of Windows. Nor do I wish to.

Now and in the foreseeable future, lswifi is a CLI tool only. I do not intend to create a GUI for it. But I may add a background service that provides notifications on certain events like connection and roaming events.

I get to pick and choose what to support because my time is valuable. Every minute I spend working on lswifi is a minute taken away from spending time with my family. I am also not compensated for this work.

Improved Knowledge of a Programming Language

I picked Python. And unfortunately this required creating a wrapper around Native Wifi wlanapi.h. This is because the Native Wifi API is designed for C/C++ developers. This project has taught me a lot about Python. I currently have no third party dependencies on anything outside of the standard library.

ctypes Required

To interface with the Native Wifi library using Python, you must write wrapper code around the wlanapi.h.

This is painful and not for the faint hearted. Along with reading the official ctypes documentation, I did a lot of googling to figure out how to write wrapper code. The folks I pinged about it sent me towards articles which I had already looked at.

I did find some similar Python wrapper libraries around wlanapi.h, but they had problems. I ended up re-writing anything I found to adapt it to my project.

I wouldn’t have been able to do this without Microsoft’s Native Wifi documentation. Helge Magnus Keck was also kind to share bits and pieces of knowledge with me. Thank you Helge.

Limitations of the Native Wifi API

When you ask for scan results from the Native Wifi wlanapi.h, you have no control over certain things.

No control over what channels get scanned. That is up to the driver, per scan request. I often see mine skip DFS channels where I know APs are. The best solution I have come up is to run lswifi a few more times to get more scan results.

We have no control over how long the dwell time is on a certain channel. The wlanapi expects the driver to complete and return scan results with-in 4 seconds, but sometimes it will respond faster. The approach we use is a callback to detect when the results available. Once available, we ask for the results and get a list of networks and their fixed and tagged parameters (information elements or IEs).

Scan results can contain a beacons, probe responses, or both of those merged for a particular network. This means:

• Some results may have IEs from only the probe response
• Some results may have IEs from only the beacon
• Some results provided back are from cached results
• Some results may mix the IEs for the beacon and probe response for a particular network

This is why some results have AP names in them and some don’t. AP names are in beacons, not probe responses. So the application layer must cache those types of results in order to display them consistently in the output.

C:\Users\josh>lswifi --ap-names -include corp
display filter sensitivity -82; displaying 4 of 24 BSSIDs detected in scan results:
-==~+=~~=+++=-  -~~~=~=~=~+~+~~+-  -=~+++=+=++~====++-  -~==-  -~-  -=~~+~-  --  -=~++===~=~+-  -===~+++==~-
         ESSID  BSSID              AP NAME              RSSI   PHY  CHANNEL  SS  AMENDMENTS     AP UPTIME
[Network Name]                                          [dBm]  .11  [#@MHz]  #   [802.11]       [approx.]
-+~~=~~=~=~++-  -++~~=~=~++=+~+=-  -~~+~~+~~=++=~+~=+-  -++=-  -~-  -~=~=~-  --  -~+~~=====+~-  -++~++++~~~-
     corp-fast  b4:5d:50:1a:d3:91  Josh-205H            -73    ac    52@20   2   d/e/h/i/k/r/v  00d 1:51:58
     corp-data  b4:5d:50:1a:d3:90  Josh-205H            -75    ac    52@20   2   d/e/h/i/k/v    00d 1:51:58
     corp-fast  a8:bd:27:33:44:f1                       -77    ac    64@40-  4   d/e/h/i/k/r/v  03d 15:48:23
     corp-data  a8:bd:27:33:44:f0  Josh-AP324           -77    ac    64@40-  4   d/e/h/i/v      03d 15:48:23

We also have no idea if RSSI values are averaged across multiple frames. This could be problematic depending on what you’re trying to do with the responses. This means we may not want to use this sort of data for a passive survey. Michael Berg (TamoSoft) and Mikko Lauronen (Ekahau) explained on a recent Twitter thread that when doing a passive survey, the most accurate way to get survey data is to do a packet capture gathering beacons without keeping the packets. Most professional survey tools take an active packet capture during a passive survey and do not save the packets.

With that said, responses from the Native Wifi API still have purpose. This gives us insight into what networks are seen from and available from the clients perspective. We can do a simple discovery scan for nearby networks and display the results. That is what lswifi does.

Pick the right tool for the job at hand.

An IDE May Be Needed as Your Codebase Grows

When the codebase gets large, it is worth considering using an Integrated Development Environment (IDE). I did much of the development using PyCharm. This is not required though. VS Code is a good choice for those looking to start something today. Sublime Text 3 is also another strong choice. Real Python has a great article on ST3 for full stack Python development. If you do any Python work on SBCs, it is critical to learn Vim. If you absolutely do not want to learn Vim, you can now do remote development using VS Code. I have used each of the above to write Python code.

The Path Is Not Straight

It took me many hours of trial and error. The path was not straight forward. I’ve asked many people questions to help develop certain things. I’ve had many personal ups and downs during development. I am very grateful for those who have shared their positivity with me.

Perfection Is a Blocker

There are many things about lswifi that need improved. Let’s be honest: all code is garbage. There is always a better way to do what I am doing, but I can’t let perfection stop me. Perfection is the enemy of done. With that said, there is much work left to do on it.

I Built lswifi for Me

I built lswifi for me. I hope if others try it, they find it useful.

Got questions? Reach out. I appreciate constructive comments and feedback!

:metal:

Changelog

• 2020/10/04: added a few more sections, formatting, clarifications, and fixed some minor spelling errors

↑ Top

This post is about MAC Addresses and dissecting their common randomization format.

• What is a MAC Address
• Governance and Definition
• Representation of a MAC Address
• Universal MAC Addresses
• MAC Randomization
• Local MAC Addresses
• Structure of Local MAC Addresses
• Detection Using Python
  • Example Function
  • Example Regular Expression
• Changelog

:metal:

What is a MAC Address

A MAC address¹ is an identifier for a network interface. This is sometimes referred to as a layer 2 address² or physical address.

Note some networked devices may have multiple interfaces. This means a device could be identified by multiple MAC addresses.

There are different types of MAC addresses. Some are universally unique. Some are locally assigned (not universally unique). Some kinds have different lengths.

This post will only cover at the surface unicast 48-bit MAC addresses (with a 24-bit OUI), Universally Administered (UAA), and Locally Administered (LAA).

Governance and Definition

There are two standards bodies involved in MAC Addresses. The concept and definition is a recognized international standard.

The International Organization for Standardization (ISO) body defines MAC Address definition and representation. ISO legitimizes the format internationally. The original standard is ISO/IEC 10039 published first in 1991, but I was unable to find an available copy to review for this post.

The Institute of Electrical and Electronics Engineers (IEEE) is the authority, assigner, and maintainer of unique identifiers.

Representation of a MAC Address

A binary³ representation of a 48-bit MAC address is 6 octets of binary digits (bits):

The human readable format of a 48-bit MAC address is represented by 12 hexadecimal (hex) characters. There are 16 characters in a single hex digit which represent values 0 to 9 and a to f. This means hex is known as a base 16 numerical system. Each octet is represented by 2 hexadecimal characters.

A 48-bit MAC address represented in hexadecimal:

• 70:81:eb:ca:a9:b1

You might see hexadecimal representation in a few different formats. Here are some common ones:

• 70:81:eb:ca:a9:b1 - colon delimiter
• 70-81-eb-ca-a9-b1 - hyphen delimiter
• 7081.ebca.a9b1 - dot delimiter in groups of 4 hex digits
• 7081ebcaa9b1 - no delimiter

Stacked binary and hexadecimal representation:

Universal MAC Addresses

Companies like Apple, Google, Microsoft, etc. request and purchase blocks of identifiers (MAC addresses) from the IEEE. The IEEE will assign them a 24-bit Organizationally Unique Identifier (OUI). The remaining bits are assigned however the company wishes given uniqueness is maintained.

When a network interface is using the MAC address assigned by the company, this is known as the burned-in address. This particular identifier is known as a Universal MAC Address.

Example representation of an OUI:

70:81:eb is an OUI assigned to Apple by the IEEE. You can see for yourself by plugging in the hex representation into an OUI lookup tool⁴.

MAC Randomization

MAC randomization is not a new concept. It has been used for years by certain clients to randomize the address sent in probe requests. When associated, the client would send the real MAC address.

Many client manufacturers now enable MAC randomization by default. For both the probe request and association. This includes iOS 14, Android 10, and Windows 10. Jim Palmer has a great article on this.

This means the MAC randomization feature changes the burned-in address to a randomized MAC address. The idea of MAC randomization is to help protect end users from tracking or profiling across Wi-Fi networks. It is a privacy feature for consumers.

The common private MAC address format leveraged is technically known as the Locally Administered Address (LAA) format.

Local MAC Addresses

MAC address can either be universally or locally assigned. We already covered that universal addresses are assigned by the manufacturer. A locally administered address is not assigned from an IEEE block of MAC addresses.

We can determine whether a MAC address is universal or local by looking at a specific bit in the first octet. The distinguishment is by setting the second least significant bit (LSB) of the first octet.

If the second LSB is set (1), the address is administered locally. If the second LSB is unset (0), the address is administered universally:

• 0: intended to be globally unique (OUI enforced)
• 1: locally administered

For a local example, the first octet of d6:70:b6:a2:b8:8a contains d6 (2 hex digits). The binary representation of the first octet is 11010110. Where bits 7-4 = 1101 or hex digit d, and then bits 3-0 = 0110 or hex digit 6. The second LSB is set. This is a local MAC address.

The second LSB is 1. It’s bit position 1 in the table below (the value two from the far right).

For a universal example, the first octet of 70:81:eb:ca:a9:b1 contains 70 (2 hex digits). The binary representation of the first octet is 01110000. Where bits 7-4 = 0111 or hex digit 7, and then bits 3-0 = 0000 or hex digit 0. The second LSB is unset. This is a universal MAC address.

The second LSB is 0. It is represented by bit position 1 in the table below.

Structure of Local MAC Addresses

We can now look at the 2nd LSB of the first octet of a MAC address to determine if it is following the MAC randomization format.

Here are the possible unicast values for the 2nd digit of a MAC address:

This means we can look at the second character of a MAC address for 2, 6, a, or e to determine if it is a randomized MAC:

• x2:xx:xx:xx:xx:xx
• x6:xx:xx:xx:xx:xx
• xA:xx:xx:xx:xx:xx
• xE:xx:xx:xx:xx:xx

Detection Using Python

Example Function

Here is an example using a Python function to test if a string representation of a MAC is a randomized MAC:

def is_randomized(mac: str) -> bool:
    return any(local == mac[1].lower() for local in ["2", "6", "a", "e"])

Example:

>>> def is_randomized(mac: str) -> bool:
...     return any(local == mac[1].lower() for local in ["2", "6", "a", "e"])
...
>>>
>>> macs = [
...     "9a:38:2b:54:f3:7b",
...     "b2:fd:70:62:b0:d9",
...     "16:08:61:6f:a4:97",
...     "5e:b8:22:43:61:6b",
...     "00:0b:86:a3:71:22",
...     "fc:ec:da:16:50:fb",
...     "d4:20:b0:09:1c:bf",
...     "a8:8e:24:a3:38:bc",
... ]
>>>
>>> for mac in macs:
...     print(f"mac: {mac}, random? {is_randomized(mac)}")
...
mac: 9a:38:2b:54:f3:7b, random? True
mac: b2:fd:70:62:b0:d9, random? True
mac: 16:08:61:6f:a4:97, random? True
mac: 5e:b8:22:43:61:6b, random? True
mac: 00:0b:86:a3:71:22, random? False
mac: fc:ec:da:16:50:fb, random? False
mac: d4:20:b0:09:1c:bf, random? False
mac: a8:8e:24:a3:38:bc, random? False

Example Regular Expression

Here is a Python example using a regular expression to do the same thing:

>>> macs = [
...     "9a:38:2b:54:f3:7b",
...     "b2:fd:70:62:b0:d9",
...     "16:08:61:6f:a4:97",
...     "5e:b8:22:43:61:6b",
...     "00:0b:86:a3:71:22",
...     "fc:ec:da:16:50:fb",
...     "d4:20:b0:09:1c:bf",
...     "a8:8e:24:a3:38:bc",
... ]
>>>
>>> import re
>>>
>>> for mac in macs:
...     match = re.search("^.[ae26].*", mac.lower())
...     if match:
...         print(mac)
...
9a:38:2b:54:f3:7b
b2:fd:70:62:b0:d9
16:08:61:6f:a4:97
5e:b8:22:43:61:6b

Changelog

• 2020/10/03: clarifications, add link to a post by Jim Palmer

Thanks to Keith Miller for reading drafts of this.

↑ Top

When creating a Wi-Fi design for a walled environment, we care to know the wall attenuation values. These values are used for design input². This is because not all walls are equal. The make of walls will vary. Some may be dry wall, double dry wall, dry wall as a façade over some material, brick, concrete, or other materials.

Below are some of my notes on how to measure the attenuation of a wall.

The items needed:

1. A device to generate Wi-Fi.
   • Examples include your phone with a hotspot enabled, a USB powered WLAN Pi³ in hotspot mode, or an Enterprise grade AP with a battery pack.
   • Ideally use a generating device that you can control the transmit power and channel. This is for the sake of consistency across your measurements.
2. A device to measure Wi-Fi.
   • This could be an AirCheck G2, Ekahau Sidekick, iPhone with the AirPort Utility⁴, Android with Aruba Utilities⁵.
   • Ideally use a measuring device that you can set to scan on only the channel that your generating device is on.

Here is a process to follow for a particular wall:

1. Place your Wi-Fi generating device at least 4 meters⁶ (12-15 feet for you Imperial folks) away from the wall you are measuring. There should be nothing between the device generating Wi-Fi and the wall.

   Example:

   

2. If you can control the scanning channel on your measuring device, set it to scan on only the channel that your generating device is using.

3. Point the ‘ear’⁷ of the measuring device towards the generating device on the near side of the wall. There should be direct line of sight between both the generating and measuring devices. Do not stand between them. Stand (or sit) to the side.

4. Take several sets of measurements and determine the average on the near side of the wall. You could refer to these as X. Make note of these values.

5. Move the measuring device directly to the other side of the wall. Similar to the previous measurements, point the ‘ear’ of the measuring device towards the generating device. If you can, try to make sure nothing inside the wall is skewing the results.

   Example:

   

6. Take several sets of measurements and determine the average on the far side of the wall. You could refer to these as Y. Make note of these values.

7. X - Y = Wall Attenuation

8. Document!

Changelog

• 2020/09/24: minor updates, added example images

Thanks to Mark Brasacchio and Ryan Stewart for reading drafts of this.