On 31.07.2024 14:20, Bitterblue Smith wrote:
On 31/07/2024 03:47, Ping-Ke Shih wrote:
Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> wrote:
On 30/07/2024 09:33, Ping-Ke Shih wrote:
Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> wrote:
In AP mode, the firmware stops transmitting beacons if it receives
H2C_CMD_RA_INFO for macid 0.
Leave macid 0 unused in AP mode. Macid 1 is already reserved for
broadcast/multicast. Assign macid 2 to the first connected client.
Seemingly we missed to set mac_id in TX desc for a long time.
+#define RTW_TX_DESC_W1_MACID GENMASK(7, 0)
#define RTW_TX_DESC_W1_QSEL GENMASK(12, 8)
#define RTW_TX_DESC_W1_RATE_ID GENMASK(20, 16)
The mac_id should be from rtwvif->mac_id or si->mac_id according to
operating mode and role.
And I suppose mac_id assignment for AP is mac_id 0 for broadcast/multicast, and
other mac_id can be used by connected stations regularly.
What about the concurrent AP + station scenario? Will the
station vif use the next available macid, whatever that is?
Just wondering, I don't use concurrent mode.
My basic idea is to assign mac_id to each vif when adding vif. For station mode,
sta->mac_id will reuse vif->mac_id. For AP mode, I will dynamically allocate an
sta->mac_id to a station, and vif->mac_id is to send broadcast/multicast packets
that are not belong to a sta. For example,
vif->mac_id sta->mac_id
vif0 (STA mode) 0 0
vif1 (AP mode) 1 2...
Also, do you mean that you will do all this? It's not clear to me.
I can do it. Or are you interested in this?
No, no, it's all yours. :)
It would be nice to have either this submitted fix or alternative one merged soon
since the AP mode is completely broken otherwise (at least on RTL8821CU).
Thanks,
Maciej
