| Message ID | 20190122110858.12993-1-zajec5@gmail.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Kalle Valo |
| Headers | show |
| Series | brcmfmac: support monitor frames with hardware/ucode header | expand |
On 1/22/2019 12:08 PM, Rafał Miłecki wrote: > From: Rafał Miłecki <rafal@milecki.pl> > > The new FullMAC firmwares for 4366b1/4366c0 were supposed to provide > monitor frames with radiotap header but it doesn't seem to be the case. I was not aware that this was supposed to. I did not build a radiotap variant to keep it feature-wise similar to 4366b0 firmware. > Testing the latest release resulted in discovering a new format being > used. It seems (almost?) identical to the one known from ucode used in > SoftMAC devices which is most likely the same codebase anyway. I am a bit confused. How many formats are there? It is either ucode format or radiotap, right? > While radiotap support was meant to be announced with the "rtap" fw > capability string it seems no alternative was added for the hw/ucode > format. It means each firmware requires a feature mapping quirk. I thought we only needed a quirk for the firmware that provide radiotap but do not announce it. For the others we can assume ucode format if monitor mode is supported. Probably missing something. Regards, Arend
On 2019-01-25 09:51, Arend Van Spriel wrote: > On 1/22/2019 12:08 PM, Rafał Miłecki wrote: >> From: Rafał Miłecki <rafal@milecki.pl> >> >> The new FullMAC firmwares for 4366b1/4366c0 were supposed to provide >> monitor frames with radiotap header but it doesn't seem to be the >> case. > > I was not aware that this was supposed to. I did not build a radiotap > variant to keep it feature-wise similar to 4366b0 firmware. Well, then apparently I got confused :( When you wrote: On Mon, 11 Jun 2018 at 12:48, Arend van Spriel <arend.vanspriel@broadcom.com> wrote: > Looking into our firmware repo it there are two flags, ie. WL_MONITOR > and WL_RADIOTAP. It seems both are set for firmware containing -stamon- > feature. Your list below confirms that. I still plan to add indication > for WL_RADIOTAP in the "cap" iovar, but a stamon feature check could be > used for older firmwares. I assumed you'll add "rtap" cap value (to the internal wl code repository?) because you mean to release a firmware using it. Maybe you just meant it to be for your customers compiling firmwares on their own? >> Testing the latest release resulted in discovering a new format being >> used. It seems (almost?) identical to the one known from ucode used in >> SoftMAC devices which is most likely the same codebase anyway. > > I am a bit confused. How many formats are there? It is either ucode > format or radiotap, right? So far we got two formats: 1) 802.11 frames (with frame (sub)type & all addresses) 2) 802.11 frames with the radiotap header and now we also have: 3) 802.11 frames with the ucode header For more info please check my original post: Research + questions on brcmfmac and support for monitor mode https://www.spinics.net/lists/linux-wireless/msg173573.html >> While radiotap support was meant to be announced with the "rtap" fw >> capability string it seems no alternative was added for the hw/ucode >> format. It means each firmware requires a feature mapping quirk. > > I thought we only needed a quirk for the firmware that provide > radiotap but do not announce it. For the others we can assume ucode > format if monitor mode is supported. Probably missing something. 802.11 frames with ucode header is something entirely new, I didn't see any Asus/Linksys/Netgear/TP-LINK firmware using it. As the old firmwares were providing frames without any header (also making it impossible to e.g. read signal strength) we need this new flag to distinguish firmwares with ucode header from them.
On 1/25/2019 10:11 AM, Rafał Miłecki wrote: > On 2019-01-25 09:51, Arend Van Spriel wrote: >> On 1/22/2019 12:08 PM, Rafał Miłecki wrote: >>> From: Rafał Miłecki <rafal@milecki.pl> >>> >>> The new FullMAC firmwares for 4366b1/4366c0 were supposed to provide >>> monitor frames with radiotap header but it doesn't seem to be the case. >> >> I was not aware that this was supposed to. I did not build a radiotap >> variant to keep it feature-wise similar to 4366b0 firmware. > > Well, then apparently I got confused :( When you wrote: > > On Mon, 11 Jun 2018 at 12:48, Arend van Spriel > <arend.vanspriel@broadcom.com> wrote: >> Looking into our firmware repo it there are two flags, ie. WL_MONITOR >> and WL_RADIOTAP. It seems both are set for firmware containing -stamon- >> feature. Your list below confirms that. I still plan to add indication >> for WL_RADIOTAP in the "cap" iovar, but a stamon feature check could be >> used for older firmwares. > > I assumed you'll add "rtap" cap value (to the internal wl code repository?) > because you mean to release a firmware using it. > > Maybe you just meant it to be for your customers compiling firmwares on > their own? and for customer for whom we compile firmwares based on their feature requirements. Anyway, I could build a new firmware for 4366b1/4366c0 including radiotap. However, end-users may get to use firmware that is not supporting it. >>> Testing the latest release resulted in discovering a new format being >>> used. It seems (almost?) identical to the one known from ucode used in >>> SoftMAC devices which is most likely the same codebase anyway. >> >> I am a bit confused. How many formats are there? It is either ucode >> format or radiotap, right? > > So far we got two formats: > 1) 802.11 frames (with frame (sub)type & all addresses) > 2) 802.11 frames with the radiotap header > and now we also have: > 3) 802.11 frames with the ucode header > > For more info please check my original post: > Research + questions on brcmfmac and support for monitor mode > https://www.spinics.net/lists/linux-wireless/msg173573.html I did read that before, but apparently did miss some details. >>> While radiotap support was meant to be announced with the "rtap" fw >>> capability string it seems no alternative was added for the hw/ucode >>> format. It means each firmware requires a feature mapping quirk. >> >> I thought we only needed a quirk for the firmware that provide >> radiotap but do not announce it. For the others we can assume ucode >> format if monitor mode is supported. Probably missing something. > > 802.11 frames with ucode header is something entirely new, I didn't see any > Asus/Linksys/Netgear/TP-LINK firmware using it. > > As the old firmwares were providing frames without any header (also making > it impossible to e.g. read signal strength) we need this new flag to > distinguish firmwares with ucode header from them. Right. Thanks for explaining (again). Regards, Arend
Rafał Miłecki wrote: > From: Rafał Miłecki <rafal@milecki.pl> > > The new FullMAC firmwares for 4366b1/4366c0 were supposed to provide > monitor frames with radiotap header but it doesn't seem to be the case. > Testing the latest release resulted in discovering a new format being > used. It seems (almost?) identical to the one known from ucode used in > SoftMAC devices which is most likely the same codebase anyway. > > While radiotap support was meant to be announced with the "rtap" fw > capability string it seems no alternative was added for the hw/ucode > format. It means each firmware requires a feature mapping quirk. > > As for now only an empty radiotap is being created. Adding support for > extracting some info (band, channel, signal, etc.) is planned for the > future. > > Signed-off-by: Rafał Miłecki <rafal@milecki.pl> It's unclear what I should do with this patch, take it?
On Thu, 7 Feb 2019 at 17:36, Kalle Valo <kvalo@codeaurora.org> wrote: > Rafał Miłecki wrote: > > > From: Rafał Miłecki <rafal@milecki.pl> > > > > The new FullMAC firmwares for 4366b1/4366c0 were supposed to provide > > monitor frames with radiotap header but it doesn't seem to be the case. > > Testing the latest release resulted in discovering a new format being > > used. It seems (almost?) identical to the one known from ucode used in > > SoftMAC devices which is most likely the same codebase anyway. > > > > While radiotap support was meant to be announced with the "rtap" fw > > capability string it seems no alternative was added for the hw/ucode > > format. It means each firmware requires a feature mapping quirk. > > > > As for now only an empty radiotap is being created. Adding support for > > extracting some info (band, channel, signal, etc.) is planned for the > > future. > > > > Signed-off-by: Rafał Miłecki <rafal@milecki.pl> > > It's unclear what I should do with this patch, take it? It seems to me there are no objections regarding the code. It was only my commit message that was a bit confusing. I'll send V2 with updated commit message.
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c index 860a4372cb56..e772c0845638 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c @@ -43,6 +43,36 @@ #define BRCMF_BSSIDX_INVALID -1 +#define RXS_PBPRES BIT(2) + +#define D11_PHY_HDR_LEN 6 + +struct d11rxhdr_le { + __le16 RxFrameSize; + u16 PAD; + __le16 PhyRxStatus_0; + __le16 PhyRxStatus_1; + __le16 PhyRxStatus_2; + __le16 PhyRxStatus_3; + __le16 PhyRxStatus_4; + __le16 PhyRxStatus_5; + __le16 RxStatus1; + __le16 RxStatus2; + __le16 RxTSFTime; + __le16 RxChan; + u8 unknown[12]; +} __packed; + +struct wlc_d11rxhdr { + struct d11rxhdr_le rxhdr; + __le32 tsf_l; + s8 rssi; + s8 rxpwr0; + s8 rxpwr1; + s8 do_rssi_ma; + s8 rxpwr[4]; +} __packed; + char *brcmf_ifname(struct brcmf_if *ifp) { if (!ifp) @@ -409,6 +439,31 @@ void brcmf_netif_mon_rx(struct brcmf_if *ifp, struct sk_buff *skb) { if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MONITOR_FMT_RADIOTAP)) { /* Do nothing */ + } else if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MONITOR_FMT_HW_RX_HDR)) { + struct wlc_d11rxhdr *wlc_rxhdr = (struct wlc_d11rxhdr *)skb->data; + struct ieee80211_radiotap_header *radiotap; + unsigned int offset; + u16 RxStatus1; + + RxStatus1 = le16_to_cpu(wlc_rxhdr->rxhdr.RxStatus1); + + offset = sizeof(struct wlc_d11rxhdr); + /* MAC inserts 2 pad bytes for a4 headers or QoS or A-MSDU + * subframes + */ + if (RxStatus1 & RXS_PBPRES) + offset += 2; + offset += D11_PHY_HDR_LEN; + + skb_pull(skb, offset); + + /* TODO: use RX header to fill some radiotap data */ + radiotap = skb_push(skb, sizeof(*radiotap)); + memset(radiotap, 0, sizeof(*radiotap)); + radiotap->it_len = cpu_to_le16(sizeof(*radiotap)); + + /* TODO: 4 bytes with receive status? */ + skb->len -= 4; } else { struct ieee80211_radiotap_header *radiotap; diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c index 4c5a3995dc35..b91b7ecbfedf 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c @@ -103,6 +103,10 @@ static const struct brcmf_feat_fwfeat brcmf_feat_fwfeat_map[] = { { "01-6cb8e269", BIT(BRCMF_FEAT_MONITOR) }, /* brcmfmac4366b-pcie.bin from linux-firmware.git commit 52442afee990 */ { "01-c47a91a4", BIT(BRCMF_FEAT_MONITOR) }, + /* brcmfmac4366b-pcie.bin from linux-firmware.git commit 211de1679a68 */ + { "01-801fb449", BIT(BRCMF_FEAT_MONITOR_FMT_HW_RX_HDR) }, + /* brcmfmac4366c-pcie.bin from linux-firmware.git commit 211de1679a68 */ + { "01-d2cbb8fd", BIT(BRCMF_FEAT_MONITOR_FMT_HW_RX_HDR) }, }; static void brcmf_feat_firmware_overrides(struct brcmf_pub *drv) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h index 0b4974df353a..5e88a7f16ad2 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h @@ -35,6 +35,7 @@ * FWSUP: Firmware supplicant. * MONITOR: firmware can pass monitor packets to host. * MONITOR_FMT_RADIOTAP: firmware provides monitor packets with radiotap header + * MONITOR_FMT_HW_RX_HDR: firmware provides monitor packets with hw/ucode header */ #define BRCMF_FEAT_LIST \ BRCMF_FEAT_DEF(MBSS) \ @@ -52,7 +53,8 @@ BRCMF_FEAT_DEF(GSCAN) \ BRCMF_FEAT_DEF(FWSUP) \ BRCMF_FEAT_DEF(MONITOR) \ - BRCMF_FEAT_DEF(MONITOR_FMT_RADIOTAP) + BRCMF_FEAT_DEF(MONITOR_FMT_RADIOTAP) \ + BRCMF_FEAT_DEF(MONITOR_FMT_HW_RX_HDR) /* * Quirks: