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 Bye 64rl0 asked 27 Apr '16, 15:46  64rl0 |
2 Answers:
Check this older question regarding a similar topic and the answer to it. If it does not help, come back here. answered 28 Apr '16, 00:43  sindy 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:
for devices 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: 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:
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. answered 30 Apr '16, 05:11  Bob Jones @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. https://www.dropbox.com/s/qk1htlyz10pwx2v/test1.pcap?dl=0 here another capturing with SSID: test and Password: /none/ https://www.dropbox.com/s/11pauwbcvhpctn7/test2.pcap?dl=0 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 thanks Bye 64rl0 (30 Apr '16, 05:41) 64rl0
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 132.245.229.146 192.168.1.31 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. THANKS TO EVERYONE GUYS FOR ALL YOUR HELP!!!! Bye 64rl0 (30 Apr '16, 12:05) 64rl0 Glad it's working for you. Some comments:
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.
This can happen, so have a look at this answer if you want to avoid this: https://ask.wireshark.org/questions/52077/cant-capture-5ghz-traffic-on-os-x 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.
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 |
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
Bye
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.
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.
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
Bye
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
Thanks
Bye
Carlo
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.
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
https://i.imgsafe.org/534727d.png
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
Thanks
Bye
64rl0
Above
Decryption keysin the list of 802.11Protocol 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.
Hi Sindy,
yes, enable decryption is ticked, and this is how I ì've inserted my detail.
http://s32.postimg.org/o9waxx8id/Screen_Shot_2016_04_30_at_12_13_47.png
here a copy of the pcap with SSID: The Wolf and Password: 123456789 WPA2/PSK AES
https://www.dropbox.com/s/xmma38ejgwctg55/test.pcap?dl=0