2023-12-21 22:29:51

by Matthias May

[permalink] [raw]
Subject: [PATCH] iw: strip NLA_FLAGS from printed bands

nl_band->nla_type might have NLA_F_NESTED (0x8000) set,
causing 'Bands' to be displayed with an according offset
when used directly.

Use the nla_type() macro instead to strip flags for
printing.

Signed-off-by: Zefir Kurtisi <[email protected]>
Signed-off-by: Matthias May <[email protected]>
---
info.c | 2 +-
phy.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/info.c b/info.c
index 317e7a3..5334436 100644
--- a/info.c
+++ b/info.c
@@ -354,7 +354,7 @@ static int print_phy_handler(struct nl_msg *msg, void *arg)
if (tb_msg[NL80211_ATTR_WIPHY_BANDS]) {
nla_for_each_nested(nl_band, tb_msg[NL80211_ATTR_WIPHY_BANDS], rem_band) {
if (last_band != nl_band->nla_type) {
- printf("\tBand %d:\n", nl_band->nla_type + 1);
+ printf("\tBand %d:\n", nla_type(nl_band) + 1);
band_had_freq = false;
}
last_band = nl_band->nla_type;
diff --git a/phy.c b/phy.c
index 4722125..ebd7289 100644
--- a/phy.c
+++ b/phy.c
@@ -52,7 +52,7 @@ static int print_channels_handler(struct nl_msg *msg, void *arg)
if (tb_msg[NL80211_ATTR_WIPHY_BANDS]) {
nla_for_each_nested(nl_band, tb_msg[NL80211_ATTR_WIPHY_BANDS], rem_band) {
if (ctx->last_band != nl_band->nla_type) {
- printf("Band %d:\n", nl_band->nla_type + 1);
+ printf("Band %d:\n", nla_type(nl_band) + 1);
ctx->width_40 = false;
ctx->width_80 = false;
ctx->width_160 = false;
--
2.39.2


2023-12-31 21:59:33

by Johannes Berg

[permalink] [raw]
Subject: Re: [PATCH] iw: strip NLA_FLAGS from printed bands

On Thu, 2023-12-21 at 22:29 +0000, Matthias May wrote:
> nl_band->nla_type might have NLA_F_NESTED (0x8000) set,

I'm curious - how does that happen?

Not that the change looks wrong per se, but ... I don't think this can
happen?

johannes


2024-01-05 20:37:09

by Johannes Berg

[permalink] [raw]
Subject: Re: [PATCH] iw: strip NLA_FLAGS from printed bands

On Fri, 2024-01-05 at 21:35 +0100, Matthias May wrote:
> We saw that happen on one of our platforms where we are forced to use an
> out-of-tree driver by QCA (SPF12.2).
> If you think this is something that can not happen with upstream
> drivers, feel free to ignore this patch.
>

It should be independent of drivers, so they must have modified cfg80211
to explicitly use the nla_put_nested() instead of
nla_put_nested_noflag()? It's just ... weird.

johannes

2024-01-05 20:43:02

by Matthias May

[permalink] [raw]
Subject: Re: [PATCH] iw: strip NLA_FLAGS from printed bands

On 31/12/2023 22:59, Johannes Berg wrote:
> On Thu, 2023-12-21 at 22:29 +0000, Matthias May wrote:
>> nl_band->nla_type might have NLA_F_NESTED (0x8000) set,
> I'm curious - how does that happen?
>
> Not that the change looks wrong per se, but ... I don't think this can
> happen?
>
> johannes
>
Hi Johannes

We saw that happen on one of our platforms where we are forced to use an
out-of-tree driver by QCA (SPF12.2).
If you think this is something that can not happen with upstream
drivers, feel free to ignore this patch.

BR
Matthias


2024-01-06 00:56:17

by Jeff Johnson

[permalink] [raw]
Subject: Re: [PATCH] iw: strip NLA_FLAGS from printed bands

On 1/5/2024 12:36 PM, Johannes Berg wrote:
> On Fri, 2024-01-05 at 21:35 +0100, Matthias May wrote:
>> We saw that happen on one of our platforms where we are forced to use an
>> out-of-tree driver by QCA (SPF12.2).
>> If you think this is something that can not happen with upstream
>> drivers, feel free to ignore this patch.
>>
>
> It should be independent of drivers, so they must have modified cfg80211
> to explicitly use the nla_put_nested() instead of
> nla_put_nested_noflag()? It's just ... weird.

Indeed. Matthias do you have a QCA support contact? You should open a
ticket with them to address this issue.

/jeff