Iphone Sniffer
Rolando Kumar
I've got a few wifi issues at the moment, can someone recommend a good free 'wifi sniffer' app for my iPad. I use iStumbler on my mac as this shows all the things I would need, signal strength, channel number etc. But not sure of a good/similar app for the iPad.
The apps like iStumbler that show you details about available WiFi networks were pulled a year or so ago. The WiFi "finder" apps currently available just tell you where there are WiFi hotspots base on location. Not quite the same, unfortunately.
We are attempting to use the Nordic Sniffer app on a DK52 board to sniff and troubleshoot BLE communication issue with our board/app and iphone/app. During sniffing we can also watch a display on the iPhone that shows a transmitted count value. When inspecting the packets for each transmission, we find missing packets on the Wireshark display that the iPhone properly displays the count for. Obviously the packet was sent.
I have attached a short capture file with a missing packet. if you look at the value column you will see that there are two values shown at packet 1 and packet 134, There should have been another packet displayed at 69. The packet was definitely transmitted, as it was received and shown on the master within the load of these packets is a string message with a countdown. The countdown value in packet 1 is "64". The countdown value in packet 134 is "62". There should have been a load at packet 69 with the a countdown value of "63".
I have some trouble with the CC2540 BLE Sniffer. My problem is, that i don't exactly know how the settings should be, that i can sniff the communication between my iPhone(Multitool App) and the CC2541 Keyfob. If the Keyfob is looking for a device I can sniff some data, but as soon as I connect it with my iPhone, there is nothing more sniffed. But I think after connecting if I press the buttons and they're recognized in the app or if I set the alert in the app and the Keyfob makes sounds, there should be some communication sniffed. Or am I wrong?
The sniffer can only sniff on one channel of the three advertising channels. If the connection is created on any of the other two, you will miss establishment and thus never be able to see more packets (as Bluetooth low energy uses frequency hopping and the channel map is distributed at connection establishment).
I have now read out the IEEE Address of my Keyfob to filter its packages out. This works but only when the Keyfob is advertising(the red LED is blinking fast). My problem now is that if I connect the Keyfob with the TI BLE Multitool App on my iPhone, it won't find packeges anymore.
The sniffer is probably simply missing the connection request. You can only sniff one of the three adv channels with the TI Sniffer. You can either try another channel (TI Sniffer: Radio Configuration -> Advertising Channel) or you can change your keyfob software to only advertise on the specific channel you are advertising on. This is done by something like this;
(Following Nordic's installation instructions) Currently I get all the way through the Nordic dev kit firmware loading, Wireshark installation, nrf Sniffer plugin installation and even the command line test of the nrf Sniffer plugin components (as Nordic's instructions direct), but Wireshark refuses to recognize and list the plugin among its available interfaces.
Step 3 of the instructions for installing the Wireshark plugin are to "Make sure that the nRF Sniffer files can be run correctly:". Did you do that? Did nrf_sniffer_ble.sh --extcap-interfaces produce output similar to what they describe?
I'm running on MasOS Big Sur 11.2.3, WireShark 3.4.4, and had a similar issue. I've tried all advice mentioned above but nothing helped me. This is what I understood. If you don't have installed Xcode - you won't have such troubles, simply install python 3 using brew, then install pip3 and install pyserial using pip3 and that's it. But If you have installed Xcode on the machine - the WireShark will use python3 from the Xcode's framework and this will cause such problems, and neither reinstalling python3 nor specifying the correct PATH in the profile (bash_profile, zprofile, etc) won't help you to resolve the problem. What helped me:
Thank you so much for posting this, that was exactly my issue. I sometimes do Python development so I have pyenv installed, which changed my global Python, preventing pyserial from being recognized by Wireshark.
I.e., the output from the script doesn't have any "interface" lines listing any interfaces on which to capture; it just has an entry for the extcap itself (the "extcap" line), lines for the controls it offers (the "control" lines), and a line giving values for the selector ("choose one of these options") control 0 (the "value" line).
Guy,Double-checked firmware loaded in PCA10000 and PCA10040 Nordic boards. Here's the log of the command line script from the first. I presume the interface line right after the extcap line is what you're looking for. In spite of that, Wireshark still doesn't recognize this capture plugin on the Mac configuration running Catalina listed above. However, Wireshark does recognize the plugin on an older Mac running Mojave. So it looks like the problem is Catalina compatibility.
So either 1) there's a bug in the extcap code in your version of Wireshark that's not in the master branch version, 2) there's something else weird, but not Catalina-specific, here, or 3) there's something about the environment in which the script is run that keeps it from finding the Nordic ...(more)
Yes, the output is from a Catalina machine. And confirming proper access on that machine through the identified serial port, nRF Connect works just fine to program the PCA10040, etc., with hex files and debugging from SES (the Segger IDE) works just fine. So as you surmised, the problem doesn't appear to be the serial connection.Responding to your analysis:1) The Wireshark app used is a fresh download "latest stable", 3.2.2, macOS Intel 64-bit.dmg. I can try newer(beta?) and older releases. (BTW, I did try nRF Sniffer 2, the next to last Nordic plugin, with no change.)2) Yes, gremlins could be hiding in random places.3) Quite plausible! Catalina has changed lots of file security processes and hides lots of things to "make the system easier to use". For example, the home disk is now divided into at least two "disks" and the ...(more)
Folks at Nordic figured out the problem. Catalina comes with Python3 preinstalled. When I installed a fresh copy, I now had a duplicate. All my further installation of Wireshark and nRF Sniffer used my copy. The the Wireshark app ran, it used the system copy, which didn't have pyserial! See the Nordic thread here (sorry for the long URL):
Earlier releases didn't offer Python 3 at all, so, if Nordic's nRF Sniffer depends on Python 3, 1) it won't work on pre-Catalina systems if you don't install Python 3 but 2) if you do install Python 3, you don't have a collision between the OS's Python 3 and an installed Python 3.
I actually have an Ellisys USB Tracker 110b that I bought on eBay many years ago, but it only does low-/full-speed decoding. I thought this would be a good opportunity to upgrade my capabilities to also be able to handle high-speed USB sniffing, while also providing some good soldering practice.
I guarantee that would get old really fast. You would also need a pretty fancy oscilloscope or logic analyzer in order to decode 480 Mbps high-speed traffic while also having enough memory to record everything you want to see. Nobody actually does that though.
This is exactly where hardware USB sniffers come into play. They are essentially specialized logic analyzers that only know how to decode USB traffic. They do one thing, and they do that one thing very well: record raw USB traffic and stream it to your computer as fast as possible.
The really cool thing about this sniffer is that it integrates with Wireshark. You can make use of protocol decoders already built into Wireshark for interpreting USB packets, as well as its fancy filtering capability. Ellisys devices, in comparison, use a proprietary USB analysis program. Protocol decoding is unlocked for an extra charge of thousands of dollars.
To elaborate a little more, the host controller is handling a lot of the low-level communication under the hood such as checking checksums and combining multiple transactions into a transfer. That low-level info would be useless for normal device drivers because they can trust that the host controller has performed the high-level operation that was requested.
In the past two years or so I have been delving into Bluetooth Low Energy (BLE) for a project I did for one of our customers at Luminis Arnhem. In this project we have been tasked with implementing mobile applications for Android and iOS that used BLE to communicate with various products made by our customer. Because of this, a lot of my focus has gone to the BLE stacks that Apple and Google have created on their platforms for application developers to use.
Depending on the platform that you are developing, for there may already be options available that you can use to get access to such logging without having to put in a lot of effort. For iOS devices with an OS version higher than 13 for example, Apple already offers a solution using PacketLogger that is fairly easy to set up. I have not actually tried this solution myself yet, but as the solution I am about to propose builds on some of the same concepts I can say with some confidence that this will work. In fact if iOS is the only target you are focussed on I would probably advise you to just use this instead and forget about my solution (Keep reading though! It never hurts to learn).
ff7609af8f