We are trying to capture the 802.11 ping packet flow over the air between 2 STAs connected to the same AP. steps: connect STA1 to AP ---> connection successful and gets the IP address 192.168.1.252, MAC address: 18:FF:0F:11:64:46 We could observe that ping command is successful on the STA1 with 0% packet loss. We expected packet flow based on the https://wiki.wireshark.org/Wi-Fi for ICMP echo request: for ICMP echo response: But from the packet capture file(ping_packet_flow.png 194 -210 ), we observed: ICMP request is going from STA1 to STA2 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 edited 26 Apr '16, 08:46  sindy showing 5 of 14 show 9 more comments |
One Answer:
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. answered 10 May '16, 06:48 rajeshrao |
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.
Hi Sindy,
thanks for the response. i have uploaded the wire shark packets to cloudshark. link is https://www.cloudshark.org/captures/85182b2c8b43
thanks Rajesh
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?
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.
copy-paste without postprocessing, sorry for adding confusion.
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.
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.
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
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:90to 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.
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.
@rajeshrao
Your "answer" has been converted to a comment as that's how this site works. Please read the FAQ for more information.
Aren't we looking at Direct or Ad-Hoc mode here?
I don't think so as the icmp request shows
So the receiver and destination differ, which would not be the case in any of the AP-less modes.
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.
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.
@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:
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.
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:
https://mypeek.wildpackets.com/driver_downloads.php#bestPractices
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!!)