RE: [PATCH RFC net-next 0/2] wifi: rtw89: fix monitor mode RX filtering and enable raw packet injection

[Ping-Ke Shih <pkshih@realtek.com>]

ph4ntom-rev <owner@ph4ntom-rev.uz> wrote:
> More specifically:
> 1. In R_AX_RX_FLTR_OPT (0xCE20), B_AX_A_CRC32_ERR must be unmasked whenever
>    mac80211 passes FIF_FCSFAIL, which is necessary to capture corrupted/aborted
>    ACKs and RTS/CTS frames in noisy air.

I thought the B_AX_SNIFFER_MODE set should be included CRC_ERR packets. I'll
check this internally.

> 2. If B_AX_SNIFFER_MODE is enabled on Band 0 without setting promiscuous matching
>    in the Address CAM, non-matching BSSID control frames are filtered at the MAC
>    CAM layer prior to reaching the R_AX_CTRL_FLTR routing logic.
> 
> For reference on our RTL8852AE test system (PCI ID [10ec:8852], HP subsystem
> [103c:88e1]), the default register values on channel 5 after monitor mode entry
> without our patch:
>   R_AX_RX_FLTR_OPT (0xCE20): 0x00020000  (B_AX_SNIFFER_MODE set, CRC32 error dropped)
>   R_AX_CTRL_FLTR   (0xCE24): 0x55555555
>   R_AX_MGNT_FLTR   (0xCE28): 0x55555555
>   R_AX_DATA_FLTR   (0xCE2C): 0x55555555

The 0xCE20 I can see is different from yours: (kernel 7.1.5 without any change)

1860ce20h : 03174438 55555555 55555555 55555555

If I use the latest driver, the bit B_AX_SNIFFER_MODE is enabled (after 7.2):

1860ce20h : 03174439 55555555 55555555 55555555

Can you try the latest kernel without any modification?

> > I did similar steps with program written in C, but no problem.
> > Could you share the simple Python raw socket script as attachment that you can
> > reproduce NULL vif pointer in your side? (I think radiotap_null_data_frame above
> > is a pseudo code).
> >
> > Does every injection cause NULL vif? Or some under certain conditions?
> > In my side, I have never seen that with raw_socket injection.
> 
> The difference comes down to how the monitor interface was instantiated:
> - If a monitor interface is created as a virtual sub-interface alongside an
>   existing station interface (e.g., `iw dev wlan0 interface add mon0 type monitor`),
>   mac80211 may retain an associated sdata/vif reference.
> - However, when the physical interface itself is switched directly into a pure,
>   standalone monitor mode:
>     # ip link set wlan0 down
>     # iw dev wlan0 set type monitor
>     # ip link set wlan0 up
>   In this mode, net/mac80211/tx.c (ieee80211_monitor_start_xmit()) is called
>   without an associated operational VIF. Consequently, mac80211 explicitly sets
>   info->control.vif = NULL.

My test results are the opposite of yours.

The standalone works well to me, no vif = NULL case. 

For concurrent wlan0 + mon0 case. I up two interfaces, and run your script on
each of them. 
If I did inject on wlan0, it obviously can't send out because vif type isn't
monitor. 
If I did inject on mon0, it crashes as what your first patch want to prevent.

But anyway, I have seen what you want to fix.