Re: [PATCH v2 2/2] Use control port over nl80211 also for rx path

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/5/20 9:07 PM, Jouni Malinen wrote:
On Fri, Jan 03, 2020 at 04:17:42PM +0100, Markus Theil wrote:
This patch is based on the previous patch from Brendan Jackman
and adds rx support over nl80211. In order to receive frames
over the event nl socket, assoc/connect/beacon setting has to be
performed over the same socket, which should later receive the events.
Thanks, I cleaned this up and split the changes into easier to
understand smaller commits. I applied the parts that I understood and
that did not break hwsim test cases. However, this change to use event
nl socket broke large number of test cases, so I could not apply it
(i.e., this is enabled only for TX for now). I'm not sure what exactly
goes wrong with the RX changes, but it looks like cfg80211 state is
somewhat strange when trying to disconnect and try to connect again with
a new network (NL80211_CMD_AUTHENTICATE fails).

I didn't fully understand what the changes were doing with nl_event and
why the changes looked so inconsistent on using
send_and_recv_msgs_event() vs. send_and_recv_msmgs(). I tried to fix
those, but that did not remove the issues (but probably fixed some other
cases that I did not hit yet due to those other problems preventing full
testing). Anyway, the change itself did allow a simple test sequence
like the ap_wpa2_psk test case to complete full connection on both the
AP and station side using the nl80211 control port, so most of the
functionality is working, but something is just messing up what happens
for following operations.

I'm attaching the remaining patches that I could not apply. These
include all the cleanup and fixes I did when trying to figure out what
is happening.

With this patch ctrl port tx supports the no_encrypt flag.
This was fine, but I moved from encrypt to no_encrypt in the driver ops
API since this is really a special case requesting frames not to be
encrypted when keys are set rather than something that is needed for the
normal case where the EAPOL frames should be encrypted if PTK is set.

wpa supplicant now uses the l2 socket only to obtain the device mac
address, future patches may split this out.
I could not apply this one because it depends on the nl80211 control
port RX path working.

Sending frames over the nl80211 event socket should may be made harder
again, by xor-ing the socket handle outside of send_and_recv_msgs_event.
I'm not sure how to interpret this.. Are you noting that something
additional should be done in the future or are you commenting that that
is already done here?

In order to correctly encrypt rekeying frames, wpa_supplicant now checks
if a PTK is currently installed and sets the corresponding encrypt
option for tx_control_port.
I'm not completely confident on this being accurate for all cases, but I
applied these as well. Especially PTK rekeying part is unclear since the
EAPOL frames need to be encrypted, but with the old key, not the new
one. Anyway, all test cases seemed to be passing fine with the changes
on the TX path.

Thanks a lot for reviewing and splitting the patch. I have time to look into the Rx path issues by the end of next week and will send another patch when ready.
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap

_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux