Macbook pro RTS data rate not belong to AP's basic rate set
Last Post: March 28, 2020:
-
AP advertised its basic rate set as following, don't support 6M:
Tag: Supported Rates 12(B), 18, 24, 36, 48, 54, [Mbit/sec]
Tag Number: Supported Rates (1)
Tag length: 6
Supported Rates: 12(B) (0x98)
Supported Rates: 18 (0x24)
Supported Rates: 24 (0x30)
Supported Rates: 36 (0x48)
Supported Rates: 48 (0x60)
Supported Rates: 54 (0x6c)And Macbook pro has associated the AP successfully, which means it knows and accepts the supported rates.
But the macbook pro constant sent RTS with 6M rate:
802.11 radio information
PHY type: 802.11a (OFDM) (5)
Turbo type: Non-turbo (0)
Data rate: 6.0 Mb/s
Channel: 52
Frequency: 5260MHz
Signal strength (dBm): -54dBm
Noise level (dBm): -95dBm
Signal/noise ratio (dB): 41dB
TSF timestamp: 162236858
[Duration: 52µs]
IEEE 802.11 Request-to-send, Flags: ........C
Type/Subtype: Request-to-send (0x001b)
Frame Control Field: 0xb400
.... ..00 = Version: 0
.... 01.. = Type: Control frame (1)
1011 .... = Subtype: 11
Flags: 0x00
.... ..00 = DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0 From DS: 0) (0x0)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = Protected flag: Data is not protected
0... .... = Order flag: Not strictly ordered
.000 0001 0001 1010 = Duration: 282 microseconds
Receiver address: Cisco_ba:33:ee (2c:33:11:ba:33:ee)
Transmitter address: Apple_4a:24:e0 (f0:18:98:4a:24:e0)
Frame check sequence: 0x0c2d050b [unverified]
[FCS Status: Unverified]This behavior caused the macbook pro constant ping loss. Why it sent RTS with a rate that doesn't belong to AP's basic rate set?
BTW: the macbook pro's version is 10.14.2, and 10.15.1 has the same problem as well. The AP model is Cisco AP2802i.
-
Obviously, the MACbook has either moved out of range of the AP, or for some other reason (noise ?) is experiencing communications problems since it first associated to the AP.
Apple has LONG been known to NOT obey the rules set in the 802.11 standard, when it (Apple) thinks it knows better. The FCC won't care about it, and neither will the IEEE. The WFA would not do much about it as long as it passes their test requirements.
In the final analysis, I'm sure the WFA test cases don't test for this specific case - or at least if it does recognize the behavior, it is not flagged as a FAIL - and therefore it "Passed" its Certification tests.
6 Mbps is the Lowest OFDM which, perhaps more importantly to Apple, also because it requires the lowest SNR it also provides the longest range.
Perhaps Apple's algorithms have already tried the higher rates and gave up on them. Knowing Apple somewhat, I doubt that. I think it's attempting to reconnect as quickly as possible - and to hell with the rules.
After all, Apple, and all other manufactures know, that if a device can "understand" 12 Mbps, it can also "understand" 6 Mbps.
Except for the fact that this behavior can interfere with other nearby AP's, I almost have to admire it. But, as I've had to diagnose problems on my own and other companies networks I can't give them a "free pass".
My concern is the best performance on the network overall, and the fact that this behavior could affect other networks I cannot condone it. I would hope the behavior is of short duration.
- 1