Raspberry Pi 5 in-built WiFi

Looking into traces of the Infineon CYW43455 WiFi inside the RPi5

Introduction

I just bought a couple of RPi5 boards to tinker around with, and I’m curious as to the capabilities of the WiFi interface on them. In this article we will capture and examine sniffer traces to try and understand a bit more about the WiFi interface on the RPi5.

This article assumes some familiarity with WiFi including basic packet exchanges, initial authentication and association, and how data aggregation works. Basic information on the steps involved (probing, authentication, association, key exchange, aggregation) are covered in many articles online, or offline in physical books such as Next Generation Wireless LANs by Eldad Perahia and Robert Stacey or 802.11ac: Wi-Fi at Gigabit and Beyond by Matthew Gast.

My RPi5 devices have the ‘bookworm’ Debian image version installed, running kernel version 6.6.20+rpt-rpi-2712.

RPi5 hardware

The RPi5 hardware is based on the Broadcom BCM2712, which is a quad-core Arm Cortex A76 processor, coupled with Infineon CYW43455 WiFi¹ via an SDIO interface.

The CYW43455 is driven by the Broadcom FullMAC Linux kernel driver. The IP inside the CYW43455 chip is originally from Broadcom, and presumably was obtained by Infineon through their purchase of Cypress in 2020, who in turn had purchased the Broadcom Wireless IoT division in 2016.

For differentiation between FullMAC and SoftMAC drivers, see my previous article on the Linux kernel WiFi stack basics.

WiFi connection

Configuration of the RPi5 WiFi can be done with the Raspberry Pi imager tool (prior to SD card flashing), or after the system is up-and-running using the network manager nmcli utility or via the GUI configurator.

I configured my RPi to connect to a Quantenna QSR10G based reference AP, located ~1m away from the RPi, configured with a WPA2 pre-shared key.

The traces I captured during my analysis and testing can be found on Google Drive, here. These traces were captured on a Macbook Pro M2, which has a 2x2 802.11ac WiFi interface.

Diving into the traces, I’ll mention packet numbers and provide screen snips as reference to highlight interesting points.

Initial connection

The initial connection (trace here) consists of the probe request/response exchanges, authentication request/response exchanges and association request/response exchanges. After this point, for WPA2, the 4-way key exchange can be performed to establish the session keys and ensure link privacy.

Probe request/response exchanges are in packets 19-22, 24-27 and other places within the trace. Zooming into the probe requests from the RPi, we notice both the wildcard (broadcast) SSID (19, 21, 24-26, …) as well as the directed SSID QSR10G-XYZ (82, 95, 99, …) are probed. This is normal behaviour as per most of the client cards I have analysed over the years.

Authentication exchanges are seen twice, first at packet 87, a single authentication from the RPi to the AP is transmitted which goes unanswered. The second authentication exchange is in packets 171-173, which completes successfully.

The association request/response exchange is in packets 176-178, and completes on first attempt.

The 4-way EAPOL exchange is in packets 179-188. It should be noted that here that the initial transmit of the key exchange message 2 is unsuccessful (packet 180) as a second transmit of this message is seen in packet 185. The IEEE 802.1X Controlled Port (allowing normal data exchange) for the STA is unblocked after packet 188, being the final frame in the 4-way key exchange.

Some observations from this part of the trace:

1. The initial authentication frame (packet 87) and initial key 2 frame (packet 180) being unsuccessful could be related to the physical location of the devices, being very close together.

2. In packets 183-184 we see two broadcast packets from the RPi to the network, which violates the 802.11 STA authentication and association state machine (figure 11-17 in IEEE802.11 2020 edition²). It is clear these are transmitted by the AP due to their proximity to the DTIM beacon (186), and the use of the ‘more data’ bit and ‘from DS’ bit being set in the frame control header of packet 183. This issue lies purely in the AP implementation, these two transmissions from the RPi should be silently dropped as the IEEE 802.1X Controlled Port is closed until the EAPOL exchange completes successfully.

Data transfer

After the WPA2 exchange completes, we can see the establishment of block ACK agreements, which are required to allow data frames to be aggregated inside A-MPDUs and A-MSDUs, to make more efficient use of airtime. Establishment of the block ACK agreement usually involves the sending of a Block Ack Request (BAR) frame to initialise the first receive sequence number.

One thing which should be noted in the initial connection trace file is the number of multicast and broadcast frames which are regularly transmitted by the RPi. For example, the following packet pairs show the directed transmit from the RPi to the AP followed by the broadcast transmit from the AP to the BSS. The initial directed transfer is at high data rate, not such a major issue, but the retransmit into the BSS is at the lowest basic rate (6Mbps).

• Packet 192 (RPi→AP) 390Mbps; packet 232 (AP→BSS) 6Mbps

• Packet 199 (RPi→AP) 390Mbps; packet 233 (AP→BSS) 6Mbps

• Packet 216 (RPi→AP) 390Mbps; packet 234 (AP→BSS) 6Mbps

• Packet 218 (RPi→AP) 390Mbps; packet 235 (AP→BSS) 6Mbps

• Packet 227 (RPi→AP) 390Mbps; packet 236 (AP→BSS) 6Mbps

This is nothing out of the ordinary, it’s the usual IPv4/IPv6 network chatter for neighbor discovery or mDNS, but something which network engineers must be aware of because this background chatter can easily bring networks down if the multicast domains are not properly configured. I have experienced this first hand, as did the other 100 or so employees in the same building due to a badly configured network and hundreds of RPi devices chattering away.

Power saving

Looking at packet 249 we see a QoS NULL frame with the ‘power management’ bit of the frame control flags field set. This indicates the device is entering power save, and packets directed to this client should be buffered until the client wakes up. This is followed a few packets later by a QoS NULL with the ‘power management’ bit cleared, indicating the client is awake again. This is a common pattern throughout the trace, when the client is idle it will go to sleep through use of QoS NULL (fast power save), and wake up periodically.

An interesting sequence in the trace is packets 330→337. Here we see a number of packets being transmitted to the RPi and subsequently retried due to lack of acknowledgement by the RPi. However, from the trace we see no indication that the RPi is asleep. Note packet 326, which is a QoS NULL frame from the RPi with the power management bit cleared - the RPi is apparently awake. If the RPi was going to sleep then a directed (acknowledged) QoS NULL frame would be sent from the RPi to the AP, which would likely also be seen on the sniffer. Clearly the AP has not received any such QoS NULL or the packets 330→337 would not be transmitted in the first place. This is probably an issue in the CYW43455 firmware, and is a common issue I have encountered over the years.

Diving deeper

RPi5 WiFi capabilities

From the probe request (packet 84) and association request (packet 180) we can determine the capabilities of the RPi5. We will do this through examining several IEs. Note that for the HT and VHT capabilities IEs, we only examine the non-zero fields. Any fields not discussed below are zero and not really of interest for the CYW43455 device capabilities.

Using the below capability information fields and IEs, we can (generally) uniquely identify a WiFi client signature through the values set and not set.

Capability Information field (9.4.1.4)

The capability information field is present in the association request frame, and indicates basic information about the wireless client. The ESS bit is set (it is reserved in the context of non-IBSS STA), which is meaningless, and the STA also indicates the need for data privacy, or encryption to be supported. The other bit which is set in this field is Spectrum Management, which is generally a requirement when operating at 5GHz.

Supported rates IE (9.4.2.3)

This IE indicates support for 6, 9, 12, 18, 24, 36, 48 and 54Mbps legacy rates. Note: this is a 5GHz trace, so no 11b rates are present. No surprises here!

HT capabilities IE → HT Capability Information field (9.4.2.55.2)

The HT capability information field is part of the HT capabilities IE, and in the RPi5 case indicates the HT specific functionality which is supported by this device. In the case of the CYW43455 it supports LDPC coding for HT rates, 20 and 40MHz operation, and short GI for both 20 and 40MHz.

HT capabilities IE → A-MPDU parameters field (9.4.2.55.3)

The AMPDU parameters field is part of the HT capabilities IE, and this field indicates that the maximum HT aggregate supported on receive is 65535 - this being the maximum HT AMPDU length. Any value lower than this would indicate a less efficient device. The MPDU density setting indicates the required padding between MPDUs within the AMPDU, to allow the receiver to process the received MPDUs in real-time without suffering from overflow conditions on receive.

HT capabilities IE → Supported MCS set field (9.4.2.55.4)

The Supported MCS (Modulation and Coding Scheme) Set field is part of the HT capabilities IE, and provides the critical details of which HT Modulation and coding schemes the CYW43455 supports. ie, this shows which rates can be received.

From this IE we can tell the CYW43455 is a single spatial stream device (only the first byte of the RX MCS has non-zero values), and that the transmit MCSes are the same as those supported on receive, which is the typical case.

Extended Capabilities IE (9.4.2.26)

The extended capabilities element is an extension on the Capability Information field (9.4.1.4), and varies in length based on which version of the standard the given WiFi chipset is developed against.

For the CYW43455, there are only two additional extended capabilities supported: BSS transition (section REF) and Operating Mode Notification (section REF).

VHT capabilities IE → VHT Capability Information field (9.4.2.157.2)

The VHT capability information field within the VHT capabilities IE indicates the VHT specific features which are supported by the CYW43455. We can see a couple of interesting things here. First, the ‘Supported Channel Width Set’ indicates the device is up to 80MHz only. Second, the device is able to be a beamformee through ‘SU Beamformee Capable’ being set. Third, the maximum MPDU length supported is 11,454 bytes, the maximum supported MPDU length in 802.11ac, and the maximum A-MPDU length is 1,048,575 bytes, the maximum A-MPDU length supported in 802.11ac.

VHT capabilities IE → Supported VHT-MCS and NSS Set field (9.4.2.157.3)

The Supported VHT-MCS and NSS Set field is part of the VHT capabilities IE, and indicates the supported transmit and receive MCSes by the CYW43455. We see from this field that only single spatial stream MCSes are supported, as expected.

