[RFC,wireless-next,0/2] wifi: allow tagged control packets

Message

Janusz Dziedzic April 1, 2025, 8:04 p.m. UTC

Hello,

Base on EasyMesh spec:
If a Multi-AP Agent configures a Primary VLAN ID, the Multi-AP Agent
shall send EtherType 0x888E frames on a Wi-Fi link in a Multi-AP Profile-2
Network Segment with an 802.1Q C-Tag with VLAN ID equal to the Primary VLAN ID.

Today I see BRCM agents already tag EAP frames when we enable
EasyMesh traffic separation.

This is initial version I tested using Mediatek mt7915e and hostapd.
Guys please check/comment.


Janusz Dziedzic (2):
  wifi: cfg80211: allow send/recv tagged EAPOL
  wifi: mac80211: allow tagged control packets

 include/net/cfg80211.h       |  3 ++-
 include/uapi/linux/nl80211.h |  5 +++++
 net/mac80211/cfg.c           |  3 +++
 net/mac80211/ieee80211_i.h   |  3 ++-
 net/mac80211/iface.c         |  2 ++
 net/mac80211/rx.c            | 40 ++++++++++++++++++++++++++++++++++++
 net/mac80211/tx.c            | 24 +++++++++++++++++-----
 net/wireless/nl80211.c       | 11 +++++++++-
 net/wireless/rdev-ops.h      |  5 +++--
 9 files changed, 86 insertions(+), 10 deletions(-)

Comments

Johannes Berg April 2, 2025, 7 a.m. UTC | #1

> 
> This is initial version I tested using Mediatek mt7915e and hostapd.
> Guys please check/comment.
> 

How serious are you with this? ;-)

On a very quick read: the first patch cannot build, there's a security
issue I think, the nl80211 attribute is defined wrong, you're making
unrelated changes, and you're probably breaking older hostapd versions.

johannes

Janusz Dziedzic April 2, 2025, 7:17 a.m. UTC | #2

śr., 2 kwi 2025 o 09:00 Johannes Berg <[e-mail]> napisał(a):
>
> >
> > This is initial version I tested using Mediatek mt7915e and hostapd.
> > Guys please check/comment.
> >
>
> How serious are you with this? ;-)
>
:)

> On a very quick read: the first patch cannot build, there's a security
> issue I think, the nl80211 attribute is defined wrong, you're making
> unrelated changes, and you're probably breaking older hostapd versions.
>
Just do minimal imp/check and share RFC, while don't know this
approach could be accepted.

BR
Janusz




--
Janusz Dziedzic

Johannes Berg April 2, 2025, 7:24 a.m. UTC | #3

On Wed, 2025-04-02 at 09:17 +0200, Janusz Dziedzic wrote:
> 
> Just do minimal imp/check and share RFC, while don't know this
> approach could be accepted.
> 

What choices are there? What's the alternative? Go back to sending the
frames via raw sockets? I guess it works but it's not great?

johannes

Janusz Dziedzic April 2, 2025, 7:55 a.m. UTC | #4

śr., 2 kwi 2025 o 09:24 Johannes Berg <[e-mail]> napisał(a):
>
> On Wed, 2025-04-02 at 09:17 +0200, Janusz Dziedzic wrote:
> >
> > Just do minimal imp/check and share RFC, while don't know this
> > approach could be accepted.
> >
>
> What choices are there? What's the alternative? Go back to sending the
> frames via raw sockets? I guess it works but it's not great?
>
Yes, back to netdev/bridge eap read in hostapd should fix receive path.
But, don't see it on netdev/bridge when use tcpdump - guess we change
smth here for rx path (or skip not protected when control port used).

Some background:
 - backhaul AP send primary_vlan_id in assoc resp in multi_ap IE
 - backhaul STA (agent) if support multi_ap profile >= 2 should tag
EAPOLs with primary_vlan_id
 - with control_port we have today hostapd backhaul AP don't get this
tagged EAPOLs

Other issue is sending tagged EAPOL from hostapd when backhaul STA
multi_ap_profile >= 2.
But RX path looks like regression compare to raw sockets.

BR
Janusz