Hi Johannes,
>
Applied. I squashed 1/2 since it's kinda pointless to have a patch
introducing infrastructure that's not used.
I also made some minor cleanups - please check (both that it's right,
and for next time)
Your changes look fine to me. Thanks for taking these.
Regards,
-Denis
--
Hi Johannes,
On 08/11/2016 07:47 AM, Johannes Berg wrote:
On Wed, 2016-08-03 at 17:02 -0500, Denis Kenzior wrote:
+static int nl80211_dump_interface_parse(struct sk_buff *skb,
+ struct netlink_callback *cb,
+ int
Hi Arend,
>
You can find it in checkpatch.pl [1] :-p
Aha! Will use that one next time. Thanks.
Regards,
-Denis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Hi Johannes,
>> Speaking of indentation, can you point me to a doc of the rules I
should follow?
You've seen Documentation/CodingStyle?
Of course. But that one doesn't discuss that you want your function
parameters to be aligned to the opening '('. Is there a dialect
document specific
havior has not been implemented until now.
Signed-off-by: Denis Kenzior <denk...@gmail.com>
---
net/wireless/nl80211.c | 36
1 file changed, 36 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 46417f9..ac19eb8 100644
--- a/net/
: Squished patches 2+3, 4+5. DEL_INTERFACE event notification is now
sent inside cfg80211_unregister_wdev instead of nl80211_del_interface.
v3: No changes, non-RFC version.
Denis Kenzior (3):
nl80211: Add nl80211_notify_iface
core: Always notify of new wireless netdevs
core: Always notify when
Hi Johannes,
>
No, I don't see a fault in the logic. I just think it's misleading. You
make the code look like it relies on filter_wiphy != 0, but then you go
and treat filter_wiphy==0 as a valid case.
It relies on a sentry condition with all 3 variables being zero, not
just filter_wiphy.
havior has not been implemented until now.
Signed-off-by: Denis Kenzior <denk...@gmail.com>
---
net/wireless/nl80211.c | 63 +++---
1 file changed, 55 insertions(+), 8 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index
Hi Johannes,
On 07/08/2016 05:32 AM, Johannes Berg wrote:
On Thu, 2016-07-07 at 02:08 -0500, Denis Kenzior wrote:
The current mechanism to detect hot-plug / unplug of wireless devices
is
somewhat arcane. One has to listen to NEW_WIPHY/DEL_WIPHY events
over
nl80211 as well as RTM_NEWLINK
Hi Johannes,
>> Are you okay with the general approach?
I see no issues with sending these events out. I'd like them to
actually be reliable (if present) though, not double as you'd implied -
but I didn't really understand in which cases you were expecting
issues, was it only P2P-Device?
Hi Johannes,
>
Looks fine.
Thanks for the review. I rebased & resent this patch as a non-RFC.
Regards,
-Denis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
havior has not been implemented until now.
Signed-off-by: Denis Kenzior <denk...@gmail.com>
---
net/wireless/nl80211.c | 36
1 file changed, 36 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 5782f71..f39fd4d 100644
--- a/net/
/ DEL_INTERFACE commands is interested in the status of these
operations. E.g. the caller is / should be using SOCKET_OWNER attribute.
Thus one possibility is to not emit NEW_INTERFACE/DEL_INTERFACE events in
such cases.
Denis Kenzior (5):
nl80211: Add nl80211_notify_iface
core: Notify of new
For wireless device objects with an associated netdev, the NEW_INTERFACE
event is generated inside the netdev notifier. The event is generated
regardless of whether it was due to a NL80211_CMD_NEW_INTERFACE call
from userspace or if the netdev was created implicitly by the driver.
If
---
net/wireless/core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 7758c0f..d35038b 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -1159,6 +1159,8 @@ static int cfg80211_netdev_notifier_call(struct
notifier_block *nb,
This function emits NL80211_CMD_NEW_INTERFACE or
NL80211_CMD_DEL_INTERFACE events. This is meant to be used by the core
to notify userspace applications such as wpa_supplicant when a netdev
related to a wireless device has been added or removed.
---
net/wireless/nl80211.c | 28
---
net/wireless/core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 7645e97..7758c0f 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -1079,6 +1079,8 @@ static int cfg80211_netdev_notifier_call(struct
notifier_block *nb,
: Squished patches 2+3, 4+5. DEL_INTERFACE event notification is now
sent inside cfg80211_unregister_wdev instead of nl80211_del_interface.
Denis Kenzior (3):
nl80211: Add nl80211_notify_iface
core: Always notify of new wireless netdevs
core: Always notify when wireless netdev is removed
net
-off-by: Denis Kenzior <denk...@gmail.com>
---
net/wireless/core.c| 2 ++
net/wireless/nl80211.c | 23 +--
2 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 7645e97..7758c0f 100644
--- a/net/wireless/
This function emits NL80211_CMD_NEW_INTERFACE or
NL80211_CMD_DEL_INTERFACE events. This is meant to be used by the core
to notify userspace applications such as wpa_supplicant when a netdev
related to a wireless device has been added or removed.
Signed-off-by: Denis Kenzior <denk...@gmail.
-off-by: Denis Kenzior <denk...@gmail.com>
---
net/wireless/core.c| 4
net/wireless/nl80211.c | 18 +-
2 files changed, 5 insertions(+), 17 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 7758c0f..fccead7 100644
--- a/net/wireless/core.c
+++
This function emits NL80211_CMD_NEW_INTERFACE or
NL80211_CMD_DEL_INTERFACE events. This is meant to be used by the core
to notify userspace applications such as wpa_supplicant when a netdev
related to a wireless device has been added or removed.
Signed-off-by: Denis Kenzior <denk...@gmail.
-off-by: Denis Kenzior <denk...@gmail.com>
---
net/wireless/core.c| 4
net/wireless/nl80211.c | 18 +-
2 files changed, 5 insertions(+), 17 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 7758c0f..fccead7 100644
--- a/net/wireless/core.c
+++
-off-by: Denis Kenzior <denk...@gmail.com>
---
net/wireless/core.c| 2 ++
net/wireless/nl80211.c | 23 +--
2 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 7645e97..7758c0f 100644
--- a/net/wireless/
This patch allows GET_INTERFACE dumps to be filtered based on
NL80211_ATTR_WIPHY or NL80211_ATTR_WDEV. The documentation for
GET_INTERFACE mentions that this is possible:
"Request an interface's configuration; either a dump request on
a %NL80211_ATTR_WIPHY or ..."
However, this behavior has not
Hi Johannes,
On 08/16/2016 02:25 AM, Johannes Berg wrote:
From: Denis Kenzior <denk...@gmail.com>
This patch allows GET_INTERFACE dumps to be filtered based on
NL80211_ATTR_WIPHY or NL80211_ATTR_WDEV. The documentation for
GET_INTERFACE mentions that this is possible:
"Request an
Spriel <arend.vanspr...@broadcom.com>
Signed-off-by: Denis Kenzior <denk...@gmail.com>
---
net/wireless/nl80211.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 95d55d2..ddc994a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wirele
Hi Arend,
On 08/25/2016 04:35 PM, Arend van Spriel wrote:
On 25-08-16 22:44, Denis Kenzior wrote:
dump_wiphy_parse only assigns filter_wiphy if one of the supported
NL80211 attributes is present. So for unfiltered dumps, filter_wiphy
was always initialized to 0, and only interface 0
Hi Johannes,
> Huh? No, beacon filtering is implemented by a lot of drivers today.
Pardon a dumb question, but can filtering be turned off? I doubt anyone
would want to, but just wondering.
The userspace switches count too and are the main motivation for this
patch. Eventually, as you
Hi Johannes,
On 12/07/2016 12:48 AM, Johannes Berg wrote:
On Wed, 2016-12-07 at 00:40 -0600, Denis Kenzior wrote:
No, this is the part you didn't understand. Simply authenticating
doesn't actually create anything like a "link" to the AP. The only
Okay, but it is then a bit
Hi Johannes,
On 12/07/2016 12:15 AM, Johannes Berg wrote:
I'm afraid to consider what you're like when you _are_ 'super'
against something :)
Why, that's easy, there wouldn't be a long discussion like that ;-)
lol
No, this is the part you didn't understand. Simply authenticating
Hi Johannes,
On 12/05/2016 07:51 AM, Johannes Berg wrote:
On Fri, 2016-12-02 at 21:56 +0100, Andrew Zaborowski wrote:
Disconnect or deauthenticate when the owning socket is closed if this
flag has been supplied to CMD_CONNECT, CMD_AUTHENTICATE or
CMD_ASSOCIATE.
Huh. That I think needs a lot
Hi Johannes,
On 12/05/2016 09:14 AM, Johannes Berg wrote:
Well, no, that'd only work with an open connection :)
Actually, it also works fairly easily for when firmware has 4-way-
handshake offload, which will be coming to a kernel near you soon.
Great, but still not applicable for all
Hi Johannes,
On 12/05/2016 08:58 AM, Johannes Berg wrote:
Detecting it is easy, sure. But I'm a bit lost on how you propose
to
'use' it. The connection is active up until the next rekey
event. If
rekey offloading is supported, then this might never involve user
space.
But if it isn't
Hi Johannes,
On 12/06/2016 01:16 AM, Johannes Berg wrote:
On Mon, 2016-12-05 at 09:32 -0600, Denis Kenzior wrote:
To what purpose? That's like saying that maybe a socket should be
kept open in case an application crashes.
That socket would be useless, so no, that's not comparable at all
Hi Johannes,
Let me start a separate thread on this:
Also, while we're on this subject. Should the kernel auto-manage
the LINKMODE and OPERSTATE flags? It would seem that it already has
the information to do so, and having userspace manage this just
introduces another source of latency /
Hi Ben,
On 06/08/2017 06:43 PM, Ben Greear wrote:
On 06/08/2017 04:36 PM, Denis Kenzior wrote:
Hi Ben,
The problem I see is that sometimes (and quite often when I am using
lots
of vdevs and thus the NIC is busy), the keys are set before the EAPOL
4/4
hits the air. When the key is set
Hi Ben,
The problem I see is that sometimes (and quite often when I am using lots
of vdevs and thus the NIC is busy), the keys are set before the EAPOL 4/4
hits the air. When the key is set, the NIC will no longer transmit the
frame because of key-length issues in the tx-descriptor (ath10k
Hi Johannes,
We've actually discussed doing precisely this, for - among other things
- this reason. Just nobody stepped up yet to propose the necessary APIs
and do the remaining work to use it etc.
Do you have any thoughts on what the operations should look like or do
you want me to take a
Hi Johannes,
On 09/15/2017 02:19 AM, Johannes Berg wrote:
On Thu, 2017-09-14 at 14:54 -0500, Denis Kenzior wrote:
If you want roaming to keep oper state UP in all cases, then
yes. Does this work on full mac cards as well?
I don't see why not.
E.g. if I CMD_CONNECT to AP1, then pre
Hi Johannes,
And AFAIK the kernel generates a disconnected event as soon as we
send a CMD_AUTHENTICATE, so not sure how you envision 'your'
preauthentication working...
That's what I was trying to say - it doesn't. A few years ago we tried
to support that but it's not really possible to do
Hi Johannes,
On 09/15/2017 08:29 AM, Johannes Berg wrote:
On Fri, 2017-09-15 at 07:50 -0500, Denis Kenzior wrote:
E.g. if I CMD_CONNECT to AP1, then pre-authenticate to AP2 and
issue a CMD_CONNECT to AP2?
That's not something you can do with full-MAC cards?
Err, why not? Pre
Hi Ben,
There are different meanings for 'roam'. Are you just talking about
fast-transition roaming?
I'm using 'roam' as any transition between BSSes in the same
SSID/Security type. So regular re-association, pre-authenticated
association, fast transition.
I would think that the
Hi Ben,
How do you re-confirm them? There are definitely cases where
SSID/Security is the same but each
AP has its own DHCP server and roaming between them will require getting
a new DHCP address (on
the same (NAT'd) subnet and with same gateway, likely as not).
Using DHCPREQUEST to
Hi Ben,
On 09/14/2017 03:29 PM, Ben Greear wrote:
On 09/14/2017 01:26 PM, Denis Kenzior wrote:
Hi Ben,
How do you re-confirm them? There are definitely cases where
SSID/Security is the same but each
AP has its own DHCP server and roaming between them will require
getting a new DHCP
Hi Johannes,
On 09/14/2017 03:39 AM, Johannes Berg wrote:
Hi Arend, Jouni, all,
Avi and I just discussed another use case for the PORT_AUTHORIZED flag,
which is PMKSA caching.
Assume you have 4-way-HS offloaded, then if you send a PMKID in the new
connection (doesn't matter if it's roaming or
11]
The last I saw on this was Denis Kenzior volunteering for it, but
that was about it.
Oh, thanks for the reminder, I'd forgotten entirely...
Denis?
*wakes up*
Ah I now seem to remember that I volunteered to look into this before my
sabbatical :) I think this was in early June? I'm certain
Hi Johannes,
On 09/14/2017 01:36 PM, Johannes Berg wrote:
Hi Denis,
I'd actually only Cc'ed you to see if you were actually working on
EAPOL-over-nl80211 :-)
Curious, isn't sending a PMKID for a non-roaming case not strictly
per spec? Is this just to avoid running 802.1x?
I don't think
Hi Johannes,
On 09/14/2017 02:17 PM, Johannes Berg wrote:
On Thu, 2017-09-14 at 13:37 -0500, Denis Kenzior wrote:
The question is whether all APs are actually sane after a
roam. E.g. can the STA assume that the same IP address, DHCP lease,
etc is still valid? I heard from various people
Hi Johannes,
My earlier point is that software roams need to have the exact same
behavior as well. And my understanding is that when we try to
Fast-Transition (e.g. issue a CMD_ASSOCIATE), operstate is no longer
UP.
I'm not sure - I don't know what the state machine in wpa_s goes
through
Hi Johannes,
Well I guess any time that the carrier does in fact go down, you'd also
reset oper state...
And now that I think about it, that does in fact happen in
ieee80211_set_disassoc(), which we even go through for FT roaming.
Sounds like something we should fix?
If you want roaming to
Hi Ben,
I think it is sane to assume that the IP address _should_ be the same.
The 802.11 spec expects this even. This is to handle bizarre networks
that don't do this
properly.
Can you point me to the section in the spec about this?
Lets see, 802.11-2012, Section 4.3.4.2:
"The key
Hi Ben,
On 09/14/2017 05:15 PM, Ben Greear wrote:
On 09/14/2017 02:35 PM, Denis Kenzior wrote:
Hi Ben,
I think it is sane to assume that the IP address _should_ be the
same. The 802.11 spec expects this even. This is to handle bizarre
networks that don't do this
properly.
Can you point
Only invoke cfg80211_bss_expire on the first nl80211_dump_scan
invocation to avoid (likely) redundant processing.
Signed-off-by: Denis Kenzior <denk...@gmail.com>
---
net/wireless/nl80211.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c
)
^~
Signed-off-by: Denis Kenzior <denk...@gmail.com>
---
net/wireless/nl80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index fd2b1646e81a..376cb66d164c 100644
--- a/net/wireless/nl80211.c
+++
Hi Arend,
On 05/22/2018 05:39 AM, Arend van Spriel wrote:
On 5/8/2018 5:05 PM, Denis Kenzior wrote:
Hi Arend,
Sure. I guess we all have been there kicking of wpa_s and discovering
there is already one running in the background. I am just a bit
squeamish to change the behavior like
Hi Johannes,
On 05/22/2018 03:12 AM, Johannes Berg wrote:
Hi Denis,
Just FYI, there's definitely something funny with the scanning code:
denkenz@iwd-test ~ $ sudo iw dev wlp2s0 scan flush
BSS 10:c3:7b:54:74:d4(on wlp2s0)
last seen: 274.815s [boottime]
freq: 5765
Hi Arend,
Are you saying the first result is from the Beacon and the other is from
the Probe Response? Then why are the 'Information elements from Probe
Response frame' the way they are?
Nope. I am not saying that. I am saying that there are two probe
requests being sent. One with broadcast
Hi Johannes,
I think I finally figured out what's going on. It's a mix between
strange 'iw' behaviour, and strange backward-compatibility behaviour in
cfg80211.
If you do this again and give the scan dump command explicitly with -b
added, like
sudo iw dev wlp2s0 scan passive
iw dev wlp2s0
Hi Johannes,
On 05/22/2018 03:40 PM, Johannes Berg wrote:
Hi,
So I need to absorb all of this some more, but I'm still wondering why
we are seeing two separate scan entries (with hidden & plain ssid) when
we requested a flush? Is there a way to force the kernel to only show
us the probe
Hi Johannes,
But in theory, I think you could've received the beacon with hidden SSID
*before* the scan, yet it might be present in the scan results if the
new scan caused the probe response to be associated with that scan.
Right, your explanation was helpful, thanks. It still seems
Hi Johannes,
> On May 22, 2018, at 3:52 PM, Johannes Berg <johan...@sipsolutions.net> wrote:
>
> On Tue, 2018-05-22 at 15:49 -0500, Denis Kenzior wrote:
>
>> Okay, so we need to use NL80211_BSS_PRESP_DATA if we want to filter out
>> scan results that are coming
On 05/22/2018 04:28 PM, Johannes Berg wrote:
On Tue, 2018-05-22 at 16:25 -0500, Denis Kenzior wrote:
Hi Johannes,
But in theory, I think you could've received the beacon with hidden SSID
*before* the scan, yet it might be present in the scan results if the
new scan caused the probe response
Hi Johannes,
On 05/18/2018 03:13 AM, Johannes Berg wrote:
On Fri, 2018-05-11 at 09:48 -0700, Tim Kourt wrote:
__cfg80211_bss_expire function was incorrectly used to flush the BSS
entries from the previous scan results, causing NL80211_SCAN_FLAG_FLUSH
flag to have no effect.
Hmm. I guess I'm
Hi Arend,
On 05/18/2018 01:54 PM, Arend van Spriel wrote:
On 5/18/2018 6:47 PM, Denis Kenzior wrote:
Hi Johannes,
On 05/18/2018 03:13 AM, Johannes Berg wrote:
On Fri, 2018-05-11 at 09:48 -0700, Tim Kourt wrote:
__cfg80211_bss_expire function was incorrectly used to flush the BSS
entries
Hi Johannes,
On 05/22/2018 09:51 AM, Johannes Berg wrote:
On Tue, 2018-05-22 at 16:50 +0200, Johannes Berg wrote:
On Tue, 2018-05-22 at 09:48 -0500, Denis Kenzior wrote:
Hi Arend,
Are you saying the first result is from the Beacon and the other is from
the Probe Response? Then why
Hi Johannes,
Some Arch Linux users are reporting a kernel oops when using iwd on 4.17
inside the control port bits. It seems to be pre-emption related since
I've never seen this in all my testing. Any pointers as to what might
be causing this?
[ 5069.567760] Call Trace:
[ 5069.567765]
] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Signed-off-by: Denis Kenzior
---
net/mac80211/tx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 5b93bde248fd..6a79d564de35 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -4850,7 +4850,9 @@ int
Hi Johannes,
On 06/29/2018 05:01 AM, Johannes Berg wrote:
Hi Denis,
Hope you don't mind me adding the list to the explanations, so they're
recorded. Your questions are completely reasonable, after all :-)
Absolutely do not mind.
So I've been poking around a bit more in nl80211/mac80211
Hi Johannes,
> On Jun 15, 2018, at 7:30 AM, Johannes Berg wrote:
>
> On Fri, 2018-06-15 at 11:09 +, McGinn, Dan wrote:
>> Hi, I'm newly trying out Intel iwd daemon but I experience regular kernel
>> errors in 4.17, although WPA2-PSK connection remains stable. These errors
>> don't seem
-by: Denis Kenzior
---
v2 changes:
- Reword commit header
- Rework tracing slightly per Arend's feedback
- Added blurb about skb->protocol in include/net/cfg80211.h
include/net/cfg80211.h | 12 ++--
net/mac80211/rx.c | 5 +
net/wireless/nl80211.c | 24 +++-
Hi Arend,
To make this possible this patchset introduces a new NL80211 command
and several
new attributes. A userspace that is capable of processing EAPoL
packets over
NL80211 includes a new NL80211_ATTR_CONTROL_PORT_OVER_NL80211
attribute in its
NL80211_CMD_ASSOCIATE or
Hi Jouni, Johannes,
> + * User space uses the %NL80211_CMD_CONNECT command to the host
driver for
+ * triggering a connection. The host driver selects a BSS and further uses
+ * this interface to offload only the authentication part to the user
+ * space. Authentication frames are
If userspace requested control port frames to go over 80211, then do so.
The control packets are intercepted just prior to delivery of the packet
to the underlying network device.
Pre-authentication type frames (protocol: 0x88c7) are also forwarded
over nl80211.
Signed-off-by: Denis Kenzior
for mac80211 was added.
Denis Kenzior (5):
nl80211: Add CONTROL_PORT_OVER_NL80211 attribute
nl80211: Add CMD_CONTROL_PORT_FRAME API
mac80211: Send control port frames over nl80211
nl80211: Implement TX of control port frames
mac80211: Add support for tx_control_port
include/net/cfg80211.h
routing is requested in NL80211_CMD_CONNECT or
NL80211_CMD_ASSOCIATE
Signed-off-by: Denis Kenzior <denk...@gmail.com>
---
include/net/cfg80211.h | 17 +
include/uapi/linux/nl80211.h | 15 +++
net/wireless/nl80211.c | 59 +++
Signed-off-by: Denis Kenzior <denk...@gmail.com>
---
net/mac80211/cfg.c | 1 +
net/mac80211/ieee80211_i.h | 3 +++
net/mac80211/main.c| 1 +
net/mac80211/tx.c | 46 ++
4 files changed, 51 insertions(+)
diff --git
frames. If CONTROL_PORT_ETHERTYPE_NO_ENCRYPT is
specified, then the driver will be asked not to encrypt the outgoing
frame.
Signed-off-by: Denis Kenzior <denk...@gmail.com>
---
include/net/cfg80211.h | 9
net/wireless/nl80211.c | 60
Signed-off-by: Denis Kenzior <denk...@gmail.com>
---
include/net/cfg80211.h | 6 ++
include/uapi/linux/nl80211.h | 14 +-
net/wireless/nl80211.c | 20
3 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/i
Hi Johannes,
On 01/15/2018 07:14 AM, Johannes Berg wrote:
Ok this is the interesting part :-)
+ int (*tx_control_port)(struct wiphy *wiphy,
+ struct net_device *dev,
+ const u8 *buf, size_t len,
+
Hi Johannes,
On 01/15/2018 07:09 AM, Johannes Berg wrote:
On Wed, 2018-01-10 at 11:09 -0600, Denis Kenzior wrote:
Pre-authentication type frames (protocol: 0x88c7) are also forwarded
over nl80211.
Interesting - maybe userspace should be able to configure a(n) (list
of) ethertype(s)?
I'm
Hi Johannes,
On 01/31/2018 03:53 PM, Johannes Berg wrote:
+static int nl80211_tx_control_port(struct sk_buff *skb, struct genl_info *info)
+{
+ struct cfg80211_registered_device *rdev = info->user_ptr[0];
+ struct net_device *dev = info->user_ptr[1];
+ struct wireless_dev
Hi Johannes,
+ * @NL80211_CMD_CONTROL_PORT_FRAME: Control Port (e.g. PAE) frame TX request
+ * and RX notification. This command is used both as a request to transmit
+ * a control port frame and as a notification that a control port frame
+ * has been received. %NL80211_ATTR_FRAME
routing is requested in NL80211_CMD_CONNECT or
NL80211_CMD_ASSOCIATE
Signed-off-by: Denis Kenzior <denk...@gmail.com>
---
include/net/cfg80211.h | 17 +
include/uapi/linux/nl80211.h | 15 +++
net/wireless/nl80211.c | 59 +++
Signed-off-by: Denis Kenzior <denk...@gmail.com>
---
include/net/cfg80211.h | 3 +++
include/uapi/linux/nl80211.h | 17 -
net/wireless/nl80211.c | 12
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/inclu
frames. If CONTROL_PORT_ETHERTYPE_NO_ENCRYPT is
specified, then the driver will be asked not to encrypt the outgoing
frame.
Signed-off-by: Denis Kenzior <denk...@gmail.com>
---
include/net/cfg80211.h | 9 +++
net/wireless/nl80211.c | 63
If userspace requested control port frames to go over 80211, then do so.
The control packets are intercepted just prior to delivery of the packet
to the underlying network device.
Pre-authentication type frames (protocol: 0x88c7) are also forwarded
over nl80211.
Signed-off-by: Denis Kenzior
of cfg80211_rx_control_port.
- TX path reworked completely. tx_control_port method has been introduced to
cfg80211_ops. An implementation of tx_control_port for mac80211 was added.
Denis Kenzior (6):
uapi: Add 802.11 Preauthentication to if_ether
nl80211: Add CONTROL_PORT_OVER_NL80211 attribute
nl80211: Add
This adds 0x88c7 protocol type to if_ether.
Signed-off-by: Denis Kenzior <denk...@gmail.com>
---
include/uapi/linux/if_ether.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/if_ether.h b/include/uapi/linux/if_ether.h
index f8cb5760ea4f..54585906e50a 100644
--- a/i
Signed-off-by: Denis Kenzior <denk...@gmail.com>
---
net/mac80211/cfg.c | 1 +
net/mac80211/ieee80211_i.h | 3 +++
net/mac80211/main.c| 2 ++
net/mac80211/tx.c | 46 ++
4 files changed, 52 insertions(+)
diff --git
Hi Johannes,
On 01/31/2018 04:00 PM, Johannes Berg wrote:
Looks pretty good! Some comments over in separate emails.
Maybe you should consider reordering:
[1/6] keep
[2/6] keep
[3/6] introduce TX (now patch 5)
[4/6] introduce RX (now patch 3)
modify this to require TX from the driver in
frames. If CONTROL_PORT_ETHERTYPE_NO_ENCRYPT is
specified, then the driver will be asked not to encrypt the outgoing
frame.
A new EXT_FEATURE flag is introduced so that nl80211 code can check
whether a given wiphy has capability to pass EAPoL frames over NL80211.
Signed-off-by: Denis Kenzior <d
Signed-off-by: Denis Kenzior <denk...@gmail.com>
---
include/net/cfg80211.h | 3 +++
include/uapi/linux/nl80211.h | 14 +-
net/wireless/nl80211.c | 13 +
3 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/inclu
This adds 0x88c7 protocol type to if_ether.
Signed-off-by: Denis Kenzior <denk...@gmail.com>
---
include/uapi/linux/if_ether.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/if_ether.h b/include/uapi/linux/if_ether.h
index f8cb5760ea4f..54585906e50a 100644
--- a/i
If userspace requested control port frames to go over 80211, then do so.
The control packets are intercepted just prior to delivery of the packet
to the underlying network device.
Pre-authentication type frames (protocol: 0x88c7) are also forwarded
over nl80211.
Signed-off-by: Denis Kenzior
routing is requested in NL80211_CMD_CONNECT or
NL80211_CMD_ASSOCIATE
Signed-off-by: Denis Kenzior <denk...@gmail.com>
---
include/net/cfg80211.h | 22 +
include/uapi/linux/nl80211.h | 13 ++
net/wireless/nl80211.c
Signed-off-by: Denis Kenzior <denk...@gmail.com>
---
net/mac80211/cfg.c | 1 +
net/mac80211/ieee80211_i.h | 3 +++
net/mac80211/tx.c | 46 ++
3 files changed, 50 insertions(+)
diff --git a/net/mac80211/cfg.c b/net/mac80211
. tx_control_port method has been introduced to
cfg80211_ops. An implementation of tx_control_port for mac80211 was added.
Denis Kenzior (6):
uapi: Add 802.11 Preauthentication to if_ether
nl80211: Add CMD_CONTROL_PORT_FRAME API
nl80211: Implement TX of control port frames
nl80211: Add
Hi Johannes,
On 02/19/2018 06:44 AM, Johannes Berg wrote:
On Wed, 2018-01-31 at 19:04 -0600, Denis Kenzior wrote:
+ switch (wdev->iftype) {
+ case NL80211_IFTYPE_STATION:
+ if (wdev->current_bss)
+ break;
+ err = -EN
be nice to extend this functionaly for Pre-Authentiation frames
(protocol 0x88c7) as well so that userspace does not have to deal with these
using a different transport.
The proposed patchset has been tested in a mac80211_hwsim based environment with
hostapd and iwd.
Denis Kenzior (4):
nl80211
1 - 100 of 154 matches
Mail list logo
