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

Hello guys,

I'd like to check the traffic in/out from my wireless camera.

I need to know the who it talks to.

Now the camera has a internal ip of 192.X.X.X

If I start capturing with filter: host 192.X.X.X I get only traffic in/out the camera which is good but if I connect to the camera from my iPhone app Wireshark doesn't capture any traffic in/out the camera.

can anybody help me with this issue?

Thanks in advance



asked 27 Apr '16, 15:46

64rl0's gravatar image

accept rate: 0%

Check this older question regarding a similar topic and the answer to it. If it does not help, come back here.

permanent link

answered 28 Apr '16, 00:43

sindy's gravatar image

accept rate: 24%

Thank you very much!!!!!

I've got OS X so the only think I now need to find is monitoring mode, isn't it?

Do I need to turn promiscuous mode off when I turn monitoring mode on?

Thank again



(28 Apr '16, 00:50) 64rl0

I've converted your "Answer" (which it was not) into a Comment to my Answer, which is how this site is supposed to work, see site FAQ.

Do I need to turn promiscuous mode off when I turn monitoring mode on?

No, if the WLAN driver is in monitoring mode, the destination MAC address filter, which you normally deactivate by setting promiscuous mode, is not active.

But bear in mind that if your WLAN uses encryption, you have to capture the encryption key negotiation phase of all devices except the Access Point (your wireless router) whose traffic you want to see above the 802.11 layer (so in your case, it would be the camera and the iPhone). So if it is the case, first start the capture in monitoring mode on your MAC, then restart the camera, and then switch off and on WiFi on the iPhone. After that, you have to tell Wireshark the passphrase to your WLAN. Instructions can be found e.g. here but there are several simpler answers around here.

This is only necessary in monitoring mode - in promiscuous mode, you didn't need to care as there it is the driver that takes care of WPA so you get the frames decrypted.

(28 Apr '16, 01:09) sindy

Hello Sindy,

I followed all the steps:

•capture options -> interface: Wi-Fi -> monitoring mode: enabled

•start capturing

•802.11 Preferences

•Decryption Keys -> edit

•add Key type: wpa-pdw

•add Key: password:ssid

everything looks ok now my question is:

why it doesn't capture anything if I set ipv4 host on the camera IP? It does capture lots of date if I don't set any filter.

What I'd like to do is monitor which external ip address the camera sends data to.

It is a cheap camera from Amazon and I'd like to know if the camera sends information to anyone else rather than me.

This is the reason why I'd like to monitor the traffic in/out from the camera.

Thanks in advance



(28 Apr '16, 12:35) 64rl0

Ok I'll add a bit more of info after all the tests I've run.

I can now tell that nothing is working with the wpa.

I created a new network 2.4ghz without security. Connected camera phone and MacBook to that network. Start monitoring and everything was PERFECT!!!!!! Start monitoring again with filter host X.X.X.X and again PERFECT!!!!!!

I then removed the test SSID and connect everything back to the standard one. Start monitoring with filter host and NOTHING!!!!

802.11 preferences I set it on wpa-pdw ->password:SSID. and I set wpa-psk as well with the raw generator.

Unfortunately nothing




(29 Apr '16, 00:47) 64rl0

I can now tell that nothing is working with the wpa.

As it works for almost everyone else, I dare to ask you whether you haven't forgotten that in order to allow Wireshark use the password:ssid tuple for WPA decryption, you have to capture the negotiation of encryption keys between each of the devices (STAs) of interest and the AP as part of the capture. The display filter which shall quickly show you whether you have really captured them is eapol. In the Info column of packet list, you must see "Key (Message 1 of 4)" through to "Key (Message 4 of 4)". If you've missed any of the EAPOL frames while capturing for a given device, the decryption for that device won't work.

The EAPOL negotiation takes place each time the STA associates to the WLAN, and the negotiated keys differ each time and for each device even though the passphrase is the same for all. Switching the device off and on is one possibility how to enforce the EAPOL negotiation, but you may use a smaller hammer on some devices - switch off an on only the WLAN connection, or switch the device to sleep mode and wake it up again. But I suspect that the only method for the camera will be a power cycle.

If you can see that you have captured all the EAPOL packets but the decryption doesn't work anyway, I'd suggest you to temporarily change the passphrase to some other one which you're really unlikely to use normally, take the capture including the association phase of the devices, and publish that capture, login-free, somewhere like at Cloudshark (preferred by the community around this site), Google drive, Dropbox, ... and provide a link to it here so that we could have a look what may be wrong without disclosing the passphrase you use normally.

(29 Apr '16, 10:46) sindy

hello Sindy,

I think my decryption key doesn't work. I can't understand where I got it wrong.

So, here a picture of what happen after I start a capture in monitor mode:

•start capture

•turn Wi-Fi off/on on my iPhone

•browser on iPhone apps

•taken screenshot

as you can see I've got "Key (Message 1 of 4)" through to "Key (Message 4 of 4)" but I can't filter the iPhone ip X.X.X.X




(29 Apr '16, 14:30) 64rl0

Above Decryption keys in the list of 802.11 Protocol Preferences, there is [] Enable Decryption. Is the tickbox checked or not? If yes and decryption doesn't work, is there a colon (:) symbol in your passphrase or SSID?

And as already said - if we eventually should proceed further, you'd have to publish the pcap file, not just some screenshots, and in order not to disclose your real passphrase, you'll have to change it before taking the capture to be published.

(29 Apr '16, 22:33) sindy

Hi Sindy,

yes, enable decryption is ticked, and this is how I ì've inserted my detail.

here a copy of the pcap with SSID: The Wolf and Password: 123456789 WPA2/PSK AES

(30 Apr '16, 04:15) 64rl0
showing 5 of 8 show 3 more comments

I put in your SSID and passphrase and cannot determine what the issue might be with decryption because of the real issue: there are no data frames to decrypt.

With a filter:


I see two sets of full 4-way handshake:

alt text

for devices

(wlan.bssid == 00:1d:aa:ea:ca:42) or (wlan.addr == 6c:72:e7:05:60:60)

So the only frames that could be decrypted are after this 4-way handshake, and before the next set (i.e. as long as this PTK is in use, so up to a rekey, death, disassociate, etc). Group key traffic is handled a little different, but a detail not likely critical here.

This filter gives me the frames for wlan client, and show only good ones:

(wlan.addr == 6c:72:e7:05:60:60) and wlan.fcs_good == 1

So I don't see any Data frames between frame 3312 (Key 4 message) and a disassociate in frame 3594.

Your issue is not decryption, it is capturing packets. I see both client and AP support 802.11n/ac (HT/VHT). How are you capturing in the local RF environment? I see the Checksum is passed up but no MCS index value, what capture device are you using? Is it 802.11abg capable only?

I can infer traffic is passing between devices due to the block ACKs, CTS/RTS, etc. These are sent usually transmitted at lower rates so probability is that we are more likely to see these than data frames which would be sent at a higher rate/modulation.

Note this finding might be consistent with the claim that a 2.4GHz/unencrypted environment was setup and all worked well. Apple devices will not use 802.11n rates (and no device can do 802.11ac) on 2.4GHz, so perhaps the recognition of unencrypted traffic was due to the capture mechanism handling 802.11b/g rate frames properly. I note this capture is on channel 36 (5GHz). So we have two changes compounding the difficulties: 5GHz and capture of likely high speed unicast frames and encryption. Perhaps try encrypted 2.4GHz configuration to see if you can get decryption to work, then address the other modulation issue with 5GHz.

I also note that this is not generally true:

No, if the WLAN driver is in monitoring mode, the destination MAC address filter, which you normally deactivate by setting promiscuous mode, is not active.

I have a handful of adapters with various chipsets that support monitor mode but not promiscuous mode. I do agree that checking the box in Wireshark for promisc mode has no effect, but general searches on Google for this topic make similar claims: monitor mode is all that is needed. Perhaps there is a better term or concept so this might be technically a correct statement, as written, but practically it is a myth. Not all chipsets pass up unicast frames from other hosts even of they do monitor mode. Perhaps this behavior is a bug and monitor mode is supposed to mean no filter, but it happens.

permanent link

answered 30 Apr '16, 05:11

Bob%20Jones's gravatar image

Bob Jones
accept rate: 21%

@Bob Jones, you've made me delete an already written comment :-)

I was wondering how comes that the capture with WPA off did contain the data frames carrying IP packets while the WPA one doesn't; if the interdependency you describe (i.e. that the frequency band and modulation scheme used depends on security mode chosen) exists on some devices, it explains a lot.

As for my (over)statement, do you say it should have actually read "No, if the WLAN driver is in monitoring mode, ticking the promiscuous mode in Wireshark won't make any difference because it depends on the particular WLAN driver whether it filters frames by destination MAC address or not, and the promiscuous mode setting in Wireshark cannot change this"?

@64rl0, in your particular case the above should not be an issue, given that your adaptor in the Mac machine does let through unicast packets sent to different destination MAC addresses.

(30 Apr '16, 05:26) sindy

Thanks Bob,

I'm using a macbook pro and its only capable of 802.11/abgn its not capable of ac.

so what I did was to turn 5Ghz off in the router and leave only 2.4 on. unfortunately I can't see any difference in the capturing.

here another capturing with SSID: test and Password: /none/

as you can see I can filter camera ip and lots od UDP data that I can't see when I use an encrypted network

why can't I achieve the same results of the result with

SSID:test and password /none/

when I use

SSID: The Wolf an d password 123456789




(30 Apr '16, 05:41) 64rl0

(i.e. that the frequency band and modulation scheme used depends on security mode chosen)

In this case it was a 'user' choice to make both changes: going from something (presume 5GHz... but no trace so we can't tell) to 2.4GHz AND turning off encryption. I know Apple devices (nor Cisco APs) won't do 40MHz on 2.4GHz so I actually mis-typed - they will do some n rates, just not the wide channels - sorry for my confusion. I was looking at his beacons and they are set for 40MHz for 802.11n,

.... .... .... ..1. = HT Support channel width: Transmitter supports 20MHz and 40MHz operation

and looks like 80MHz on ac as well:

.... .... .... .... .... .... ..1. .... = Short GI for 80MHz: Supported

Since the network appears to support high speed rates with n/ac, wide channels, etc., his unicast frames will be high speed so they will be difficult to capture.

And I do agree with the new comment regarding promiscuous mode. With these devices, nothing I do changes the behavior until I get a new driver. My MacBook does monitor+promisc out of the box, but, for instance, here is a regression in the Linux kernel:

(30 Apr '16, 05:48) Bob Jones

In the file test1.pcap, after frame 64583 I am able to decrypt device wlan.addr == 6c:72:e7:05:60:60 with your provided credentials. The positioning in the trace is significant because this is the first instance of 4-way handshake completion.

For instance, frame 64819 is:

64819 119.993339 0.00019 TCP 2412 130 -44 130 678 [TCP segment of a reassembled PDU]

(30 Apr '16, 09:06) Bob Jones

ok finally i solve my problem.

I found a website to convert my SSID and password in a spa-psk, added that to the 802.11 preferences, then turn 5 Ghz off in the router, rebooted the camera and voilà traffic has started appearing in Wireshark.

The only problem is as soon as I turn 5 Ghz on my macbook connects straight to it and Wireshark stops getting traffic from the camera.

I think it is because 2.4 and 5 have the same SSID and the macbook is connected to 5 and the camera is connected to 2.4.

But its alright because I got what i wanted.

now i know i need to turn 5Ghz off in the router if I need to monitor the traffic in my network.




(30 Apr '16, 12:05) 64rl0

Glad it's working for you. Some comments:

I found a website to convert my SSID and password in a spa-psk

I didn't have to do this to decrypt your traffic, so it should work but is not necessary. Wireshark can (does) the same calculation of converting an SSID and PSK to a PMK.

The only problem is as soon as I turn 5 Ghz on my macbook connects straight to it and Wireshark stops getting traffic from the camera.

This can happen, so have a look at this answer if you want to avoid this:

Use your particular channel that has camera communication. This assumes you don't want the MAC to be connected to anything. If you do, then obviously you don't want to do this, and you won't be able to capture a different channel at the same time.

i need to turn 5Ghz

You should be able to sniff 5GHz, it will just take more work to get the capture mechanism correct. Try the tool referenced in the link above and set your Mac as a dedicated sniffer to the 5GHz channel and proper width - I'm guessing 80MHz from the probes/beacons in an earlier trace - and see if you can catch the 5GHz traffic.

(01 May '16, 11:36) Bob Jones

Well, from what Carlo wrote over time I've concluded that while the AP supports 2.4 and 5 GHz simultaneously, the camera doesn't. And as the Mscbook Pro in monitoring mode remained tuned to the 5 GHz channel to which it was previously associated, it could only monitor at 5 GHz, and thus could only see part of the iPhone's 5 GHz traffic but none of the camera's 2.4 GHz one.

So while the AP can bridge the 802.11 frames between the camera and the iPhone, so the frames which the camera is sending to the iPhone could be spotted on the "5 GHz" portion of their way which spans from the AP to the iPhone (provided that the AP would be sending them using a modulation scheme the Macbook Pro would understand), to fulfil the task of finding out all IPs to which the camera is talking to, it is necessary to set the Macbook Pro to monitor at the proper channel at 2.4 GHz.

And, having myself no clue how to instruct the wireless driver what channel to tune to in monitoring mode (I don't own any Mac), I can imagine that Carlo also depends on what channel the adaptor was associated before the monitoring mode has been activated, and so the easiest way to make the Macbook Pro monitor at the right channel in 2.4 GHz band may be to simply disable the 5 GHz band on the AP.

(01 May '16, 12:00) sindy
showing 5 of 7 show 2 more comments
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: 27 Apr '16, 15:46

question was seen: 5,461 times

last updated: 01 May '16, 12:00

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