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

Capturing wifi http traffic of my own network


I am trying to debug an app on my smart tv and I need to capture the http requests it does. since the tv is in another room, im first testing with a tablet.

So first, I connect a wifi adapter (AWUS036H). Set it to monitor mode with airmon-ng start wlan0 8 (8 is my router channel).

Then I start wireshark, and start capturing on the interface wlan0mon. When I visit on my tablet, this is what appears on wireshark:

alt text

f0:4f:7c:xx:xx is my tablet mac address, if I remove that filter I still don't see any http traffic, all white stuff and nothing of the green stuff I see when capturing eth0.

So how do I capture the http traffic that goes thru my wifi router?

The wifi network is temporarily open btw, I removed all the security for the test.


I tried reenabling the router security (WPA2-PSK), reconnected the tablet while wireshark was running (to capture the handshake), and visited again. Added wpa-pwd:mypwd:ssid to the IEEE 802.11 protocol and when I click "apply", some packets that were previously identified as LLC protocol change to 802.11 protocol, so decryption seems to be working, but I still can't find any package containing http information.

asked 28 Jun '17, 23:21

wokcz's gravatar image

accept rate: 0%

edited 28 Jun '17, 23:52

One Answer:


I've never seen a block ACK with a layer 3 IP address included - they all have Receiver Address and Transmitter Address (RA/TA), which are MAC addresses. I guess you have Wireshark configured to do some mapping from L2->L3?

This looks like one of two problems:

  1. You are too far away from the devices under test so you can only see the low data rate frames. Lower data rate frames travel further, so you will pick this up at a greater distance. Data frames (since we see block ACK, I presume QoS-Data frames but applies to regular Data frames as well) will typically be sent at higher data rates so won't travel as far as management and control frames.
  2. The capture device does not have the same capabilities to pick up the modulation of the actual data frames you are looking for. For instance, your capture adapter is in monitor mode and can only do 802.11abg (just for an example). But the AP and the client you want to capture from can do 802.11 abgn/ac, 2SS, SGI, LDPC. You have no chance of picking up frames sent at the upper end of these capabilities with that adapter. Note from (1) that not all frames are sent at maximum data rates, so you will see SOME traffic, like mgmt/control frames, but you will miss most of the data.

Since you didn't provide a trace I can't look at signal strengths to determine if the issue might a distance problem, and I can't deduce the running network parameters because I can't see the beacons/probes/assoc frames for your network to determine the actual capabilities to compare to your capture adapter (which google says is 802.11bg).

Block ACKs usually come along with 802.11n or HT capability, so most likely your issue is (2). The data frames are sent at 802.11n rates, and the capture adapter can't pick them up.

What to do?

This comes up often here -

  1. Buy a better capture adapter with at least same or better modulation capabilities than the network under review
  2. Reduce the settings on the AP so that only 802.11bg is supported - no 802.11n / HT / WMM, etc. This will reduce your performance, but you might be able to pick up the traffic.

answered 29 Jun '17, 02:45

Bob%20Jones's gravatar image

Bob Jones
accept rate: 21%

Thanks for your reply. You were correct, the adapter only supports 802.11b/g and the router was set to use 802.11b/g/n. I've set b/g mode on the router and now I can see all the packets, including the http ones I needed. Thank you very much.

(29 Jun '17, 12:51) wokcz