Ignore other packets?

[rodizio1]

Is it possible to make the cards ignore packets we don't want?

I noticed that packetloss can be reduced by disconnecting the antennas (so that the receiving cards do not receive other wifi traffic from other wifi networks around).

My theory is, this happens because the receiving card is already busy decoding other packets (for example those annoying beacons which are sent with lowest data rate and thus reach further than other packets and also take up a lot of "air-time").

Is it possible to make the firmware only receive packets destined to a specific mac address? Or maybe tell it to only receive data frames and no beacons and other management frames? I.e. stop decoding and go to listening state again as soon as it has decoded enough of the frame to identify it as a beacon (or not "unwanted")?

[olerem]

The filter option was already asked by some other users too. Reducing useless traffic from Firmware to the Host is probably a good idea. But it need time to research and implement. Without help I won't be able to do this. All help is welcome ;)

[erikarn]

Hiya,

So in theory, the firmware is only sending frames that the hardware sends, and the hardware in STA mode should only be sending frames that match its filter config.

The wifi half just DMAs frames that it receives that passes the filter to RAM inside the SoC side of things. The firmware then sends those frames over USB.

So for STA mode, you'll see frames destined to it, and broadcast frames from the BSS, and beacons. If you turn on promisc then you'll see BSS frmaes to anyone, and if you turn on "any bss" you'll see everything.

The packet loss is likely happening because of stuff going on as part of packet decode in the wifi half of the chip, way way before firmware. So it's likely there's some RF problem, or some busy air problem that's causing issues. That all happens way before firmware gets the frames.

So it's not a firmware problem. If you have two antennas and one isn't working right then it's likely an antenna diversity or interference problem. If it's AR9271 then I can help someone who wants to do a bit of programming understand what's going on, as I know how antenna diversity works on AR9285/AR9485/AR9271.

Thanks!

-adrian

[rodizio1]

Just to clarify, this wasn't a bug report ;)

I use monitor mode injection and reception for video transmission, so I only need data frames. BTW, I use only monitor mode, no promiscous mode, as enabling promiscous mode makes the cards crash every 5th to 10th attempt.

I mean the following situation (similar to the hidden-node issue when using wifi in normal STA/AP mode): The transmitting wifi card is say 200m in front of the receiving wifi cards, injecting video frames. 700m behind the receiving wifi card, there is an access point, (well, actually not only one, more like 10) sending 10 (more like a hundred ...) beacons per second with 1mbit data rate, using up quite a lot of air-time. The transmitter card cannot hear the accesspoint in 700m+200m distance, but the receiving cards in 700m distance can.

Since the interferring accesspoint and the injecting card cannot hear each other (and also because wifi backoff and medium access timings are not made for such high distances) it can happen, that a beacon from the access point reaches the receiving wifi cards on the ground slightly earlier than the video data frames from the injecting wifi card in the air.

In this case, the wifi part will sense the beacon and start decoding it. Since beacons take very long to transmit/receive (several milliseconds vs. ~0.5ms for my injected data packets), the wifi part will not listen to other frames coming in during that time (since the aircraft's signal is stronger, the capture effect will allow for decoding of the 'intended' video data packets, even though there are beacons in the air at the same time).

And of course, I'd like to stop any un-needed packets as soon as possible so they don't use up ressources on the wifi card and the host computer (Raspberry Pi).

According to this paper (https://people.cs.kuleuven.be/~mathy.vanhoef/papers/acsac2014.pdf), the hardware is actually capable of reading a frame while it is still coming in from the air and also stop decoding it. These guys used it to implement a dos attack by aborting the reception of a frame still in the air and injecting another frame (while the original one is still in the air).

1. Read the decoded header of a frame still in transit.
2. Abort receiving the current frame
3. Immediately jam the channel Point 2 can be accomplished using the AR_DIAG_SW register.

There is no support to read the already decoded bytes of a frame still in transit. Nevertheless, one can still accomplish this if the wireless chip uses Direct Memory Access (DMA) to write already decoded bytes to memory. In that case we can monitor the receive bu er using the main CPU (see Figure 6). We rst initialize the receive bu er with values that do not occur in valid 802.11 frames. Once these bytes are being modi ed, we know a frame is being received, and can read the already decoded bytes.

The AR9271 datasheet says about the MAC_PCU_RX_FILTER:

If any bit is set, the corresponding packet types pass the filter and are DMAed

and e.g. regarding the beacon filter:

Beacon frame enable; Enable reception of beacon frames.

Now the question for me is, will that Atheros RX_Filter functionality also abort the frame reception as soon as possible (i.e. after it has read the headers required to determine what type of frame it is), like described in the security research paper above? Or will it still decode the whole frame first (and thus not be able to receive other frames during that time) and then throw it away?

To me it seems easier and more straight-forward to change (already existing) rx filter settings than to do such advanced things like in that security paper, so I hope this can be achieved by using the Atheros rx filter settings.

Can you maybe give me a pointer where those rx filters you describe are set?

[erikarn]

Hi,

RX filter only controls what is sent up. it still attempts to decode a packet no matter what.

-adrian

[rfelten]

Luckily @vanhoefm is a cool guy and - unlike many other CS papers - he provides (and still maintain (!)) the source code. Maybe a look on his implementation gives some insights? https://github.com/vanhoefm/modwifi-ath9k-htc

I'had only a brief look on the src, but this look like the implementation of an abort of a frame during reception. (Please note there where several bugfix releases after this commit ... )

@rodizio1 maybe you want to be a cool guy too :) And share your work on source code level and allow others to reproduce your work? And build on it, like you did on befinitiv's work? Yes, this is a hint to #6. :-)

[rodizio1]

Have seen the code, but my C skills are not sufficient for that. I hoped it was possible to achieve this by just setting a register or so.

Regarding sharing my work: All source code is available and Befinitiv is being credited and linked right in the first sentence of the readme, so I'd say it's all fine (and I'm cool anyway ;-) ...) Issue Number 6 is about creating a build script (which would just cause a lot of work for me and not make EZ-Wifibroadcast any better ...) I don't see the point in that.

[makesens86]

@rodizio1 Hi, I leave this message here since I couldn't find your e-mail address. I am working on the similar things you tried (for example, ignoring beacon frames that a STA doesn't need to receive, and receive data frames during the beacon period). If you found solution for this issue, could you share the solution? Please contact me via my e-mail (hjlee@netlab.snu.ac.kr) Thank you very much.