mbox series

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

Message ID 20250401201259.50627-1-janusz.dziedzic@gmail.com
Headers show
Series wifi: allow tagged control packets | expand

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:24 a.m. UTC | #1 
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 3, 2025, 12:46 p.m. UTC | #2 
śr., 2 kwi 2025 o 09:55 Janusz Dziedzic <janusz.dziedzic@gmail.com> napisał(a):
>
> śr., 2 kwi 2025 o 09:24 Johannes Berg <johannes@sipsolutions.net> 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.
>

OK, even if disarm control_port in net/mac80211/main.c
(NL80211_EXT_FEATURE_CONTROL_PORT_
*) still need this for rx path:

@@ -2560,13 +2561,16 @@ static bool ieee80211_frame_allowed(stru
       static const u8 pae_group_addr[ETH_ALEN] __aligned(2)
               = { 0x01, 0x80, 0xC2, 0x00, 0x00, 0x03 };
       struct ethhdr *ehdr = (struct ethhdr *) rx->skb->data;
+       struct vlan_ethhdr *vhdr = (void *) ehdr;

       /*
        * Allow EAPOL frames to us/the PAE group address regardless of
        * whether the frame was encrypted or not, and always disallow
        * all other destination addresses for them.
        */
-       if (unlikely(ehdr->h_proto == rx->sdata->control_port_protocol))
+       if (unlikely(ehdr->h_proto == rx->sdata->control_port_protocol ||
+                    (ehdr->h_proto == cpu_to_be16(ETH_P_8021Q) &&
+                     vhdr->h_vlan_encapsulated_proto ==
rx->sdata->control_port_protocol)))
               return ether_addr_equal(ehdr->h_dest, rx->sdata->vif.addr) ||
                      ether_addr_equal(ehdr->h_dest, pae_group_addr);


BR
Jansz