Ezra Buehler <ezra@xxxxxxxx> wrote: > > On 19 Feb 2025, at 18:52, Ezra Buehler <ezra@xxxxxxxx> wrote: > > > > From: Ezra Buehler <ezra.buehler@xxxxxxxxxxxxxxxxxx> > > > > As mentioned in the previous patch [1], especially the transmit rate is > > rather low in AP mode with gen1 devices like the RTL8192CU. The > > following changes seem to fix the issue. > > > > When looking at the patches introducing the initial AP support [2], I > > noticed that rtl8xxxu_gen2_report_connect() was altered too. So, now I > > am wondering if we need to use `macid` and `role` in > > rtl8xxxu_gen1_report_connect() as well... > > > > [1]: https://lore.kernel.org/all/20250122071512.10165-1-ezra@xxxxxxxx/ > > [2]: https://lore.kernel.org/all/20230428150833.218605-1-martin.kaistra@xxxxxxxxxxxxx/ > > > > > > Ezra Buehler (3): > > wifi: rtl8xxxu: Use macid in rtl8xxxu_update_rate_mask() > > wifi: rtl8xxxu: Use macid in rtl8xxxu_fill_txdesc_v1() > > wifi: rtl8xxxu: Make sure TX rate is reported in AP mode > > > > drivers/net/wireless/realtek/rtl8xxxu/core.c | 28 ++++++++++++++++++- > > .../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 1 + > > 2 files changed, 28 insertions(+), 1 deletion(-) > > > > — > > 2.43.0 > > I apologize for the radio silence. It turned out that these changes do > not improve things. I must have made a mistake when measuring throughput > back then. > > When testing the TX rate (with iperf3), I see the throughput constantely > dropping to 0 bits/sec. This makes AP mode unusable even for our > non-data-heavy use case. > > Do you have any suggestions where to dig deeper to get to the bottom of > this? Testing with single one station connected would be easier to address problem, and ensure mac_id is always 1 for AP mode transmitting packets to the station. Also, you need a sniffer to check PHY rate if it can keep. As well as the rate when throughput dropped. If rate is good, check any misbehavior of air packets. Before all above, please ensure the PHY rate is good when it plays as a station mode.
