This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Sniffer Crashes

Other Parts Discussed in Thread: CC2540

I'm running the sniffer on a Windows 7 Professional SP1 64-bit machine. I've set the buffer cache to 255MB. A few seconds after I see data packets, the application crashes with the message "GenPacketSniffer MFC Application has stopped working". This is happened about 5 times in a row, so I don't think it's a fluke. Any possible solutions?

  • Moving to Tools forum.
  • Hi,
    Can you please provide some more information of the steps you do when this is observed? Which HW do you use as Sniffer device?

    Bjørn
  • Hi Bjørn,

    I'm using the CC2540 to sniff. I start it, see advertising packets, see the data coming through and then it usually crashes within a few seconds of the data packets appearing. The connection I'm sniffing has a ton of traffic (about 2KB/s), so perhaps that's why it crashes when the data packets start. By the way, I've also tried on a laptop running Windows 8 and 10, but the same issue occurs.

    Thanks,
    Rand

  • Hi,
    Which connection interval do you use on the connection? The Sniffer has been tested with quite heavy traffic, so this is interesting.
    Are you able to save a Sniffer capture that shows the connection establishment and data packet exchange, before it crashes? That would be helpful for us.

    Bjørn
  • Hi Bjørn,

    The connection interval is 7.5ms. Let me get permission to post the log, and I'll add it as well.

    Thanks,
    Rand

  • Any update on this? I just tried running it on a Surface Pro 4 running Windows 10 and it crashed soon after the connection was established between my tablet and BLE device.

  • According to my experiences, packet sniffer crashes when system RAM is not enough.
  • I don't see any spike in memory and have about 6GB free the whole time.
  • Whenever I re-open the app, I see two magenta error messages as shown in the attachment:

  • Hi,

    After you re-open the Sniffer app, can you please save the sniffer capture as shown in your photo and send it?

    Also, please check if there is a file under c:\temp. The Packet Sniffer buffers data temporarily to a file there. This file is deleted when the Sniffer is closed, but it might still be there when the Sniffer has crashed. If you have it please send this file also.

    From the logs, it seems that the Sniffer does not receive all packets from the Slave node. One thing you could try is to place the Sniffer closer to both nodes, and also both nodes closer to each other to get a link with less packet errors. Then check if the problem disappear.

    Bjørn

  • I've attached the sniffer capture.

    I didn't see anything in c:\temp after the crash.

    I moved the tablet, device and sniffer all right next to each other. The crash was pretty quick the first time. The second time it lasted much longer than normal, but it still crashed as seen in the attached 3240.log.psdlog.

  • Hi,
    Just to be clear, the two error packets are always shown in Sniffer after it has been restarted after the crash, right?
    Why does it show advertising packets after the error packets. Has the data exchange stopped in the meantime?
    Have you observed this same issue with longer connection intervals?

    I am not able to see what goes wrong just from these logs unfortunately. I think we would have to try recreate the setup here for further investigation, but I cannot promise when this can happen. I have filed a bug on this.

    Bjørn
  • Yah the error packets show up after opening the app back up after a crash and restarting the sniffing. There's a few minutes in between the error packets and the advertisement packets. The data exchange keeps going after the crash and the transfer completes successfully. Yep, I've seen the same issue with various types of devices at various connection intervals.

    Is the code open source? It would be easy to debug the crash if I had the source code on my computer.

  • The reason for this crash has been found. It was caused by a corrupt header length field in one of the received packets. The BLE parser in the packet sniffer was not protected well against this, and it caused a memory read out of range.


    We have made a workaround for this, but have not yet planned any next release of the Packet Sniffer.


    Regards,

    Bjørn