Search Linux Wireless

Re: [RFC PATCH v3 07/12] iwlwifi: Extended Key ID support (NATIVE)

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

 



Am 08.04.19 um 22:10 schrieb Johannes Berg:
On Sun, 2019-02-24 at 14:04 +0100, Alexander Wetzel wrote:

Finding a really good sniffer able to also capture A-MPDU frames
including control frames would be awesome.

I think the AC-9260 you have should be a decent sniffer. The (yet
unreleased) follow-up hardware is even better, but this one is fine.

Just remember to load with amsdu_size set to the appropriate (maximum)
A-MSDU size you want to capture.

I did not do that so far... Thanks for that tip!


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've got a new test system in the meantime and have it up and running as a simple test AP with Extended Key ID. I suspect I'll should tune the antennas (and probably also the card) based on the first test spins, but it's good enough for the moment.

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:-)

I was looking at the firmware now and ... well, I want to really test
this to understand what's going wrong, because it really *looks* like
even the recent ones should be supported natively, at least as far as
I've looked now.


my new test AP came with a Intel AC-3168, which seems to use only one antenna, potentially also explaining my fist impression that it's a worse card for sniffing than my old Ultimate-N 6300. But it looks like it's acting exactly the same in my other iwlmvm test. So I actually started to run some tests and started writing a mail. It's so far inconclusive and I want to verify the packets on the air next. Something is off here and I want to look at that again from scratch, including an external sniffer.

That said here what I've got so far and some fresh captures.

It looks like my (new) Wireless-AC 3168NGW (firmware 29.1044073957.0) does not have the new key ready for Rx when needed. I have a roughly 5 - 15 ms long window where the card scrambles received packets using the new key. (Note: I can't replicate that at the moment. May be wrong!) I first suspected the card "cleared" the new key for usage a bit too soon and tried to verify that by waiting a bit after installing a key to the HW. But it looks like it's not so simple...

I've added a 40 ms delay in the mvm driver after the call to iwl_mvm_set_sta_key() and it first looked like that improved the situation. So I moved the sleep to iwl_trans_send_cmd() behind send_cmd() when not being in CMD_ASYNC but I can't see any any differences any longer. At the moment (with the new test setup) I always get one corrupted frame when downloading from the AP. Always the first frame using the new key...

As for the test procedure: I just add a monitor interface in parallel to the "normal" interface on the AP. With HW encryption enabled we should only get cleartext packets and don't have to worry about encrypted packets in our capture at all:
  iw phy phy0 interface add mon0 type monitor
  ip link set up dev mon0
And start a capture in the interface:
  tcpdump -pi mon0 -s0 -w /tmp/AP.cap

I've just uploaded some captures for you to https://www.awhome.eu/index.php/s/AJJXBLsZmzHdxpX also. I've enabled swcrypto on the client for the first two and enabled HW crypto on the client again for the third and forth.

AP-40ms.pcap.gz
	delay hack as outlined above on the AP
AP-no-delay.cap.gz
	no hack (just some useless printks)
AP-no-delay-client-HW-crypt.cap.gz
	same as above, only cleint using HW crypto
AP-upload-no-delay-HW-crypt.cap.gz
	same as previous, only uploading instead of downloading.
	(and too many broken packets on receive, indicating a bad
	reception/sniffer card)

In all captures I have a normal (1s) ping running to the AP from the cleint and start a download from an internal server after a while.

You can e.g. find the "corrupted" looking frames with the wireshark filter
"(wlan.fc.type_subtype == 0x0028) && !(llc.dsap == 0xaa)"

Each capture here only has exactly one, the very first packet using the new key.

I'll plane to look deeper here, but that is as far as I got so far.

When you look at the captures keep in mind that both the client and the AP also have the two not merged patches applied. But I do not see how that makes a difference here.


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...

AC-9260 should be fine, as far as Intel is concerned. Also make for good
sniffers, in my experience, we use them all the time for that.

Guess I will have to get one for my AP soon at least:-)

Alexander



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux