Apimote very unstable and doesn't sniff packets correctly

[Faeris95]

Hello,

I have some issues with the ApiMote v4 beta. Sniffed packets are malformed (bad FCS) which I have not with an other sniffer and tool, it prints also many "#DEBUG Clearing overflow" lines in terminal.

I tried to reflash the firmware (with and without the --speed argument because it failed at first) and it gets even worst as the card recognition failed 3 times out 4: "See the GoodFET FAQ about missing info flash."

We test the sniffer and reflash it under several environments with same results : Fedora 30, Ubuntu 19.04, Ubuntu12.04 (in VM, as someone has suggested to try in an other thread) and Parrot OS (debian based).

Best regards

[rmspeers]

This doesn't seem like an issue that reflashing the same FW will fix. This we believe typically occurs when the laptop/computer is not running data quickly enough, so the packets back up on the ApiMote's internal memory, and it drops them. If you can't read faster, I'd suggest looking at updating the ApiMote firmware (GoodFET project ccspi.c file) to allocate a larger or more efficient ring buffer and read.

[Faeris95]

I've just tried it on a Macbook with same result as the others laptops.
I also tried to recompile the firmware from the GoodFET project and flash it as you recommend, however without modification, and killerbee crashed :

# DEBUG Clearing overflow
issue in peeking for a register
string index out of range
Traceback (most recent call last):
File /usr/bin/zbstumbler, line 4, in
import('pkg_resources').run_script('killerbee==2.7.1', 'zbstumbler')
File /usr/lib/python2.7/site-packages/pkg_resources/init.py, line 666, in run_script
self.require(requires)[0].run_script(script_name, ns)
File /usr/lib/python2.7/site-packages/pkg_resources/init.py, line 1453, in run_script
exec(script_code, namespace, namespace)
File /usr/lib64/python2.7/site-packages/killerbee-2.7.1-py2.7-linux-x86_64.egg/EGG-INFO/scripts/zbstumbler, line 199, in

File build/bdist.linux-x86_64/egg/killerbee/init.py, line 358, in pnext
File build/bdist.linux-x86_64/egg/killerbee/dev_apimote.py, line 195, in pnext
File build/bdist.linux-x86_64/egg/killerbee/GoodFETCCSPI.py, line 183, in RF_getrssi
File build/bdist.linux-x86_64/egg/killerbee/GoodFETCCSPI.py, line 84, in peek
IndexError: string index out of range

[rmspeers]

I didn't mean just recompile it, I meant that you would likely need to modify the code in the firmware to get it working first.

The crash issue I presume is different and due to a USB difference in macOS vs Linux? Have you debugged where that comes from?

[rmspeers]

Any updates here?

[elbrini]

Hello,
I have the same issue here!
Any suggestions?

[washcroft]

Same issue here, I believe there are issues in the ApiMote firmware that nobody knows how to fix or has the time to investigate - definitely not a speed/environment issue causing these Bad FCS packets.

I switched over to a CC2531 dongle (everything else the same) and instantly everything started working correctly, every packet fully intact, unfortunately this hardware only supports sniffing.

Pretty sad after stumping up for the "pro" ApiMote hardware that it simply doesn't work.

[rmspeers]

Correct, there are known stability issues as mentioned in the email sent to anyone who orders an ApiMote from RLS, it is beta due to the instability reasons, and thus why RLS offers it at cost of assembly. Also of note, you typically would want an ApiMote if you're doing low-level attacks (PIP, etc) on the PHY/MAC layers or things like reflexive jamming - but general IEEE 802.15.4/ZigBee attacks don't need that level of control.

@washcroft is correct that no one on the team currently has time to investigate the issues - they may be in firmware or in the FTDI chip configuration I'd note.

CC2531s are a great option for many users - and I encourage anyone interested to contribute injection support firmware for it!

[inode-]

Workaround at: #215 (comment)

[washcroft]

Workaround at: #215 (comment)

I don't see how that fixes the issue discussed here? The issue here is once you have ApiMote detected and running packet capture, most of the captured packets are actually garbage.

[inode-]

Workaround at: #215 (comment)

I don't see how that fixes the issue discussed here? The issue here is once you have ApiMote detected and running packet capture, most of the captured packets are actually garbage.

It fix the:

I tried to reflash the firmware (with and without the --speed argument because it failed at first) and it gets even worst as the card recognition failed 3 times out 4: "See the GoodFET FAQ about missing info flash."

I will execute some better test in the next days and I will let you know.

[rmspeers]

Packet corruption coming in @washcroft is likely due to it not keeping up with incoming packets fast enough, and thus having buffer overruns in the CC2420. I've suggested to people before that in these situations, if you do need to use the ApiMote v4beta, then a change to:

• use a ring buffer and read faster in the MSP430 firmware from the CC2420 makes sense, or
• maybe doing a fast read loop in a thread on the python side may work alone (but IMO likely also needs the above).

[inode-]

Ok, I found the problem, but I didn't know how to fix it...

@rmspeers the problem is not related to buffer overruns or python code

The problem is the packet generated from apimote contains two different packets, the data + the ack.

Here an example. This image is the data dumped with apimote.

Here same packet dumped with a CC2531.

I highlighted the same data transferred (without the CRC) and as you can see it's corrected. The rest of the data shown in the CC2531 are some added data by the sniffer.

All packet without an ack (for example the link status packets) are parsed correctly.

The same data can be also be viewed using the GoodFET tools with:

goodfet/client$ sudo ./goodfet.ccspi sniff 11

Any idea?

[federicodotta]

I have the same identical issue. The apimote collapse packets and ACKs. I tried with different XBee and Zigbee and on different operating systems. With the CC2531 I correctly sniff packets and ACKs, with the ApiMote I sniff wrong big packets, each of them composed by a packet plus a ACK. I didn't find a solution on this problem. :(

Any idea?