Aggregation support

To see how well the CYW43455 performs, I installed iperf on the RPi, and ran a series of tests downstream (AP→STA) and upstream (STA→AP). The setup is shown in the following diagram.

The following table gives test results for TCP downstream and upstream, with corresponding PHY efficiency calculations.

These results show us that the performance on the upstream is less stable than for downstream. For both downstream and upstream, the PHY efficiency (throughput to PHY rate ratio) is poor, hovering around the mid-50% level mostly. For good PHY efficiency I’d expect around 75% for TCP, 85% for UDP.

A sniffer trace was captured for each of the four downstream and four upstream runs, then run through my PCAP trace analyser tool to generate the following graphs. The downstream traces can be found here, the upstream traces can be found here.

PHY rate traces

The following two images are montages of all four runs in upstream and then downstream, and show the PHY rates on transmit of the TCP data from the RPi (upstream) and the AP (downstream). For the upstream TCP traces we can see the PHY rate is clean and remains stable around MCS 9 (433Mbps). For the downstream trace, we see that the PHY rate varies and remains mostly around MCS 8 (390Mbps).

Diving deeper into the downstream trace there are some telltale signs that the AP may be overloading the client receiver. One example of this can be seen in the packet exchanges around 41660→41708 in the iperf-down-4f.pcap file. We see an A-MPDU transmitted AP to RPi5 in packets 41660→41691 (32 subframes in length, 802.11 sequence numbers 1192→1223). However, the block ACK from the RPi5 to the AP indicates the end of the A-MPDU is lost - the ack covers all subframes up to and including sequence number 1208, meaning that 1209→1223 need to be retried. We see the retried A-MPDU in packets 41693→41707, which is sent at a lower PHY rate of MCS 7 (325Mbps). This pattern is repeated a number of times throughout the trace, which will eventually cause the AP to shift down to transmit using lower PHY rates.

One final point on the PHY rate analysis is that the AP is working much harder on the TCP downstream (more retransmits and at a lower PHY rate hence using much more airtime) to achieve marginally higher TCP performance than the upstream RPi5 to AP case.

TCP upstream (RPi5 to AP) PHY rates

TCP downstream (AP to RPi5) PHY rates

A-MPDU size traces

The following two images which are montages of all four runs in upstream and then downstream, show the aggregate subframe counts across the test run. Points to note are where traffic temporarily paused (graphs 1→3 for upstream, graph 2 for downstream), and that for downstream, the QSR10G device is more aggressive at aggregating large A-MPDUs. The majority of the A-MPDUs lie along the 32-subframe point in the graph, whereas for upstream the aggregate sizes are more smoothly distributed up to 32-subframes.

TCP upstream (RPi5 to AP) A-MPDU subframe counts and retries

TCP downstream (AP to RPi5) A-MPDU subframe counts and retries

The following two images show montages of the size in bytes of each MPDU and total A-MPDU. What we notice here is in the downstream direction from the AP→RPi5 we see many cases of suboptimal MPDU size, and indeed, in the traces we can see such packets from time-to-time (examples: iperf-down-4f.pcap packets 83112, 83206, 83342, …). This is likely related to the TCP windowing, as the transmitter and receivers use different operating systems, different TCP stacks, and different iperf versions (RPi5 with Linux 6.6.20 on one side, MacOS 10.15.7 on the other).

TCP upstream (RPi5 to AP) MPDU and A-MPDU sizes

TCP downstream (AP to RPi5) MPDU and A-MPDU sizes

Summary

The CYW43455 device inside the RPi5 is a wave 1 802.11ac device, which supports 80MHz, 1 spatial stream, and performs reasonably well in the low cost RPi5 single board computer.

The initial connection of the RPi5 to a Quantenna QSR10G based reference AP was analysed, and the device signature determined based on the capability fields and information elements present. Some minor issues with power save are seen with the CYW43455 WiFi device whereby a power save entry QoS NULL packet is not transmitted. However, this is a fairly common issue across clients I have debugged over the years.

Throughput testing of the RPi5 WiFi using iperf with TCP traffic was performed, and wireless sniffer traces analysed to uncover issues. From the examination of the PHY rates used, it seems that the QSR10G based AP can overload the RPi5 station, leading to PHY rate drops due to rate downshifting, which in turn is due to the inability of the RPi5 to keep up with the received packets. This is seen through ‘tail end’ A-MPDU dropping, which is generally a hint that the receiver is under-resourced.

Have you seen similar issues in your debug of WiFi problems before? Let me know in the comments.

Once again, thanks for reading and I hope you learned something from this! Constructive feedback or comments are always welcome.

1. https://www.infineon.com/cms/en/product/wireless-connectivity/airoc-wi-fi-plus-bluetooth-combos/wi-fi-5-802.11ac/cyw43455/

2. IEEE Standard for Information Technology — Telecommunications and Information Exchange between Systems Local and Metropolitan Area Networks — Specific Requirements.

Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications (IEEE Std 802.11™️‐2020) - https://ieeexplore.ieee.org/document/9363693