The latest generation of mobile devices, including the Apple iPhone 4S, may be causing performance degradation on your Wi-Fi network, which could be reported as a Denial of Service (DoS) attack by WIPS (wireless intrusion prevention systems).
One of my blog readers contacted me about a disturbing finding he had and asked for my opinion (thanks Thanh). The finding in question was that the Apple iPhone, iPad, and other mobile devices based on the latest Broadcom chipsets are setting really long Duration values in the range of 10-14ms within Wi-Fi control frames (e.g. RTS/CTS-to-self). This essentially reserves the medium for the device to transmit without a collision. The problem is that this is an excessively long period of time for an 802.11n capable device, and through my packet analysis I have found that no large frame transmission is subsequently occurring. This indicates that a performance problem may exist with the devices, and may be reported as an NAV DoS attack on the network by WIPS systems.
I've also heard anecdotal reports of this being observed on HTC Google Nexus One, Apple iPad 2, iPhone 4, some RIM Blackberrys, and even on a Broadcom evaluation board. So, there is a distinct possibility that this issue lies in the Broadcom chipset used in these devices and is not isolated to Apple devices. However, I have only tested this on my personal iPhone 4S and cannot directly verify those observations. So this post only details what I have actual been able to test and observe directly.
I had a hard time believing this could be true, so I investigated myself. Sure enough, I found the behavior when I tested.
What you see in the figure above is that the iPhone transmits CTS-to-Self frames at regular intervals, around once every second, with an excessively large Duration value. This causes all other Wi-Fi clients to set the NAV (virtual carrier sense) to the specified Duration value and defer transmission. Essentially, my iPhone was causing a blockage of all traffic on my wireless network for 11ms at regular intervals. Definitely not good for performance.
Possible valid explanations for this behavior could be:
1) Frame aggregation with 802.11n. I did see the iPhone using frame aggregation in other instances and using an appropriate Duration value around 4ms in those cases. But I did not see frame aggregation being used after the 11ms Duration control frames.
2) The use of a Transmit Opportunity (TXOP) on a QoS enabled WLAN in order to transmit a burst of packets within a specific QoS traffic class. I double-checked the TXOP values advertised by my access point and they are using the 802.11 default values of 0ms (single frame only) for best effort and background queues, 3.008ms for the video queue, and 1.504ms for the voice queue, which are much lower than the 11ms observed value.
3) A really large frame transmitted at a really low data rate. This is possible if the iPhone needed to transmit a 1,384 byte or larger frame at 1 Mbps to get such a Duration value. But I have all 802.11b rates disabled on my AP and verified in the packet trace that the iPhone was using 24 - 65 Mbps almost all the time, with only a few frames at my lowest available data rate of 6 Mbps.
After analyzing my packet trace I can find no evidence of my iPhone transmitting any data frames immediately after the control frame containing the high Duration value. This essentially rules out all three possible explanations.
Other possible explanations would be a poor client roaming algorithm that wants to halt traffic while it goes off-channel to scan for other APs to which it could roam, or a poorly designed battery saving technique for mobile devices. However, I captured on all three non-overlapping 2.4GHz channels and found no evidence of my iPhone probing on other channels during that 11ms time period. And using this as a battery saving technique doesn't even make a whole lot of sense because clients can already notify the AP of it's power save mode and the AP will buffer traffic until it wakes up, or at worst case send broadcast traffic at the configured DTIM interval, which is usually 102ms which allows for a much longer sleep period anyways. Regardless, the iPhone indicated that it was staying awake (in active mode) in the control frames, so it appears to have not been putting the radio to sleep.
Frankly, I have no answer to explain this behavior. I don't exactly know what is going on.
The effect on a home network is likely to be small, since 11ms out of every 1 second is only about 1% of available airtime. However, in a corporate environment where mobile devices are being introduced into the environment at a staggering rate, the compound effect could be a serious reduction in Wi-Fi network performance and capacity! Think of having 30 students in a single classroom all connected with their mobile devices, 200 in a university lecture hall, or 500 at a trade show or conference. This is increasingly likely as smartphone and mobile device penetration is over 50% in the U.S. and other countries already, and consumers are typically carrying 2-3 Wi-Fi enabled devices with them at all time. The worst-case result in these environments would be so much reserved airtime that almost no network capacity would be left for actual user traffic. Just what we need trying to support tons of mobile devices on enterprise networks, huh.
If I uncover more details, I will update this post accordingly.
Thanks,
Andrew vonNagy
One of my blog readers contacted me about a disturbing finding he had and asked for my opinion (thanks Thanh). The finding in question was that the Apple iPhone, iPad, and other mobile devices based on the latest Broadcom chipsets are setting really long Duration values in the range of 10-14ms within Wi-Fi control frames (e.g. RTS/CTS-to-self). This essentially reserves the medium for the device to transmit without a collision. The problem is that this is an excessively long period of time for an 802.11n capable device, and through my packet analysis I have found that no large frame transmission is subsequently occurring. This indicates that a performance problem may exist with the devices, and may be reported as an NAV DoS attack on the network by WIPS systems.
I've also heard anecdotal reports of this being observed on HTC Google Nexus One, Apple iPad 2, iPhone 4, some RIM Blackberrys, and even on a Broadcom evaluation board. So, there is a distinct possibility that this issue lies in the Broadcom chipset used in these devices and is not isolated to Apple devices. However, I have only tested this on my personal iPhone 4S and cannot directly verify those observations. So this post only details what I have actual been able to test and observe directly.
I had a hard time believing this could be true, so I investigated myself. Sure enough, I found the behavior when I tested.
 |
| Apple iPhone 4S Large Duration Value |
What you see in the figure above is that the iPhone transmits CTS-to-Self frames at regular intervals, around once every second, with an excessively large Duration value. This causes all other Wi-Fi clients to set the NAV (virtual carrier sense) to the specified Duration value and defer transmission. Essentially, my iPhone was causing a blockage of all traffic on my wireless network for 11ms at regular intervals. Definitely not good for performance.
Possible valid explanations for this behavior could be:
1) Frame aggregation with 802.11n. I did see the iPhone using frame aggregation in other instances and using an appropriate Duration value around 4ms in those cases. But I did not see frame aggregation being used after the 11ms Duration control frames.
2) The use of a Transmit Opportunity (TXOP) on a QoS enabled WLAN in order to transmit a burst of packets within a specific QoS traffic class. I double-checked the TXOP values advertised by my access point and they are using the 802.11 default values of 0ms (single frame only) for best effort and background queues, 3.008ms for the video queue, and 1.504ms for the voice queue, which are much lower than the 11ms observed value.
3) A really large frame transmitted at a really low data rate. This is possible if the iPhone needed to transmit a 1,384 byte or larger frame at 1 Mbps to get such a Duration value. But I have all 802.11b rates disabled on my AP and verified in the packet trace that the iPhone was using 24 - 65 Mbps almost all the time, with only a few frames at my lowest available data rate of 6 Mbps.
After analyzing my packet trace I can find no evidence of my iPhone transmitting any data frames immediately after the control frame containing the high Duration value. This essentially rules out all three possible explanations.
Other possible explanations would be a poor client roaming algorithm that wants to halt traffic while it goes off-channel to scan for other APs to which it could roam, or a poorly designed battery saving technique for mobile devices. However, I captured on all three non-overlapping 2.4GHz channels and found no evidence of my iPhone probing on other channels during that 11ms time period. And using this as a battery saving technique doesn't even make a whole lot of sense because clients can already notify the AP of it's power save mode and the AP will buffer traffic until it wakes up, or at worst case send broadcast traffic at the configured DTIM interval, which is usually 102ms which allows for a much longer sleep period anyways. Regardless, the iPhone indicated that it was staying awake (in active mode) in the control frames, so it appears to have not been putting the radio to sleep.
Frankly, I have no answer to explain this behavior. I don't exactly know what is going on.
The effect on a home network is likely to be small, since 11ms out of every 1 second is only about 1% of available airtime. However, in a corporate environment where mobile devices are being introduced into the environment at a staggering rate, the compound effect could be a serious reduction in Wi-Fi network performance and capacity! Think of having 30 students in a single classroom all connected with their mobile devices, 200 in a university lecture hall, or 500 at a trade show or conference. This is increasingly likely as smartphone and mobile device penetration is over 50% in the U.S. and other countries already, and consumers are typically carrying 2-3 Wi-Fi enabled devices with them at all time. The worst-case result in these environments would be so much reserved airtime that almost no network capacity would be left for actual user traffic. Just what we need trying to support tons of mobile devices on enterprise networks, huh.
If I uncover more details, I will update this post accordingly.
Thanks,
Andrew vonNagy
