Hello,
I currently have 7 Banana Pi R3 in use and a few days ago I noticed problems with the 2.4GHz module (MT7975N). Some clients have severe problems to get more than 20mbit in download direction (coming from WAN). The upload, however, does not seem to be affected. It does not matter whether both devices are in an interference-free environment or not. An iperf3 test between BPI and client shows that the TX direction of the BPI has to deal with a lot of retries. In a 30 second test I get 1550 retries. The bandwidth fluctuates between 20-50mbit. The RX direction of the BPI, on the other hand, is not affected and shows just 20 retries after 30 seconds. The bandwidth remains constant at over 90mbit.
The BPIs are configured as an access point. I was able to test the behavior with an HTC U12 Plus, OnePlus 10 Pro and a Samsung Galaxy A32. However, the behavior does not occur with a Surface Pro 3. Here I hardly see any RX/TX retries and the bandwidth remains constant at around 90 mbit. The download direction coming from the WAN also reaches its maximum bandwidth here.
An iw station dump showed that the affected devices very frequently switch to 6 mbit in the RX path. This also occurs during the iperf3 test. So under “full load”. I therefore suspect a problem with the power save of the client. I took a look at the QoS Null function frames. In the period of the problems I see a lot of frames where the power management bit changes back and forth between 1 and 0. In addition, the bit for frame retransmition is sometimes set.
The following is also very curious: If the iperf3 test is running and the client is put into standby, the retries stop immediately and the bandwidth stabilizes at 90-100mbit. But only while the test is still running. This behavior can also be observed if, for example, the Bluetooth is deactivated on the respective client during the iperf3 test or the visibility of the device via Bluetooth is switched off. However, interference with the Bluetooth on the client can be ruled out as the behavior occurs again as soon as a new iperf3 test is started. It is then irrelevant whether the Bluetooth is still deactivated or not. The retries can be observed again. Presumably, deactivating Bluetooth on the device only causes the device to stop switching to power save while the iperf3 test is running.
The behavior can be observed with the current OpenWRT snapshot as well as with the sinovoip firmware with the Mediatek OEM driver. (mtk-bpi-r3-image-20220601)
The 5Ghz module is not affected by this problem. All connected clients work here without any problems. The behavior of the affected clients cannot be observed with other access points with other 2.4GHz chipsets. This does not appear to be a general problem with the clients themselves.