I'm looking for documentation on how to parse 802.11 Action No Ack Management frames (Subtype 0d14), but I haven't found anything useful. Specifically I'm looking for a list of possible fixed parameters and their sizes.
Where can I find documentation that will tell me this information?
Looking at these packets in Wireshark, they all seem to only have one fixed parameter, VHT. However, just looking at my sample data does not convince me that's all that can appear there, or that it always will appear there.
Usually, these are defined in wifi spec like "IEEE Std 802.11™-2016"
You can still find out the definition from other wifi document, e.g.
wiki: https://en.wikipedia.org/wiki/802.11_Frame_Types
Action No Ack frame is the action frame which doesn't need Ack.
e.g. Link Measurement Request frame can be a kind of Action frame, or Action No Ack frame
https://njiot.blogspot.com/2019/08/wifi-action-no-ack.html
Related
I've set Wireshark's capture filter set to capture only packets from the MAC address of interest, but the result is dominated by zillions of packets whose Protocol is "802.11". I want to view all of the packets that are NOT 802.11, e.g. ARP, DCHP, DNS, TCP, etc.
For example, in the following, I'd like to hide all of the 802.11 packets and show the DHCP packets (and any others that are NOT 802.11):
I tried "wlan.fc.type != 0", but clearly that's not correct. What's the magic keyword for such a filter?
update
#ChristopherMaynard's comment is close, and I now understand that a simple filter of:
ip
is almost what I want, but it fails to display packets of type ARP, EAPOL, LLC, MDP and perhaps others.
[Converted comment to answer and added an alternate solution while I'm at it.]
If you just want data frames but those without un-dissected data (which would still show 802.11 in the Protocol column), then you could try wlan.fc.type == 2 and !data. Or you could try !(frame.protocols == "radiotap:wlan_radio:wlan:data" or frame.protocols == "radiotap:wlan_radio:wlan").
Another alternative is to download the filtcols.lua script written by Chuck Craft, save it to your plugins directory (Wireshark: Help -> About Wireshark -> Folders -> Personal Lua Plugins), the [re]start Wireshark. Now you can apply a display filter such as wlan and !(filtcols.protocol == "802.11").
After that I send different runicast messages with the function runicast_send, how can I understand which message was acknowledged when the callback sent_runicast is triggered?
The runicast.h file states:
The runicast primitive adds two packet attributes: the single-hop
packet type and the single-hop packet ID. The runicast primitive
uses the packet ID attribute as a sequence number for matching
acknowledgement packets to the corresponding data packets.
but I didn't understand how to do it in practice. Can somebody provide an example?
One way would be to look at the field sndnxt of struct runicast_conn *c before you send the packet, and then compare that value of the packetbuf_attr(PACKETBUF_ATTR_PACKET_ID) in the "sent" callback of your code.
However note that by default the runicast packet ID is just 2 bits long. Enough to demultiplex the ACK in most cases, but may be insufficient for your purposes. (The packet ID size in bits can be changed by redefining RUNICAST_PACKET_ID_BITS.)
Also Rime is obsolete. Don't use it in your code, especially production code unless you know what you're doing. runicast was never one of the highlights of Rime, I doubt there are no better alternatives (e.g. the uIPv6 stack) for what you want to do.
I was watching several wifi captures in wireshark and I bumped into two specimens I had never seen before. First of all, I thought that a IEEE 802.11 data frame would always be followed by a LLC header (802.2), provided that the frame actually contained data. Now I have a two wireshark captures showing otherwise !
First one, we can see an Ethernet II header following the wifi header :
Now that's the first thing I don't understand. How is an interface supposed to know, when reading the 802.11 Data header, that it is going to be an Ethernet II following ? There is no field in the 802.11 header specifying what's coming next.
Second is "raw data" directly following the wifi header.
Same question as before, how are we supposed to know that Data was following, and not LLC ?
First question:
To quote a comment in the Wireshark 802.11 dissector:
/* I guess some bridges take Netware Ethernet_802_3 frames,
which are 802.3 frames (with a length field rather than
a type field, but with no 802.2 header in the payload),
and just stick the payload into an 802.11 frame. I've seen
captures that show frames of that sort.
There is no field in the header that says "this is a bridged Netware Ethernet_802_3 frame", so Wireshark has to use a heuristic. The heuristic is "if the first two bytes of the payload are not both 0xAA, the first 6 bytes of the payload equal the destination MAC address, and the next 6 bytes of the payload equal the source MAC address, then this is a bridged Netware Ethernet_802_3 frame", in which case it calls the Ethernet dissector. Because this is a heuristic, it is, of course, not guaranteed to get the correct answer all the time.
IEEE Std 802.11-2012 says, in section 5.1.4 "MSDU format":
This standard is part of the IEEE 802 family of LAN standards, and as such all MSDUs are LLC PDUs as defined in ISO/IEC 8802-2: 1998. In order to achieve interoperability, implementers are recommended to apply the procedures described in ISO/IEC Technical Report 11802-5:1997(E) (previously known as IEEE Std 802.1H-1997 [B21]), along with a selective translation table (STT) that handles a few specific network protocols, with specific attention to the operations required when passing MSDUs to or from LANs or operating system components that use the Ethernet frame format. Note that such translations may be required in a STA.
"ISO/IEC 8802-2: 1998" is also ANSI/IEEE Std 802.2, 1998 Edition, so that says that the payload should begin with an 802.2 header. At least as I read IEEE Std 802.1H-1997, Ethernet frames without an 802.2 header should be translated to SNAP frames, using their Ethernet type value, when bridged to a LAN using 802.2, such as an 802.11 LAN. I guess, since Netware Ethernet_802_3 frames don't have a valid 802.2 LLC header and don't have a type field (they have a length field; I think that, as they don't have an 802.2 header following the Ethernet header, this means that they technically aren't valid Ethernet frames), they aren't covered by the specifications in question, so it's not technically a protocol error to just put the Ethernet packet, starting with the Ethernet header, into the data field. Presumably those packets are sent only to bridges, under the assumption that the bridge knows how to Do The Right Thing.
Second question:
The most common reason to see "Data" after an 802.11 header is that the packet in question is encrypted (WEP or WPA/WPA2) and Wireshark doesn't have the password for the network (and, for WPA/WPA2 Personal/Pre-shared key mode, doesn't have the initial EAPOL handshake in the capture; decrypting in Enterprise/802.1X mode is not supported).
Are you capturing on a "protected" (WEP or WPA/WPA2) network?
I have a DirectShow Transform filter written in Delphi 6 using the DSPACK component library. It is a simple audio mixer that creates a new input pin whenever a new connection is attempted. I say simple because once its media format is set, all connections to the its input pins or singular output pin are forced to conform to that media format. I build the filter chain manually, making all pin connections explicitly myself. I do not use any of the "intelligent rendering" calls, unless there is some way to trigger that unwanted behavior (in my case) accidentally.
NOTE: The Capture Filter is a standard DirectShow filter external to my application. My push source audio filter and simple audio mixer filters are being used as private, unregistered filters and are internal to my application.
I am having a weird problem that only occurs when I try to make multiple input connections to my mixer, which does indeed accept them. Currently, I am attempting to connect both a Capture Filter and my custom Push Source audio filter to my mixer filter. Whenever I try to do that the second upstream filter connection fails. Regardless of whether I connect the Capture Filter first or Push Source audio filter first, the second upstream filter connection always fails.
The first test I ran was to try connecting just the Capture Filter to the mixer. That worked fine.
The second test I ran was to try connecting just the Push Source audio filter to the mixer. That worked fine.
But as soon as try to do both I get a "no combination of intermediate filters could be found" error. I did several hours of deep digging into the media negotiation calls hitting my filter from the graph builder and then I found the problem. For some reason, the filter graph is dragging in the ancient "Indeo (R) Audio Software" codec into the chain.
I discovered this because despite the fact that codec did have a media format that matched my filter in almost every regard (major type, sub type, format type, wave format parameters), it had an extra 2 bytes at the end of it's pbFormat data member and that was enough to fail the equals test since that test does a comparison between the source and target pbFormat areas by comparing the cbFormat value of each media type. The Indeo codec has a cbFormat value of 20 while my filter has a cbFormat value of 18, which is the size of a _tWAVEFORMATEX data structure. In a way it's a good thing the Indeo pbFormat has that weird size because the first 18 bytes of its 20 byte area were exactly equal to the pbFormat area of my mixer filter's supported media type. Without that anomaly I never would have known that ancient codec was being drug in. I'm surprised it's being drug in at all since it has known exploits and vulnerabilities. What is most confusing is that this is happening on my mixer filter's output pin, not one of the input pins, and I have not made a single downstream connection yet when building up my pin connections.
Can anyone tell me why DirectShow is trying to drag in that codec despite the fact that the media formats for the both incoming filters, the Capture Filter and the Push Source filter, are identical and don't need any intermediate filters at all since they match my mixer filter's input pins supported format exactly? How can I fix this problem?
Also, I noticed that even in the single filter attachment tests above that succeeded, my mixer output pin was still getting queried for media formats. Why is that when as I said, at this point in building up my pin connections I have not connected anything to the output pin of my mixer filter?
--------------------------- UPDATE: 1 ----------------------------
I have learned that you can avoid the "intelligent connection" behavior entirely by using IFilterGraph.ConnectDirect() instead of IGraphBuilder.Connect(). I switched over to DirectConnect() and turns out that the input pin on my mixer filter is coming back as "already connected". That may be what is causing the graph builder to drag in the Indeo codec filter. Now that I have this new diagnostic information I will correct the problem and update this post with my results.
--------------------------- RESOLUTION ----------------------------
The root problem of all of this was my re-use of the input pin I obtained from the first destination/downstream filter I connected to my simple audio mixer filter, at the top of my application code. In other words my filter was working correctly, but I was not getting a fresh input pin with each upstream filter I tried to connect to it. Once I started doing that the connection process worked fine. I don't know why the code behind the IGraphBuilder.Connect() interface tried to bring in the Indeo codec filter, perhaps something to do with trying to connect to an already connected input pin, but it did. For my needs, I prefer the tight control that IFilterGraph.ConnectDirect() provides since it eliminates any interference from the intelligent connection code in IGraphBuilder, but I could see when video filters get involved it could become useful.
I need to write a rate limiter, that will perform some stuff each time X bytes were transmitted.
The straightforward is to check the length of each transmitted packet, but I think it will be to slow for me.
Is there a way to use some kind of network event, that will be triggered by transmitted packets/bytes?
I think you may look at netfilter.
Using its (kernel level) api, you can have your custom code triggered by network events, modify received messages before passing it to application, and so on.
http://www.netfilter.org/
It's protocol dependent, actually. But for TCP, you can setsockopt the SO_RCVLOWAT option to define the minimum number of bytes (watermark) to permit the read operation.
If you need to enforce the maximum size too, adjust the receive buffer size using SO_RCVBUF.