search

virtualabs / cc2531-killerbee-fw

Killerbee compatible ZigBee sniffer/injector firmware for TI CC2531 USB dongles
MIT License
39 stars 17 forks source link

Miss rate when sending ZigBee packet #1

Closed wang70880 closed 3 years ago

wang70880 commented 3 years ago

Hi, I am recently using your firmware, especially for the CMD_SEND_PKT part. I use KillerBee.inject to test it. It seems like that from KillerBee's output, everything is normal. But when I use Wireshark to sniff the spoofed packet, I found nothing.

So I am curious that how do you test your SEND_PKT functionality? Do you also use Wireshark to sniff the packets? Since I cannot sniff any packet, do you have any idea for me to debug it?

wang70880 commented 3 years ago

I just tried to send 100 packets at the same time, instead of 1. Finally I can sniff the packet in Wireshark. However, I only sniffed 64 packets, instead of 100. I guess there must be some problems because 36 packets are not sent.

virtualabs commented 3 years ago

I just tried to send 100 packets at the same time, instead of 1. Finally I can sniff the packet in Wireshark. However, I only sniffed 64 packets, instead of 100. I guess there must be some problems because 36 packets are not sent.

There could be an issue of course, I tested the injection feature by sending a packet to a device I own, but did not have 2 CC2531 to send and sniff at the same time. My firmware relies on Contiki's CC253x radio driver, but after a quick code review it looks like this driver may fail at sending a packet. And of course my code does not handle this case. This could explain why you manage to send 64 packets out of 100.

I still need to confirm this guess with some realworld testing, but it looks to me that's the only possible explanation for this packet loss.

wang70880 commented 3 years ago

Could you please point out the suspicious part in the CC253x radio driver? I can help you to confirm the guess.

virtualabs commented 3 years ago

In my code, the send radio_send_packet function does not check the returned value, i.e. does not make sure that the packet has correctly been sent.

Contiki's CC253x driver implements a transmit function that is called by my firmware when sending packet, and this function may return an error code if some conditions are met (see https://github.com/contiki-os/contiki/blob/32b5b17f674232867c22916bb2e2534c8e9a92ff/cpu/cc253x/dev/cc2530-rf.c#L435).

It would be interesting to see if the returned value from contiki NETSTACK_RADIO equals RADIO_TX_COLLISION, and if this is the case that would explain for sure what's happening.

wang70880 commented 3 years ago

In my code, the send radio_send_packet function does not check the returned value, i.e. does not make sure that the packet has correctly been sent.

Contiki's CC253x driver implements a transmit function that is called by my firmware when sending packet, and this function may return an error code if some conditions are met (see https://github.com/contiki-os/contiki/blob/32b5b17f674232867c22916bb2e2534c8e9a92ff/cpu/cc253x/dev/cc2530-rf.c#L435).

It would be interesting to see if the returned value from contiki NETSTACK_RADIO equals RADIO_TX_COLLISION, and if this is the case that would explain for sure what's happening.

Great. After handling this return value, i.e., while(NETSTACK_RADIO.send(p_packet_buffer, packet_length) != RADIO_TX_OK); the miss rate has been reduced to 1% and there is 2% of error rate (BAD FCS).