From: Johannes Berg <[email protected]>
This reverts commit 9b125c27998719288e4dcf2faf54511039526692.
As Jouni points out, there's really no need for this, since the
RSN pre-authentication frames are normal data frames, not port
control frames (locally).
Fixes: 9b125c279987 ("mac80211: support NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211_MAC_ADDRS")
Signed-off-by: Johannes Berg <[email protected]>
---
net/mac80211/main.c | 2 --
net/mac80211/tx.c | 2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index cae3a34d3503..944e86da5c65 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -589,8 +589,6 @@ struct ieee80211_hw *ieee80211_alloc_hw_nm(size_t priv_data_len,
wiphy_ext_feature_set(wiphy, NL80211_EXT_FEATURE_FILS_STA);
wiphy_ext_feature_set(wiphy,
NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211);
- wiphy_ext_feature_set(wiphy,
- NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211_MAC_ADDRS);
if (!ops->hw_scan) {
wiphy->features |= NL80211_FEATURE_LOW_PRIORITY_SCAN |
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 8dd93072f6e6..2645a39cce88 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -5315,7 +5315,7 @@ int ieee80211_tx_control_port(struct wiphy *wiphy, struct net_device *dev,
ehdr = skb_push(skb, sizeof(struct ethhdr));
memcpy(ehdr->h_dest, dest, ETH_ALEN);
- memcpy(ehdr->h_source, src, ETH_ALEN);
+ memcpy(ehdr->h_source, sdata->vif.addr, ETH_ALEN);
ehdr->h_proto = proto;
skb->dev = dev;
--
2.24.1
Hi Johannes,
On 2/24/20 3:19 AM, Johannes Berg wrote:
> As Jouni points out, there's really no need for this, since the
> RSN pre-authentication frames are normal data frames, not port
> control frames (locally).
Using control port for pre-auth frame TX/RX allows userspace to skip
setting up a raw socket and associated bpf filters. This greatly
simplifies the rx/tx path and uses less resources as well.
So to me this patch set seemed like a good idea... We (iwd) don't have
plans to support pre-auth in AP mode in the near future, so this revert
doesn't really affect us. I do wonder what is the actual concern to
warrant a revert?
Regards,
-Denis
On Mon, 2020-02-24 at 10:56 -0600, Denis Kenzior wrote:
> So to me this patch set seemed like a good idea... We (iwd) don't have
> plans to support pre-auth in AP mode in the near future, so this revert
> doesn't really affect us. I do wonder what is the actual concern to
> warrant a revert?
These are two entirely different things, preauth is simply real data as
far as the local system is concerned. It's not related to controlled
port operation at all, which this nl80211 API is about.
FWIW, you may have seen Markus's patch to remove preauth from the RX as
well, this won't work as is, but I'm still a bit on the fence as to
whether I'll force you into the right model or not (i.e. clear the
existing capability bit in mac80211, and introduce a new one that
doesn't report preauth over nl80211). For RX, however, the difference
isn't really that much of a big deal, so maybe just make it optional.
johannes
Hi Johannes,
On 2/24/20 12:26 PM, Johannes Berg wrote:
> On Mon, 2020-02-24 at 10:56 -0600, Denis Kenzior wrote:
>
>> So to me this patch set seemed like a good idea... We (iwd) don't have
>> plans to support pre-auth in AP mode in the near future, so this revert
>> doesn't really affect us. I do wonder what is the actual concern to
>> warrant a revert?
>
> These are two entirely different things, preauth is simply real data as
> far as the local system is concerned. It's not related to controlled
> port operation at all, which this nl80211 API is about.
I can understand this argument, but from what I remember, one of the
goals of the control port API was to make this legacy 'special data
packet' processing unnecessary for userspace. In other words userspace
wouldn't need to establish raw sockets. Hence my question, what is the
actual concern here?
>
> FWIW, you may have seen Markus's patch to remove preauth from the RX as
> well, this won't work as is, but I'm still a bit on the fence as to
> whether I'll force you into the right model or not (i.e. clear the
> existing capability bit in mac80211, and introduce a new one that
> doesn't report preauth over nl80211). For RX, however, the difference
> isn't really that much of a big deal, so maybe just make it optional.
We're actually quite happy with the current model. So I'd like to keep
things as they are.
Regards,
-Denis
On Mon, 2020-02-24 at 12:26 -0600, Denis Kenzior wrote:
> > These are two entirely different things, preauth is simply real data as
> > far as the local system is concerned. It's not related to controlled
> > port operation at all, which this nl80211 API is about.
>
> I can understand this argument, but from what I remember, one of the
> goals of the control port API was to make this legacy 'special data
> packet' processing unnecessary for userspace. In other words userspace
> wouldn't need to establish raw sockets. Hence my question, what is the
> actual concern here?
That's a question of how you define "special data packet processing"...
You're defining it purely in terms of the mechanics of how you handle
them, but that's not really the point.
Preauth frames are _not_ special. They're entirely regular data packets
as far as wifi is concerned.
What _is_ special is EAPOL packets, because you may need to control
their encryption, know if they were ACKed, etc.
> > FWIW, you may have seen Markus's patch to remove preauth from the RX as
> > well, this won't work as is, but I'm still a bit on the fence as to
> > whether I'll force you into the right model or not (i.e. clear the
> > existing capability bit in mac80211, and introduce a new one that
> > doesn't report preauth over nl80211). For RX, however, the difference
> > isn't really that much of a big deal, so maybe just make it optional.
>
> We're actually quite happy with the current model. So I'd like to keep
> things as they are.
I concede that on RX, there isn't actually really a _problem_, although
it's really strange to transport what really is just data frames (from a
wifi POV) over a control path ...
Depending on how much complexity it adds in the kernel (I've not tried
to fix that today) I guess we can keep this. I'd _prefer_ not to, but I
guess I cannot convince you that the preauth model is wrong, and -
mostly as a sign of how much you've worn me down - I'll probably just
keep it.
johannes
Hi Johannes,
> That's a question of how you define "special data packet processing"...
> You're defining it purely in terms of the mechanics of how you handle
> them, but that's not really the point.
Why isn't it the point? These are the only data packets userspace
management daemon(s) actually care about and has to setup raw sockets +
bpf filters for every interface it manages. The current control port
makes all of that unnecessary.
So from a holistic point of view, taking kernel + userspace into
account, what is wrong with letting control port transport preauth
frames if that saves a bunch of resources (and possibly wakeups if the
bpf is setup badly) on the system?
Also, the question is what changed your mind? I asked you specifically
if preauth should be included in the control port API and you thought it
was a good idea at the time?
>
> Preauth frames are _not_ special. They're entirely regular data packets
> as far as wifi is concerned.
Sure. I already conceded this point if this wasn't clear earlier.
Regards,
-Denis
On Mon, 2020-02-24 at 12:57 -0600, Denis Kenzior wrote:
>
> Why isn't it the point? These are the only data packets userspace
> management daemon(s) actually care about and has to setup raw sockets +
> bpf filters for every interface it manages. The current control port
> makes all of that unnecessary.
Sure.
> So from a holistic point of view, taking kernel + userspace into
> account, what is wrong with letting control port transport preauth
> frames if that saves a bunch of resources (and possibly wakeups if the
> bpf is setup badly) on the system?
If you paint it that way, it doesn't seem like there's anything wrong
with it, does it?
But not sure that's the right color - you could apply that precise same
argument to, say, transporting DHCP packets over the same path? I think
you'd agree that doesn't make it right?
Just because preauth is a wifi related protocol doesn't mean we should
treat it in a wifi control path.
> Also, the question is what changed your mind? I asked you specifically
> if preauth should be included in the control port API and you thought it
> was a good idea at the time?
I don't really remember that, but perhaps? Mostly I guess the discussion
on the hostap list now, I suppose.
johannes
Hi Johannes,
>> So from a holistic point of view, taking kernel + userspace into
>> account, what is wrong with letting control port transport preauth
>> frames if that saves a bunch of resources (and possibly wakeups if the
>> bpf is setup badly) on the system?
>
> If you paint it that way, it doesn't seem like there's anything wrong
> with it, does it?
>
> But not sure that's the right color - you could apply that precise same
> argument to, say, transporting DHCP packets over the same path? I think
> you'd agree that doesn't make it right?
But I'm not, and I don't think the argument for DHCP is anywhere as
strong. DHCP is typically handled outside of the wifi management daemon
(though it can be done inside) and is usually something that is very
much separate from WiFi details regardless of where it lives.
>
> Just because preauth is a wifi related protocol doesn't mean we should
> treat it in a wifi control path.
But it seems like the benefits outweigh the drawbacks? At least we have
been super happy with how control port works for us. If you take the
pre-auth path away, I'm really not sure there's any point in (at least
for us) keeping support for the control port path.
>
>> Also, the question is what changed your mind? I asked you specifically
>> if preauth should be included in the control port API and you thought it
>> was a good idea at the time?
>
> I don't really remember that, but perhaps? Mostly I guess the discussion
> on the hostap list now, I suppose.
I'm not subscribed there. A synopsis of the discussion (or
linux-wireless CC) would have been nice.
Regards,
-Denis
On Mon, Feb 24, 2020 at 01:35:51PM -0600, Denis Kenzior wrote:
> But it seems like the benefits outweigh the drawbacks? At least we have
> been super happy with how control port works for us. If you take the
> pre-auth path away, I'm really not sure there's any point in (at least for
> us) keeping support for the control port path.
Do you use the control port for RX only or both TX and RX? The RX side
is mostly harmless _if_ something filters unprotected RSN
pre-authentication frames that are received between the association and
the completion of 4-way handshake. That something would either need to
be the specific user space application using the interface or
potentially mac80211 with some special rules that are different between
EAPOL and RSN pre-authentication ethertypes.
For TX, the control port path will likely result in more problematic
issues. I'd expect drivers to use higher priority and/or higher
reliability for delivering the frames. That is justifiable for EAPOL
frames, but unnecessary for RSN pre-authentication frames. Being able to
bypass the port authorization control would be undesired from security
view point.
The key point for me here is the concept of authorized/unauthorized port
for normal Data frames based on the IEEE 802.1X standard. Only the
frames critical for the authentication service (establishing protected
link with the current access point) are allowed to be transmitted and
received while the port used for normal data is unauthorized. For IEEE
802.11, only the EAPOL frames are such Data frames that are needed
before the port can be authorized. RSN pre-authentication frames are
used to establish a new security association with a different access
point once the port with the current AP is authorized. As such, RSN
pre-authentication frames do not need to go through any special path
from the protocol view point and in fact, it would be incorrect to allow
them to be transmitted or received before the main port has been
authorized.
The IEEE 802.11 standard describes this with "communication of all
non-IEEE-802.1X MSDUs sent or received" being authorized/not-authorized.
MSDU is a reference to Data frames and "non-IEEE-802.1X" in this context
to any ethertype other than the one defined in IEEE 802.1X (EAPOL).
As a more specific example, the EAPOL frames are expected to be
transmitted unencrypted during the initial 4-way handshake (and with
some old IEEE 802.1X/WEP designs and some WPA(v1) implementation, even
during rekeying). On the other hand, RSN pre-authentication frames are
never supposed to go out unencrypted over the air (i.e., they must not
be sent or received before the encryption key has been established for
the link). The IEEE 802.11 standard describes this with "A STA shall not
use preauthentication except when pairwise keys are employed" and "As
preauthentication frames do not use the IEEE 802.1X EAPOL EtherType
field, the AP with which the STA is currently associated need not apply
any special handling. The AP and the MAC in the STA shall handle these
frames in the same way as other frames with arbitrary EtherType field
values that require distribution via the DS."
I understand that there is a different view point for this from the
kernel--user space interface side and it may indeed look more
convenient to use the same path for both EAPOL and RSN
pre-authentication frames from that view point. If that mechanism is
used, it needs to be understood that the rules for EAPOL and RSN
pre-authentication frames are different, though, and it is not clear
where that difference is going to be enforced if the same interface path
is used.
--
Jouni Malinen PGP id EFC895FA
Hi Jouni,
On 2/25/20 5:00 AM, Jouni Malinen wrote:
> On Mon, Feb 24, 2020 at 01:35:51PM -0600, Denis Kenzior wrote:
>> But it seems like the benefits outweigh the drawbacks? At least we have
>> been super happy with how control port works for us. If you take the
>> pre-auth path away, I'm really not sure there's any point in (at least for
>> us) keeping support for the control port path.
>
> Do you use the control port for RX only or both TX and RX? The RX side
Both. For reasons already discussed.
> is mostly harmless _if_ something filters unprotected RSN
> pre-authentication frames that are received between the association and
> the completion of 4-way handshake. That something would either need to
> be the specific user space application using the interface or
> potentially mac80211 with some special rules that are different between
> EAPOL and RSN pre-authentication ethertypes.
For mac80211, pre-authentication frames are already filtered, or at
least that is the intent. See ieee80211_frame_allowed(). Only
control_port_protocol packets are allowed through if the station is not
yet authorized. Under normal circumstances that would only be EAPoL
packets (or esoteric protocols like WAPI). Pre-auth frames would be
filtered.
Furthermore, only the userspace daemon that initiated the association
would get to see the packets flowing via NL80211_CMD_CONTROL_PORT_FRAME
(by providing SOCKET_OWNER attribute). In iwd, we would drop any
pre-auth packets without an initiated session on the floor. And we
don't initiate pre-auth sessions until we are fully
associated/authenticated/authorized.
Last I checked, mac80211 is the only driver that supports this control
port mechanism. If other drivers obtain this support, then perhaps
stricter checking of the packets flowing via cfg80211_rx_control_port()
would be a good idea. However, I'm not sure how much can be done here
due to nl80211 being stateless.
>
> For TX, the control port path will likely result in more problematic
> issues. I'd expect drivers to use higher priority and/or higher
> reliability for delivering the frames. That is justifiable for EAPOL
Fair enough, but the driver is notified of the protocol being sent in
tx_control_port(). So it can easily choose not to prioritize pre-auth
packets.
> frames, but unnecessary for RSN pre-authentication frames. Being able to
> bypass the port authorization control would be undesired from security
> view point.
TX_CONTROL_PORT does require administrative access for the caller. The
userspace management daemon is already trusted to do a lot of things by
the kernel (including cleaning up things inside the kernel itself in
certain cases). If the userspace daemon cannot be trusted to send
control port frames at the appropriate time, then the 'undesired from
security view point' argument would apply quite broadly across the
entire nl80211 API. In fact, even the
NL80211_ATTR_CONTROL_PORT_ETHERTYPE is implicitly trusted to be provided
correctly by userspace.
From a practical perspective, if you're worried about this, then
perhaps stricter checking in nl80211_tx_control_port() is warranted.
But that really implies peeking into the frames being sent...
Another related issue is that NL80211_CMD_TX_CONTROL_PORT (amongst
others) doesn't actually check whether the command is being called by
the $SOCKET_OWNER process for the target netdev. Realistically, only
the $SOCKET_OWNER process has the necessary secrets to generate packets
that go via this path. I've submitted some RFC patches to lock this
down, but they were rejected.
>
> The key point for me here is the concept of authorized/unauthorized port
> for normal Data frames based on the IEEE 802.1X standard. Only the
> frames critical for the authentication service (establishing protected
> link with the current access point) are allowed to be transmitted and
> received while the port used for normal data is unauthorized. For IEEE
> 802.11, only the EAPOL frames are such Data frames that are needed
> before the port can be authorized. RSN pre-authentication frames are
> used to establish a new security association with a different access
> point once the port with the current AP is authorized. As such, RSN
> pre-authentication frames do not need to go through any special path
> from the protocol view point and in fact, it would be incorrect to allow
> them to be transmitted or received before the main port has been
> authorized.
>
> The IEEE 802.11 standard describes this with "communication of all
> non-IEEE-802.1X MSDUs sent or received" being authorized/not-authorized.
> MSDU is a reference to Data frames and "non-IEEE-802.1X" in this context
> to any ethertype other than the one defined in IEEE 802.1X (EAPOL).
>
> As a more specific example, the EAPOL frames are expected to be
> transmitted unencrypted during the initial 4-way handshake (and with
> some old IEEE 802.1X/WEP designs and some WPA(v1) implementation, even
> during rekeying). On the other hand, RSN pre-authentication frames are
> never supposed to go out unencrypted over the air (i.e., they must not
> be sent or received before the encryption key has been established for
> the link). The IEEE 802.11 standard describes this with "A STA shall not
> use preauthentication except when pairwise keys are employed" and "As
> preauthentication frames do not use the IEEE 802.1X EAPOL EtherType
> field, the AP with which the STA is currently associated need not apply
> any special handling. The AP and the MAC in the STA shall handle these
> frames in the same way as other frames with arbitrary EtherType field
> values that require distribution via the DS."
No disagreement with anything you said here...
>
> I understand that there is a different view point for this from the
> kernel--user space interface side and it may indeed look more
> convenient to use the same path for both EAPOL and RSN
> pre-authentication frames from that view point. If that mechanism is
> used, it needs to be understood that the rules for EAPOL and RSN
> pre-authentication frames are different, though, and it is not clear
> where that difference is going to be enforced if the same interface path
> is used.
>
I understand the purity argument you're making here, and I don't
disagree with it. Perhaps the naming of the commands, with CONTROL_PORT
inside them, is unfortunate, but it seemed like a good idea at the time.
It is also unfortunate that pre-authentication was designed the way it
was. It is turning out to be somewhat of an anomaly that we
nevertheless have to deal with.
I do indeed view this through a different lens. Only the wifi
management daemon can realistically generate any frames that flow
through the control port, including pre-auth frames. So I think it
makes very good sense to provide an optimized path for the userspace
daemon to send/receive these frames and not force it to create sockets
and use up resources needlessly.
I also don't mind if RX forwarding of pre-auth frames via the control
port is made optional. What I would not want to happen is for this
capability to be removed completely.
Regards,
-Denis
On 25.02.20 18:06, Denis Kenzior wrote:
> Hi Jouni,
>
> On 2/25/20 5:00 AM, Jouni Malinen wrote:
>> On Mon, Feb 24, 2020 at 01:35:51PM -0600, Denis Kenzior wrote:
>>> But it seems like the benefits outweigh the drawbacks? At least we
>>> have
>>> been super happy with how control port works for us. If you take the
>>> pre-auth path away, I'm really not sure there's any point in (at
>>> least for
>>> us) keeping support for the control port path.
>>
>> Do you use the control port for RX only or both TX and RX? The RX side
>
> Both. For reasons already discussed.
>
>> is mostly harmless _if_ something filters unprotected RSN
>> pre-authentication frames that are received between the association and
>> the completion of 4-way handshake. That something would either need to
>> be the specific user space application using the interface or
>> potentially mac80211 with some special rules that are different between
>> EAPOL and RSN pre-authentication ethertypes.
>
> For mac80211, pre-authentication frames are already filtered, or at
> least that is the intent. See ieee80211_frame_allowed(). Only
> control_port_protocol packets are allowed through if the station is
> not yet authorized. Under normal circumstances that would only be
> EAPoL packets (or esoteric protocols like WAPI). Pre-auth frames
> would be filtered.
>
> Furthermore, only the userspace daemon that initiated the association
> would get to see the packets flowing via
> NL80211_CMD_CONTROL_PORT_FRAME (by providing SOCKET_OWNER attribute).
> In iwd, we would drop any pre-auth packets without an initiated
> session on the floor. And we don't initiate pre-auth sessions until
> we are fully associated/authenticated/authorized.
>
> Last I checked, mac80211 is the only driver that supports this control
> port mechanism. If other drivers obtain this support, then perhaps
> stricter checking of the packets flowing via
> cfg80211_rx_control_port() would be a good idea. However, I'm not
> sure how much can be done here due to nl80211 being stateless.
>
>>
>> For TX, the control port path will likely result in more problematic
>> issues. I'd expect drivers to use higher priority and/or higher
>> reliability for delivering the frames. That is justifiable for EAPOL
>
> Fair enough, but the driver is notified of the protocol being sent in
> tx_control_port(). So it can easily choose not to prioritize pre-auth
> packets.
>
>> frames, but unnecessary for RSN pre-authentication frames. Being able to
>> bypass the port authorization control would be undesired from security
>> view point.
>
> TX_CONTROL_PORT does require administrative access for the caller.
> The userspace management daemon is already trusted to do a lot of
> things by the kernel (including cleaning up things inside the kernel
> itself in certain cases). If the userspace daemon cannot be trusted
> to send control port frames at the appropriate time, then the
> 'undesired from security view point' argument would apply quite
> broadly across the entire nl80211 API. In fact, even the
> NL80211_ATTR_CONTROL_PORT_ETHERTYPE is implicitly trusted to be
> provided correctly by userspace.
>
> From a practical perspective, if you're worried about this, then
> perhaps stricter checking in nl80211_tx_control_port() is warranted.
> But that really implies peeking into the frames being sent...
>
> Another related issue is that NL80211_CMD_TX_CONTROL_PORT (amongst
> others) doesn't actually check whether the command is being called by
> the $SOCKET_OWNER process for the target netdev. Realistically, only
> the $SOCKET_OWNER process has the necessary secrets to generate
> packets that go via this path. I've submitted some RFC patches to
> lock this down, but they were rejected.
>
>>
>> The key point for me here is the concept of authorized/unauthorized port
>> for normal Data frames based on the IEEE 802.1X standard. Only the
>> frames critical for the authentication service (establishing protected
>> link with the current access point) are allowed to be transmitted and
>> received while the port used for normal data is unauthorized. For IEEE
>> 802.11, only the EAPOL frames are such Data frames that are needed
>> before the port can be authorized. RSN pre-authentication frames are
>> used to establish a new security association with a different access
>> point once the port with the current AP is authorized. As such, RSN
>> pre-authentication frames do not need to go through any special path
>> from the protocol view point and in fact, it would be incorrect to allow
>> them to be transmitted or received before the main port has been
>> authorized.
>> The IEEE 802.11 standard describes this with "communication of all
>> non-IEEE-802.1X MSDUs sent or received" being authorized/not-authorized.
>> MSDU is a reference to Data frames and "non-IEEE-802.1X" in this context
>> to any ethertype other than the one defined in IEEE 802.1X (EAPOL).
>>
>> As a more specific example, the EAPOL frames are expected to be
>> transmitted unencrypted during the initial 4-way handshake (and with
>> some old IEEE 802.1X/WEP designs and some WPA(v1) implementation, even
>> during rekeying). On the other hand, RSN pre-authentication frames are
>> never supposed to go out unencrypted over the air (i.e., they must not
>> be sent or received before the encryption key has been established for
>> the link). The IEEE 802.11 standard describes this with "A STA shall not
>> use preauthentication except when pairwise keys are employed" and "As
>> preauthentication frames do not use the IEEE 802.1X EAPOL EtherType
>> field, the AP with which the STA is currently associated need not apply
>> any special handling. The AP and the MAC in the STA shall handle these
>> frames in the same way as other frames with arbitrary EtherType field
>> values that require distribution via the DS."
>
> No disagreement with anything you said here...
>
>>
>> I understand that there is a different view point for this from the
>> kernel--user space interface side and it may indeed look more
>> convenient to use the same path for both EAPOL and RSN
>> pre-authentication frames from that view point. If that mechanism is
>> used, it needs to be understood that the rules for EAPOL and RSN
>> pre-authentication frames are different, though, and it is not clear
>> where that difference is going to be enforced if the same interface path
>> is used.
>>
>
> I understand the purity argument you're making here, and I don't
> disagree with it. Perhaps the naming of the commands, with
> CONTROL_PORT inside them, is unfortunate, but it seemed like a good
> idea at the time. It is also unfortunate that pre-authentication was
> designed the way it was. It is turning out to be somewhat of an
> anomaly that we nevertheless have to deal with.
>
> I do indeed view this through a different lens. Only the wifi
> management daemon can realistically generate any frames that flow
> through the control port, including pre-auth frames. So I think it
> makes very good sense to provide an optimized path for the userspace
> daemon to send/receive these frames and not force it to create sockets
> and use up resources needlessly.
>
> I also don't mind if RX forwarding of pre-auth frames via the control
> port is made optional. What I would not want to happen is for this
> capability to be removed completely.
Is there any consensus on how to move on in this discussion? In my
opinion a pragmatic way would be to make rx forwarding of pre-auth
frames optional with a flag which can be set whenever
NL80211_ATTR_CONTROL_PORT_OVER_NL80211 is included, like Denis has
already proposed. We could call this flag for example
NL80211_ATTR_CONTROL_PORT_NO_PREAUTH.
On Wed, 2020-03-04 at 17:24 +0100, Markus Theil wrote:
> Is there any consensus on how to move on in this discussion? In my
> opinion a pragmatic way would be to make rx forwarding of pre-auth
> frames optional with a flag which can be set whenever
> NL80211_ATTR_CONTROL_PORT_OVER_NL80211 is included, like Denis has
> already proposed. We could call this flag for example
> NL80211_ATTR_CONTROL_PORT_NO_PREAUTH.
Yeah, that seems right.
Do you want to make the patch?
johannes
On 11.03.20 10:31, Johannes Berg wrote:
> On Wed, 2020-03-04 at 17:24 +0100, Markus Theil wrote:
>
>> Is there any consensus on how to move on in this discussion? In my
>> opinion a pragmatic way would be to make rx forwarding of pre-auth
>> frames optional with a flag which can be set whenever
>> NL80211_ATTR_CONTROL_PORT_OVER_NL80211 is included, like Denis has
>> already proposed. We could call this flag for example
>> NL80211_ATTR_CONTROL_PORT_NO_PREAUTH.
> Yeah, that seems right.
>
> Do you want to make the patch?
Yes, I have already some code lying around for it, but did not have time
to test them.
> johannes
>