linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Wetzel <alexander@wetzel-home.de>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFC PATCH v3 07/12] iwlwifi: Extended Key ID support (NATIVE)
Date: Sun, 24 Feb 2019 14:04:01 +0100	[thread overview]
Message-ID: <14c9d8f7-7cf6-d7e1-a1c0-9f1a10920d4e@wetzel-home.de> (raw)
In-Reply-To: <69e6577f90d99289acaa9853fe236e6f15f9e774.camel@sipsolutions.net>

>>   and I've had some time to improve my test setup and
>> hopefully have better access to a mvm card for testing.
> 
> If all that's lacking is a few NICs then I'm sure we/I can help out with
> that :)
> 

Thanks, but as you suspected the NICs are the smallest problem...

I've simply delayed setting up a good lab far too long. So prior to 
shifting the focus to drivers I have to remedy that somehow.
Not really relevant here, but if you want to know what I plan for the 
future here my thoughts on it. If not you better skip that section:-)

Current plan is, to get one (ideally two, depending on price) mini PCs 
(amd64) with m.2 slots, good antennas and one or two matching Intel AC 
9260 cards.

Additionally I want to get rid of the whitelist in my development 
notebook by flashing coreboot, opening the path to install a minipci to 
m.2 adapter mount a second/third Intel 9260 card.

The core boot flash rollout is imminent, just do not want to risk the 
system by soldering wires to the mainboard till the generic support is 
sorted out. If that goes wrong I could brick my main system and lose 
access to my dvm card, but no risk no fun:-)

With that setup and using AC-9260 in all devices I'll have near-perfect 
setup to test and observe AC-9260 and can simply swap out cards to test 
and and maybe also get working after (hopefully) getting AC-9260 
Extended Key ID "certified" as reference implementation.
With three stations I can then try my hand at the still open mesh 
support for Extended Key ID, but that should wpa_supplicant only.

That said the initial heavy lifting is done. I'm still amazed I get that 
off the ground and working end2end with comparable ease. While there is 
still much work left the structures are all in place and it's now mainly 
closing the gaps.

I currently plan stick to the project a bit langer getting at least some 
intel cards and ath9k working, finalize the already existing Extended 
Key ID and PTK0 rekey patches and also update wireshark again.

I suspect I'll need at least one year for that in the best case, 
potentially much longer.

I already have three bugs/issues flagged for analysis. Nothing really 
relevant for the generic support but all three itching enough I'll plan 
to look into them:
1) Wrong time stamps with at least iwlwifi when using monitor in 
parallel to the normal connection for outgoing MPDUs (probably mac80211 
issue, )
2) Probably: Wpa_supplicant scan list is flushed too often, preventing 
fast reconnects
3) Wireshark can't handle Extended Key IDs decoding (and decoding should 
get at least some other generic improvements

Chances are I'll be busy with coreboot for some time and then 
finding/setting up some mini PC(s). That's nothing I've had any need for 
so far and suitable systems with M.2 slots with at least two external 
antennas are hard to find. (So I may end up mounting external antennas 
to the system myself.)

To continue I primarily need another Extended Key ID AP, ideally able to 
support NATIVE and COMPAT mode. Having a second device (or maybe just 
second M.2 card in the same one?) for sniffing nice.

Finding a really good sniffer able to also capture A-MPDU frames 
including control frames would be awesome. All the so-called good 
sniffing USB sticks I got my hands on crap even for sniffing normal 
frames compared to my built-in dvm card nobody seems to suggest for 
sniffing...
Full-speed sniffing to observe a rekey during load is hardly a common 
use case and I suspect usb interface alone an indication the card won't 
be able to handle it well. And some things like the cleartext packet 
leaks only becomes visible at higher speeds. (Which btw also need a 
follow up. My crypt skills are not the best, but with my current 
understanding I'm quite sure a retransmit of a previously encrypted 
frame in the clear text gives away the TK key for all other frames 
encrypted with the same TK.)

So plenty of work and reason to get a better test environment set up:-)

I hope the newer mvm cards will be as good as my old mvm card and when 
using the same card in the AP, sta and sniffer able to get basically 
every frame as long as the sniffer has the best antennas.

If someone here has a suggestion what works for I would appreciate some 
pointers here:-) Don't want sink too much money at it but if it's 
something around 300€ or so I could simply start with one and decide 
later if I really need a second one. Non-amd64 systems would also be ok, 
but it must at least work with vanilla kernels and something like 
Debian. I'm wasted enough time of porting my patches for each test and 
keep them in sync.

If someone is willing to donate a suitable test system I would not say 
no, but I'll plan to finish that with private funds also.

I probably should work on the new AP, but then I always wanted to test 
coreboot and finding out my notebook is now supported is too alluring to 
resist;-)


>>>> I also have tested patch for iwldvm using the Compat mode and I think
>>>> mvm cards will also work with that.
>>>
>>> No they don't, no firmware is available for that.
>>
>> So far I only looked at the dvm part of iwlwifi with only minutes spend
>> on mvm to port the NATIVE solution from dvm.
> 
> :)
> 
>> Are you saying that mvm cards can't seamless switch a RX/TX key to TX
>> only one? mvm seems to support SW crypto as needed and switching RX/TX
>> to TX keys is the only other requirement for COMPAT mode.
> 
> No, sorry. I misread your statement. I thought you were saying "mvm
> cards will also work with iwldvm" rather than "mvm cards will also work
> with compat mode" :-)
> 
> I think they all should just be made to work in native mode, the
> firmware basically supports this as you found, there must be some small
> bugs.

Agree. And with your statements that it already should work and the 
option to get ucode updates I like our chances:-) With some luck it 
could even work and I made some error the first time. I'll give that a 
second look with what I have at hand soon. But after bombing you with 
mails for what feels like most of the weekend I'll postpone that for now:-)

As mentioned above I'm currently aiming for two or three Intel AC-9260 
cards for the next development round. It's seems to be the most modern 
card and the price difference between the cards is irrelevant compared 
to both efforts and costs to get the cards working in two or three 
devices. If you thing another card would be better for development I'll 
just use that one instead...

Alexander

Alexander

  reply	other threads:[~2019-02-24 13:04 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-10 21:06 [RFC PATCH v3 00/12] Draft for Extended Key ID support Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 01/12] mac80211: Optimize tailroom_needed update checks Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 02/12] nl80211/cfg80211: Extended Key ID support Alexander Wetzel
2019-02-15 10:52   ` Johannes Berg
2019-02-17 19:19     ` Alexander Wetzel
2019-02-22  8:30       ` Johannes Berg
2019-02-22 23:04         ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 03/12] mac80211: IEEE 802.11 " Alexander Wetzel
2019-02-15 11:06   ` Johannes Berg
2019-02-19 20:58     ` Alexander Wetzel
2019-02-21 19:47       ` Alexander Wetzel
2019-02-22  8:41         ` Johannes Berg
2019-02-23 21:02           ` Alexander Wetzel
2019-03-01 20:43           ` Alexander Wetzel
2019-02-23 17:26         ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 04/12] mac80211: Compatibility " Alexander Wetzel
2019-02-15 11:09   ` Johannes Berg
2019-02-21 20:07     ` Alexander Wetzel
2019-02-22  8:53       ` Johannes Berg
2019-02-23 22:50         ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 05/12] mac80211: Mark A-MPDU keyid borders for drivers Alexander Wetzel
2019-02-15 11:50   ` Johannes Berg
2019-02-21 21:20     ` Alexander Wetzel
2019-02-22  8:51       ` Johannes Berg
2019-02-23 21:47         ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 06/12] mac80211_hwsim: Ext Key ID support (NATIVE) Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 07/12] iwlwifi: Extended " Alexander Wetzel
2019-02-15 11:52   ` Johannes Berg
2019-02-22 20:50     ` Alexander Wetzel
2019-02-22 21:06       ` Johannes Berg
2019-02-24 13:04         ` Alexander Wetzel [this message]
2019-04-08 20:10           ` Johannes Berg
2019-04-10 20:46             ` Alexander Wetzel
2019-04-12  9:51               ` Johannes Berg
2019-04-14 16:12                 ` Alexander Wetzel
2019-04-15  8:44                   ` Johannes Berg
2019-04-15 20:09                     ` Alexander Wetzel
2019-04-16  9:31                       ` Johannes Berg
2019-04-16 18:28                         ` Alexander Wetzel
2019-04-16 19:11                           ` Johannes Berg
2019-04-16 21:32                             ` Alexander Wetzel
2019-04-12 11:19               ` Johannes Berg
2019-02-10 21:06 ` [RFC PATCH v3 08/12] iwlwifi: dvm - EXT_KEY_ID A-MPDU API update Alexander Wetzel
2019-02-15 11:54   ` Johannes Berg
2019-02-22 21:15     ` Alexander Wetzel
2019-02-22 21:20       ` Johannes Berg
2019-02-10 21:06 ` [RFC PATCH v3 09/12] ath: Basic Extended Key ID support (COMPAT+NATIVE) Alexander Wetzel
2019-02-13 11:05   ` Kalle Valo
2019-02-13 23:15     ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 10/12] ath5k: ath_key_config() API compatibility update Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 11/12] ath9k: Extended Key ID support (COMPAT) Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 12/12] ath9k: EXT_KEY_ID A-MPDU API update Alexander Wetzel
2019-02-15 11:10 ` [RFC PATCH v3 00/12] Draft for Extended Key ID support Johannes Berg
2019-02-21 20:44   ` Alexander Wetzel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=14c9d8f7-7cf6-d7e1-a1c0-9f1a10920d4e@wetzel-home.de \
    --to=alexander@wetzel-home.de \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).