Month: July 2021

Sleeping, Wi-Fi clients

Sleeping, WiFi clients

DTIM stands for Delivery Traffic Indication Map. This is an information element inside the beacon that tells the associated client if the AP has Multicast traffic or Unicast traffic for the client.

TIM stands for Traffic Indication Map. This is an informational element inside the beacon that tells the associated client if the AP has any unicast traffic for the client.

APs send out Beacons to advertise the networks and the capabilities of these networks. Any wireless device will read these beacons and display the SSID of each network. These beacons are sent out every 102ms or so. A Beacon has either a TIM or a DTIM information element in the beacon. When the AP has unicast packets for a station the AP will send a beacon with TIM informational element in it. The Beacon will list the AID of that client. When the client wakes up it will read these beacons and send a (Null Data Frame ???) asking for these packets. The AP will send down the packets and set more flag (see screenshot) telling the client the AP has more data. The client will request the data the AP has, and this exchange will persist as long as the AP has data.

When the AP has multicast packets for a station the AP will send a beacon with DTIM information in it and the AID of the station. When the APs tell the station, it has Multicast packets it sends those packets out ASAP even if the station is asleep. The AP will hold Unicast packets, but it will not hold multicast packets longer than the DTIM period. The AP must dump these packets as soon as the DTIM expires.

When the DTIM is set to 1 the beacons with DTIM Informational Element will be sent out every beacon. If you set the DTIM value to 2 the Multicast packets will be sent out every 2 beacons. If you rely on Multicast to deliver audio and your DTIM is set to high you will hear choppy audio during Multicast sessions.

Some device manufacturers require a higher DTIM setting so their devices can sleep more often

This begs the question “Does a Lower DTIM make the device sleep less often?”

The obvious answer is yes. Since all devices must (per the IEEE) wake up at each DTIM Beacon. The less obvious answer is it depends (“It depends” was used with permission and all applicable fees and homage were paid to Sam Clements for use of this TM saying). Most devices will sleep longer than the DTIM period. Vocera badges for instance will sleep for 500ms. This means they may miss the 1^st few (up to 4) Multicast packets. It’s tough to say how often this happens since it will be tough to tell the difference between 100ms and 500ms as the badge is waking up.

Other device manufactures are the same. Ben Miller from @sniffwifi has an excellent blog called Go to Sleep, Go to sleep, Got to sleep little iPhone.

Ben Miller’s Blog Go To Sleep, Go To Sleep, Go To Sleep Little iPhone

https://www.sniffwifi.com/2016/05/go-to-sleep-go-to-sleep-go-to-sleep.html

Static Channel Assignment vs RRM/ARM

Every time I scan a network that uses Radio Resource Management (RRM) or Adaptive Radio Management (ARM) and I see access points on the same channels near each other I cringe. I see this even with networks that are using all 26 5GHz channels. Why does RRM/ARM repeat channels so frequently? Every time I see this and I hear people saying RRM works every time without issue or configuration I have to chuckle a bit. Well, I think you will see as far as Channel planning it does not work well.

I have always been a fan of static channel assignments and static power. I know I am a dinosaur, but this is the only way you can be assured you will not see the same channel repeated very often.

I still recommend using an 8 channel plan, especially when using voice (as I said I am a dinosaur). I believe this is not a problem since back in the day we had 2.4GHz and only had 3 non over lapping channels to work with. Now if we recommend anyone use only 8 channels some network administrators cry like little schoolgirls saying “We want to use all the channels because we want the higher data rates that 40MHz and 80MHz channels give us”.

First of all, if you are using 80MHz in an enterprise environment (on 5GHz) you should be tarred and feathered. We all know how inefficient 80MHz channels are, but some Network Admins have bought into the marketing hype that bonded channels give you higher data rates and a faster more efficient network. This argument has plenty of holes in it.

The two I like to bring up are;

1.)The majority of even data packets are small (voice, email, web browsing) and these packets never use the full bandwidth of bonded channels.

2.)Even when larger packets are sent the secondary channels remain less than fully utilized.

I was once at a site that was using Extreme Access Point running Radio Resource Management (or whatever their version is). They had only 30 Access Points and were using 26 5GHz channels so, in theory, I should have seen only 4 channels repeated once and most channels never repeated. This of course was not the case. There were multiple times when I scanned the network and saw the same channels within range of each other. I can hear the skeptics saying that only happens with brands like Extreme but if you look at the screenshots below you will see this happens with Cisco and Aruba as well.

Each AP vendor has a crazy way of coming up with a list of preferred channels and they use these channels more often than others. Cisco used to heavily use Channel 36; now they’ve seemed to fix the channel 36 issues, but they still repeat channels in an RRM configuration far more than you would if you manually planned the channels.

When we design a wireless network, we always use a static channel and static power; this works extremely well. The problem comes in when we install the system and for whatever reason we let RRM take over after the design is done. Why is this? I have never heard of a design or customer requirement that states let RRM choose the channel and power. When you are planning your design the channel plan may be chosen by the design software like Ekahau or AirMagnet but this is still far better than RRM.

There are some arguments to be made for RRM over static channels design. Two of the arguments are the DFS channel issue and the coverage issues (if an AP goes offline). The first argument is the DFS channel issue. If you assigned your channel plan statically and used DFS channels, when the AP hears a radar event by the regulation, the AP needs to stay off that channel for 30 min. If you used static channels the AP would have to stop transmitting for 30 minutes. The AP does this because it lacks a mechanism to shift from the affected channel. The second argument for RRM is the coverage issue. If an AP goes offline then RRM can manually adjust the power of existing APs to fix the coverage gaps.

There are two fixes for this. The first is to keep to the 8-channel plan and you would never use a DFS channel. The second fix would be to design your network for voice coverage (two APs at -65 or better) if one AP went offline due to a radar event then there would be another AP to make sure the coverage was still good.

There are three screen shots below two from a Cisco network and one from an Aruba Network. These screenshots show multiple examples of RRM/ARM using the same channel in close proximity of each other.

This screenshot shows 2 APs on Channel 36 , 3 APs on Channel 100 . There is separation on some of these APs but my point is that, when left to RRM, Cisco uses channels more than they should on the same floor. This screenshot was filtered to show only the APs that my device was connecting to.

.....

This screenshot is from a Cisco site running RRM. You can see multiple APs have the same channel. There are 5 APs on Channel 36 , 6 APs on Channel 44 , and 2 APs on Channel 149 . This screenshot was filtered to show only the APs that my device was connecting to.

..............

Just in case you are thinking I am just picking on Cisco here is an Aruba site that has 2 APs using channel 44 , 2 APs using Channel 149 , and 2 APs using Channel 100 . This screenshot was filtered to show only the APs my device was connecting to.

......

In conclusion static channel power is the only way you can be certain that channels will not get used over and over again. RRM and ARM have there place but nothing can implement your channel plan better than you can.

Thank you for reading this blog. Please leave comments and continue this discussion on Twitter and Slack. If you haven’t followed me on Twitter please use this link to follow me.

Multicast MAC address

Multicast MAC address

This may or may not be particularly useful, but I found it interesting, so I decided to blog about it. Hopefully, this will help someone have a better understanding of multicast and how packets flow over the network. All packets on an IP network need to have a MAC address so the network can send the frames between layer 2 devices. This makes sense, but I was a bit surprised to find out the multicast sessions have their own MAC address. How else would multicast traffic and packets get delivered? I guess I never took the time to even think about it before.

I have always thought and talked about the multicast session in the form of an IP address like 230.230.0.1 but each MC session has a MAC address associated with it. The session would need this to move the traffic on a layer 2 network.

This blog will explain how the MAC address is created; I will show you some screenshots displaying these multicast MAC addresses. This might be confusing at first but once you read it over a few times it makes perfect sense.

All Multicast MAC addresses start 01:00:52:0 (the 25^th bit in the MAC address for a Multicast session is always 0) the next 23 bits are the IP address translated to binary or Hex. The table below shows the MAC address for the multicast IP session of 230.230.0.1



			230	230	0	1
IP address in Binary form			11100110	11100110	00000000	00000001




MAC address in Binary form	00000001	00000000	01011110	01100110	00000000	00000001
MAC Address	01	00	5E	66	00	01

There is an issue when you convert multicast IP into a MAC address. When we look at this a bit deeper you will see that since the 25^th bit is always 0 this MAC address for 230.230.0.1 and 230.102.0.1 would be the same. Both MAC addresses would be 01:00:5e:66:00:01 I have never seen this cause an issue before but theoretically, it could.



			230	102	0	1
IP address in Binary form			11100110	01100110	00000000	00000001




MAC address in Binary form	00000001	00000000	01011110	01100110	00000000	00000001
MAC Address	01	00	5E	66	00	01

Packet capture of a multicast MAC address

I work for Vocera so naturally, the packets I have captured are Vocera Multicast sessions. The Vocera Multicast group MAC address is normally 230.230.xxx.xxx The first session will have 230.230.0.1 and each session will increase by one. The range we use has 230.230.0.1 – 230.230.15.254 when the server runs out of addresses it will start over. Stopping and starting the server or a fail-over will reset the address’s space as well.

Vocera MC MAC address is always 01:00:5e:66:xx:xx xx:xx matches up with the 3^rd and 4^th Octet in the IP address. As the graph above shows 230.230.0.1 MAC address is 01:00:5e:66:00:01 the last Multicast session 230.230.15.254 would be 01:00:5e:66:0f:fe

I hope you found this interesting and thought-provoking. Thank you for reading this blog. Please leave comments and continue this discussion on Twitter and Slack. If you haven’t followed me on Twitter please use this link to follow me.

DFS channels and why to avoid them (even though you say you cannot)

DFS channels and why to avoid them (even though you say you cannot)

These days most wireless guys say they cannot stick to only 8 channels. Most people agree that you should use all 26 channels (including all the DFS channels). The truth is you can use an 8-channel plan if you use 20 MHz wide channels exclusively. I know …I know every marketing person, every manager and every user just lost their collective minds. Everyone wants to use 80 and 160 MHz wide channels and most people (even Wi-Fi people) want to use 40 MHz channels everywhere. If you use wide channels then you cannot stick to an 8-channel plan. On the other hand, if you agree that using 20 MHz channels is a more efficient use of the channels and spectrum, then you can very easily get away with using only 8 channels.

There are 9 non-DFS channels but when you use channel 165 (the highest channel in UNII-3) you may run into issues since there is not enough separation between Channel 165 and UNII-4 band channels. This has been known to cause issues, especially with voice clients. I always recommend staying away from channel 165 which leaves us with an 8-channel plan (36, 40, 44, 48, 149, 153, 157, and 161).

Back in the day when we used 2.4 GHz only networks, you were limited to only 3 channels, and despite this people more clever than, I got it to work with very few issues. Yes, there was always co-channel interference, but the better engineers would work to minimize it. In 5 GHz, suddenly using 8 channels is big a hassle for most people. Have we gotten lazy, or have we bought into the lie that wider channels are better? I will save my arguments for why 40MHz channels are highly inefficient for another blog. If you do not want to wait, you can look at Devin Akin’s blog at https://divdyn.com/wi-fi-throughput/ he does an amazing job diving into this point.

DFS Channels

What is a DFS channel? These channels share the spectrum with Weather Radar and Radar systems. For the FCC and IEEE to approve the use of these channels in WIFI, a mechanism had to be in place where these channels could co-exist. A mechanism called DFS (Dynamic Frequency Selection) was created to have the WIFI devices listen for radar events and either stop using the channels or automatically move off these channels. When RRM/ARM is used, and an AP hears a radar event it must pick a new channel and inform its clients to move to this new channel. If RRM/ARM is not used, then AP after hearing a radar event must stop transmitting for 30 minutes.

Why are DFS channels so bad?

There are 16 DFS channels in the UNII-2 and UNII-2e space (52, 56, 60, 64, 100, 104, 108, 112, 116, 120, 124, 128, 132, 136, 140, and 144). These channels have two major drawbacks, especially for voice clients. These drawbacks are 1.) The length of time it takes for a client to scan DFS channels. 2.) When radar events are heard the APs and device must move off that channel. The rest of this blog I will talk about these two issues.

The first issue is how long it takes a client to scan the DFS channels. This changes a bit with different clients but since I know the Vocera devices I will use them as an example. When the Vocera badge scans non-DFS channels, it immediately sends a probe request and gets back a probe response this takes roughly 15 – 20ms per channel. The device must return to its original channel for 50ms to do any TX/RX it may need. The total time to scan each channel is 65ms. When you multiply 65ms by 8 channels you get a total scan time of 520ms. When the badge scans a DFS channel it cannot send a probe right away. It must make sure there is no radar on this channel. It does this by listening for a beacon (100 – 104ms). The device will then send a Probe Request and receive a Probe Response only after it hears a beacon. Since it has stayed off its channel so long it needs to return to its original channel for 150ms for any Tx/Rx. The round trip time for every channel is roughly 250ms. When you multiply 250ms by 16 channels you get a total scan time of 4000ms (4 seconds). Four seconds may seem like a short time but, for a voice client that has a jitter buffer of 120ms, a 4-second delay can seem like a lifetime. When the device is in the middle of a call and needs to find another AP to roam to a delay beyond 120ms will cause choppy audio. It will take even longer if you hide the SSID since the badge must take an extra step of sending a Probe Request with the wildcard in it so all APs will respond.

This improves greatly when you have 802.11k enabled. When using 802.11k after the device connects to the AP it will request a Neighbor list. This neighbor list will (normally…if everything is working right) contain a list of APs that are its closest neighbors. This will cut down the number of channels the device has to scan. If the device happens to move away from all the APs in the neighbor list it will need to do a full scan.

The second issue with DFS channels is when a DFS event occurs (or even a false positive happens) the AP must send out a channel change announcement which tells the devices that it must move. Most clients will treat this as a new roaming event without the benefit of pre-scanning the channels before the move. They will have to rescan all the channels instead of just the one where the AP is moving to. If you are a laptop surfing the internet or reading email you may never notice the delay but if you are a voice client in the middle of a call you will experience choppy audio during the forced roam.

In conclusion, stick with 20 MHz channels and use only the 8 Non-DFS channels. By doing this you will avoid all the issues that come along with the DFS channels. If your devices or applications need to move massive amounts of data, either stick a cable in it or switch over to Wi-Fi 6e and you can have all the bonded channels you want. You will not have to worry about the fact you are running highly inefficient bonded channels until you start using 320 MHz bonded channels and Wi-Fi 6e will be down to 4 channels and this will restart the discussion all over bonded channels again.