This is our old Q&A Site. Please post any new questions and answers at

We are trying to capture the 802.11 ping packet flow over the air between 2 STAs connected to the same AP.


connect STA1 to AP ---> connection successful and gets the IP address, MAC address: 18:FF:0F:11:64:46
connect STA2 to AP ----> connection successful and gets the IP address MAC address: 18:FF:0F:11:45:22
use the "ping -c 1 on STA1 ( from STA 1 to STA2)

We could observe that ping command is successful on the STA1 with 0% packet loss.

We expected packet flow based on the

for ICMP echo request:
1) ICMP request from STA1 to AP
2) ACK from AP to STA1
3) AP sending the ICMP packet to STA2
4) STA2 sending the response to AP

for ICMP echo response:
5) STA2 sending the response to AP
6) AP sending the ACK to STA2
7) AP sending the ICMP reply packet to STA1
8) STA1 sending the ACK to AP

But from the packet capture file(ping_packet_flow.png 194 -210 ), we observed:

ICMP request is going from STA1 to STA2
ICMP reply from STA2 to STA1 via AP

We are not able to the intermediate packets as mentioned in steps 2,3,4 and 6,7,8.

Is this expected flow or we are missing some Wireshark configuration to capture the intermediate packets. Wireshark packets are attached for reference

Please do let me know

Note: 1. AP configuration: 2.4Ghz, channel 6, open security, shield room with no interference alt text

asked 26 Apr '16, 04:06

rajeshrao's gravatar image

accept rate: 0%

edited 26 Apr '16, 08:46

sindy's gravatar image


Please publish the capture, login-free, somewhere like at Cloudshark (preferred at this site), Google drive, MS One drive, Dropbox, ... and edit your Question with a link to it. Screenshots are almost useless for any analysis.

(26 Apr '16, 08:50) sindy

Hi Sindy,

thanks for the response. i have uploaded the wire shark packets to cloudshark. link is

thanks Rajesh

(26 Apr '16, 22:58) rajeshrao

To follow your list:

1) ICMP request from STA1 to AP - frame #194 (IP addresses are the topmost ones)
2) ACK from AP to STA1 - frame #195 (only MAC address of STA1 is present, correct)
3) AP sending the ICMP packet to STA2 - not seen in the capture
4) STA2 sending the response to AP - not seen in the capture

5) STA2 sending the response to AP - frame #210 (IP addresses are the topmost ones)
6) AP sending the ACK to STA2 - frame #211 (only MAC address of STA1 is present, correct)
7) AP sending the ICMP reply packet to STA1 - not seen in the capture
8) STA1 sending the ACK to AP - not seen in the capture

I would have several possible explanations:

1 - the STAs are also connected by Ethernet so the AP forwards the frames received through WiFi using Ethernet,

2 - (the antenna of) your monitoring equipment is too close to (the antenna of) the AP, so the monitoring receiver is overloaded by the strong signal of the AP so the frames sent by the AP often cannot be demodulated. This is supported by the fact that frames sent or forwarded by the AP indicate RF levels around 0 dBm which is much higher than those of the STAs,

3 - the monitoring mode of the driver used at the monitoring equipment doesn't work properly and doesn't report some frames

Can you please repeat the exercise after placing the capturing device farther from the AP (or throttle the AP transmit power about 10 dB) to exclude possibility #2 (and, of course, disconnect any eventual Ethernet cables to exclude possibility #1)?

Is the capturing device using a Realtek chipset?

(26 Apr '16, 23:48) sindy

in the step 6) mentioned above "AP sending the ACK to STA2 - frame #211 (only MAC address of STA1 is present, correct)" is incorrect. it should be "only MAC address on STA2"

these are my comments on your explanations

1) STAs are connected to each other through AP, so there is no Ethernet connection at all.

2) we have conducted this experiment in a shield room keeping the both STAs and APs, monitoring receiver very near. we can try to keep the receiving device away from the AP and check the behavior

3) same behavior is observed with the omnipeek tool also. so i dont think there is any issue with the receiving device.

(27 Apr '16, 02:04) rajeshrao

it should be "only MAC address on STA2"

copy-paste without postprocessing, sorry for adding confusion.

keeping the both STAs and APs, monitoring receiver very near.

Nevertheless, the reported levels from the STAs and from the AP differ significantly - around 0 dBm for the AP and between -30 - -40 dBm for the STAs. As the signal strength decreases proportionally to the square of the distance between antennas, a small difference in distance between signal source and monitor may cause a large difference of signal strength at the monitoring receiver even if all sources transmit with the same power.

same behavior is observed with the omnipeek tool

If by "the Omnipeek tool" you mean hardware, it is a supportive argument for the monitoring to be fine; if you mean just the Omnipeek software replacing Wireshark, it is not an argument as the WLAN card driver and its monitoring mode are the same for both.

An additional chance (which doesn't seem much likely to me but cannot be excluded) is that the WLAN uses several radio channels or even bands simultaneously and the monitoring device only listens at one of them.

The reverse scenario, i.e. that the monitoring device would be hopping from channel to channel and thus miss part of the frames, does not seem likely when looking at the inter-frame times.

Yet another possibility could be that when forwarding the frames received from one STA to the other one, the AP uses some modulation scheme which the monitoring device (or both of them) is unable to demodulate.

(27 Apr '16, 02:28) sindy

tried the following things:

1) Keeping the monitoring device from the AP(around 5m): No change in the behavior still intermediate packets are not captured

2) reduced the AP transmission power by 50% : No effect - No intermediate packets

3) made the monitoring device to listen for channel 1, 6 and 11 - No effect and no intermediate packets

(27 Apr '16, 06:14) rajeshrao

In cases 1) and 2), what is the signal receive level reported for packets sent by the AP? You can use display filter wlan.ta == e0:3f:49:28:9e:90 to limit display to such frames.

If you haven't already, can you use for monitoring the same type of WLAN adaptor which you use as STAs? That should exclude the possibility that an advanced modulation scheme is the reason (as the STA's WLAN adaptor must understand it as the icmp request and response have been delivered).

Otherwise I've ran out of ideas.

(27 Apr '16, 06:27) sindy

is it correct to expect the packets 3, 4, 5 and 6 (refer original question) to see in the air when the ping transaction takes place?

it would be great if you can share the ping packets transaction in your machines.

(28 Apr '16, 00:44) rajeshrao


Your "answer" has been converted to a comment as that's how this site works. Please read the FAQ for more information.

(28 Apr '16, 02:06) grahamb ♦

Aren't we looking at Direct or Ad-Hoc mode here?

(28 Apr '16, 02:38) Jaap ♦

I don't think so as the icmp request shows

Receiver address: AsustekC_28:9e:90 (e0:3f:49:28:9e:90)
Destination address: IntelCor_11:45:22 (18:ff:0f:11:45:22)
Transmitter address: IntelCor_11:64:46 (18:ff:0f:11:64:46)
Source address: IntelCor_11:64:46 (18:ff:0f:11:64:46)
BSS Id: AsustekC_28:9e:90 (e0:3f:49:28:9e:90)
STA address: IntelCor_11:64:46 (18:ff:0f:11:64:46)

So the receiver and destination differ, which would not be the case in any of the AP-less modes.

(28 Apr '16, 02:47) sindy

This ping test is not for the ad-hoc mode. its for the infrastructure mode where 2 devices are connected to same AP and ping test is conducted between the devices.

(28 Apr '16, 03:12) rajeshrao

This looks like a case of not being able to decode the FromDS unicast data packets because of the modulation (as has been floated already). When I look at the beacons for this SSID, I see 802.11n with 3 spatial streams supported:

wlan.bssid == e0:3f:49:28:9e:90 Rx Modulation and Coding Scheme (One bit per modulation): 3 spatial streams

I don't see in any of the notes where you told us exactly how you were capturing traffic. When using OmniPeek on Windows, I need to use specific adapter chipsets that don't seem to work with Wireshark (for me, anyway). With Windows, I use AirPcap adapters sometimes but these have issues. They integrate easily into Wireshark, but, for instance, with AirPcap Nx, I found it does not support SGI with 802.11n frames, so these are not captured. I can see MCS7/1SS/20MHz up to 65Mbps, but not 72.2Mbps.

On Linux, more devices support monitor mode + promiscuous mode, but there is even more variability in what is picked up. It seems clear, though, that the frames ARE there, as you claim no packet loss at application layer (i.e. ping results are good). So we infer the frames exist, but your capture technique cannot pick them up.

I don't see the probes for the devices under test to know what they support - are they multi-stream as well? I can only see that they send frames at 802.11g rates, so you see these fine in the ToDS direction. Propose next test: tune your AP to so it does NOT support 802.11n, only b/g. Do you see the frames now? The other packets from this BSSID in the FromDS direction that are data are all broadcast/multicast, so are sent at some basic rate, so we need to look for unicast packets.

(28 Apr '16, 04:11) Bob Jones

@Bob Jones = very good suggestion. Configuring the AP to operate in 802.11g will remove the variable of the capturing adapter not being able to demodulate the frames. It should also remove any Block-Acknowledgements (BA).

Some other suggestions:

  1. Ensure your capturing machine is running on a separate machine and not being utilized as part of the test equipment. That means your set-up should include an AP, 2 WiFi stations connected to the AP and the capturing computer. Do not use the capturing computer to send/receive frames.

  2. You mentioned that the test was took place in a shielded room. Then why do we see all the other WLAN's? You should have a clean environment with only SSID "TSIE_CWS_ASUS_RF2_2.4" (BSSID = e0:3f:49:28:9e:90) being broadcasted.

Items #1 and #2 might seem trivial, but they are not. Many frames in a WiFi capture are not captured because of a busy WiFi environment and/or a busy processor (i.e., capture machine is busy doing other processes instead of capturing your traffic!).

Finally, as Bob Jones suggested, the driver used to capture WiFi traffic is very important. You mentioned OmniPeek. Great tool, but they only support a limited number of WiFi adapters:

If you are not using these adapters, then the drivers will not work correctly. If you want to use Wireshark, you will run into the same problem. Some drivers do not support monitoring mode, which makes them useless for WiFi capturing. (NO promiscuous mode in WiFi is NOT a solution. It causes more confusion then it solves!!)

(28 Apr '16, 08:58) Amato_C
showing 5 of 14 show 9 more comments

Hi All,

After configuring the AP in the 802.11g only mode, i am able to see the ICMP req packet being sent by the AP to the STA2. Thanks all for your great support.

permanent link

answered 10 May '16, 06:48

rajeshrao's gravatar image

accept rate: 0%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 26 Apr '16, 04:06

question was seen: 3,910 times

last updated: 10 May '16, 06:48

p​o​w​e​r​e​d by O​S​Q​A