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
