Anyone know why 802.11 Acknowledgement Frames have no source MAC address? I don't see it when I capture the packets from TCPDUMP or Wireshark from Linux with a monitor-mode and promiscuous-mode driver. How does the Access Point distinguish ACK frames from different 802.11 clients if there is no source MAC addresses in the frame?
I can see from all the captures that the ACK comes immediately after the frame is sent (around 10 to 30 microseconds) but that alone can't be enough to distinguish the source can it? Maybe each frame has some kind of unique identifier and the ACK frame has this ID inside it? Maybe there is identifying information in the encrypted payload since the WLAN uses WPA-PSK mode?
No, there is nothing encripted in 802.11 MAC ACK frames.
802.11 is a contention based protocol. ie the medium is shared by different STA's and AP's who all are working in the same channel [frequency] in terms of time. Those who wants to transmit are competing for medium , winner who gets medium starts transmitting.
As per 802.11 spec. , once a frame is on air, the next "SIFS" period medium should be free. ie no one is allowed to transmit.
At the end of SIFS, the reciever of unicast frame should transmit ACK. This is the rule.
SIFS [Short Interframe space] in 802.11 is ~10 microseconds for OFDM based 802.11 implementations [802.11 G,A]. For 802.11b its ~20 microseconds if my memory is correct. Thats why you are seeing 10 or 30 microseconds in between TX and ACK
So, everyone knows who is transmitting the ACK and whom the ACK is to. So no need to include source address, its implecit.
Why Source address not included?
To reduce the frame size and so to same power.
Hope it helps. If you got more questions on this, please feel free
ACK frames, like all 802.11 management frames, have a DA (Destination Address) and SA (Source Address) in their MAC header (both not to be exactly confused with just "MAC address, see below), and that's all what's needed in this context.
TLD;DR: In 802.11 context, "MAC address", SA (Source addr), TA (Transmitter addr), DA (Destination addr), BSSID or whatnot all look alike a 6 byte "MAC address" that we're familiar with from other technologies, yet they should not be confused.
And now for the demolition of "MAC address" concept in 802.11 context.
802.11 Acknowledgement Frames are parts of 802.11 managements frames, and 802.11 is "a set of media access control (MAC) and physical layer (PHY) specifications" (source).
What this mean - and this is a very important concept to grasp when working with Wi-Fi - is that 802.11 in itself, including its management frames, have nothing to do with "traditional" (say 802.3, aka Ethernet) PHY (layer 1) nor MAC (layer 2) layers - they are a kind of their own.
802.3/Ethernet, to continue with this analogy - or rather counter example - have no such thing as ACK frames, beacons, probe request, RTS/CTS, auth/deauth, association etc, which are all types of 802.11 management frames. These are simply not needed with 802.3, for the most part because wired Ethernet is not a shared media (that's IEEE terminology), that may lead to unreliability/collision as is air with 802.11/Wi-Fi.
The important consequence of this is that you should not expect a priori to meet other, more familiar concept nor data from other layer 1/2 technologies. Forget this, once for all.
Sure, Wi-Fi looks like it carry on some MAC and IP and TCP and or UDP or whatnot, and they do most of the time, but regarding management frames such as ACK, that's a different world - its own world. As it is, 802.11 could perfectly be used - and maybe is used in some niche use cases - to carry other higher level protocols than TCP/IP. And its MAC concept, though looking familiar with its 6 bytes, should not be confused in its form nor use to the MAC of 802.3/Ethernet. To take another example, 802.15 aka Bluetooth also have a 6 bytes MAC, yet that is again another thing.
And to take the 802.11 a contrario example, 802.11 layer 1/2 beacon frames for instance carry some info about SSID, supported rates, Frequency-hopping (FH), parameter set etc etc that have no counterparts in other L1/2 technologies.
Now, embrace the complexity of what is/are "MAC addresses" in 802.11...
And this is why, to take an example in day to day use, pcap/tcpdump have such weird filters such as wlan ra, wlan ta, wlan addr1, wlan addr2, wlan addr3, wlan addr4 - and the like for wireshark capture and display filter.
Right George..!!
In MAC format NAV timer is updated like that, while data frames NAV is updated while transmitting , It updates for
DATA frame + SIFS + ACK + SIFS
So there is clear for this time, only one AP <---> station is talking, all are waiting to be clear NAV time period, so doesn't need to add Source address as it is wasting frame bytes.
I came across same question and saw this stackoverflow question on internet.
If you think about it, if stationA is waiting for ack from stationB, that means stationA has pretty much secured/locked medium for that long (see Jaydeep's answer) time i.e. (enough time for 2SIFS + 1ACK assuming no follow-up transmission between these 2 stations).
Hence no other station is sending any frame (i.e. ack here), leading no need to distinguish ack.
Its just StationA is waiting for ack from stationB in that time window.
I'm using Wireshark to monitor network traffinc to test a new software installed on a router. The router itself lets other networks (4g, mobile devices through usb etc) connect to it and enhance the speed on that router.
What I'm trying to do is to disconnect the connected devices and discover if there are any packet losses while doing this. I know I can simply use a filter stating "tcp.analysis.lost_segment" to track down lost packets, but how can I eventually isolate the specific device that causes the packet loss? Or even know if the reason was because of a disconnected device when there is a loss?
Also, what is the most stable method to test this with? To download a big file? To stream a video? Etc etc
All input is greatly appreciated
You can't detect lost packets solely with Wireshark or any other packet capture*.
Wireshark basically "records" what was seen on the line.
If a packet is lost, then by definition you will not see it on the line.
The * means I lied. Sort of. You can't detect them as such, but you can extremely strongly indicate them by taking simultaneous captures at/near both devices in the data exchange... then compare the two captures.
COMPUTER1<-->CAPTURE-MACHINE<-->NETWORK<-->CAPTURE-MACHINE<-->COMPUTER2
If you see the data leaving COMPUTER1, but never see it in the capture at COMPUTER2, there's your loss. (You could then move the capture machines one device closer on the network until you find the exact box/line losing your packets... or just analyze the devices in the network for eg configs, errors, etc.)
Alternately if you know exactly when the packet was sent, you could not prove but INDICATE its absence with a capture covering a minute or two before and after the packet was sent which does NOT have that packet. Such an indicator may even stand on its own as sufficient to find the problem.
I want to store large number of packets in a pcap file (say around 200000) and then send it using tcpreplay . The problem is the loop option in tcpreplay sends at a very low speed .
Now I am capturing packets using wireshark but wireshark does not respond after sending a lot of packets . How can i increase the length of the pcap file by multiplying the number of packets already stored in it ? How can I achieve good throughput using tcpreplay?
If you'd like to multiple a single pcap, consider the mergecap command, shipped with wireshark.
Regarding the packet pumping speed of tcpreplay take a look at its FAQs, and in particular consider the -T option to pick a timer mechanism that works well. I've found rdtsc to work very well. Also consider using a short trace that fits into memory, and iterating playback of that, to avoid disk I/O. For this, consider the -K option.
when does Wireshark timestamp the packets? After fully receiving a frame? Or already at receiving the first bytes of a frame? I read the following description about Wireshark timestamps but this text only states: "While packets are captured, each packet is time stamped as it comes in".
Consider the following scenario and an accurate OS time:
sender ----> Wireshark ----> receiver
The sender starts the transmission of the frame at time x. The frame is fully received at the receiver at time y (y = transmission start x + frame length / link speed). Will the captured frame appear in the Wireshark with a timestamp close to x or will it be y?
Best regards,
Jonas
Well, Wireshark doesn't time stamp the packets itself; it relies on libpcap to do them and, on almost all operating systems, libpcap doesn't time stamp them itself, either, the OS's packet capture mechanism, as used by libpcap does. The main exception is Windows, where WinPcap has to provide its own capture mechanism in the kernel, atop NDIS, but the mechanism behaves very similarly to the mechanisms inside most UN*Xes, and will give similar behavior. (The other exception is HP-UX, where the OS's capture mechanism doesn't time-stamp packets at all, so libpcap does so; that gives answers that are somewhat similar to other OSes, but with a potentially even longer delay before the packets are time-stamped.)
If Wireshark (or any other packet sniffer!) is run on the sender, the packets will be "wrapped around" within the OS and handed to the capture mechanism; the time stamp could be applied before the sender starts transmitting the packet, but the time stamp will be closer to x than to y.
If Wireshark (or any other packet sniffer) is run on the receiver, the time stamp is applied at some time after the entire packet has been received; that could involve delays due to packet being queued up, interrupts being "batched", some amount of network-stack processing being done before the packet is time stamped, etc.. The time stamp will be closer to y than to x.
If Wireshark (or any other packet sniffer) is being run on some third machine, passively sniffing a network, the time stamp will probably be closer to y than to x, but there's a difference due to the receiver and the sniffer being separate machines that might see the packet at different times, have different code paths for receiving, etc..
I have a ton of wireshark traces containing varying amount of ISCSI packets. I need to parse out the command being sent by the initiator (in bytes) and write it to a file for each packet. I was originally going to do this manually, as it is easily viewable inside the wireshark application (see SS below), but some of these traces are huge (1-2 Gb), and it would take forever to do by hand.
I've been looking into tshark and rawshark documentation, but I'm not sure either is able to get me what I need. A friend suggested using libpcap to parse the traces myself, but from what I can tell I'd need to find some way to identify the bytes I need to pull out of each packet. Ideally I'd like to use something that recognizes it for me (ie wireshark's ISCSI dissector).
Can anyone point me in the right direction? I need some way to parse out these commands from each ISCSI packet without looking through the raw packet data and trying to identify which bytes I need. As a note - It's not always the last 16 bytes in the packet as shown above, so I can't just go through and take the last 16 bytes.
If you export the packets to PDML/XML (File->Export...->File->Save As Type PDML) you will get a nice XML file with all the protocol fields. You may be able to use this for your requirements, or use it as an index to locate the raw bytes in each packet.