Add support for CC2530/1 USB dongles for sniffing. #94
Conversation
This adds support for packet sniffing for USB dongles based on the TI CC2530 and CC2531 chips. Note that the FCS received from these dongles is in TI CC24XX format, so for wireshark to display the FCS information correctly, the "TI CC24XX FCS format" in Preferences->Protocols->IEEE802.15.4 must be selected.
|
Hi. I know there are other packet sniffers for these dongles, but I am getting used to using zbwireshark and zbdump for packet sniffing. This commit adds support for these two dongles (at least, the Chinese clone examples that I have) for packet sniffing only. Not sure whether you're interested in this, but I thought I'd submit this pull request in case. |
|
You beat me to this -- I was about to commit a similar one when I had a chance to test. I will take a look at this one now. |
killerbee/dev_cc253x.py
Outdated
|
|
||
|
|
||
| def close(self): | ||
| pass |
There was a problem hiding this comment.
In my version I was checking to see if the device was in capture mode, and if so halting that.
killerbee/dev_cc253x.py
Outdated
| @rtype: List | ||
| @return: List of 3 strings identifying device. | ||
| ''' | ||
| return [self.name, "CC253x", ""] |
There was a problem hiding this comment.
Can we get a serial number off the device?
There was a problem hiding this comment.
Both of the devices that I own have iSerial = 0. I'm not sure if that's typical. I could add a check and use it if it isn't 0 (but have no way of testing it)...?
There was a problem hiding this comment.
Ok, I didn't have a chance to check mine when reviewing this.
What about a version number of the firmware, does it give us that?
If not, let's leave it out for now and just put a TODO in the code to figure out how to get a unique ID, if possible.
There was a problem hiding this comment.
I can't see anything else in the USB descriptor that would uniquely identify the device. Also, the Windows based TI Packet Sniffer tool doesn't report a unique device ID for either of my two dongles, which would suggest there isn't a "get device ID" USB transaction (or, that the Windows tool isn't using it - which will make it difficult to discover through reverse engineering). I've added a TODO.
killerbee/dev_cc253x.py
Outdated
| close(). | ||
| @rtype: None | ||
| ''' | ||
| self.dev.ctrl_transfer(CC253x.USB_DIR_OUT, CC253x.USB_XFER_STOP) |
There was a problem hiding this comment.
Most of the time we check to see if __stream_open is true first, as other devices have had edge cases there. If this one is safe, that's OK not to check it.
Can we check the result of ctrl_transfer before setting __stream_open to false?
There was a problem hiding this comment.
The check for __stream_open == True should be added, yes.
Regarding checking the results of ctrl_transfer, I'm not sure what the recovery for a failure would be, either for the driver, or for the application (we don't return a success/failure value from that function)...?
There was a problem hiding this comment.
Yes, I see your point -- we'd have to throw an exception which probably isn't great either. Maybe just put a TODO in the comments and I'll look at how to rework error handling at a later time?
There was a problem hiding this comment.
OK, I've added a TODO.
killerbee/dev_cc253x.py
Outdated
| if channel >= 11 or channel <= 26: | ||
| self._channel = channel | ||
| else: | ||
| raise Exception('Invalid channel') |
There was a problem hiding this comment.
In other implementations I think we change the channel here -- so that this can happen mid capture, etc -- without the developer using KillerBee to need to know that you need to stop, change the channel, and restart. Could we do the same here?
There was a problem hiding this comment.
Yes, but this needs to be dependent on whether the capture is running. On my CC2530 dongle, the channel setting fails if the radio isn't powered up. I'll add that.
killerbee/dev_cc253x.py
Outdated
| self._data_ep = CC253x.USB_CC2531_DATA_EP | ||
| self._channel = None | ||
| self.dev = dev | ||
| self.name = "<unknown>" |
There was a problem hiding this comment.
Seems like we probably don't need this as it is set on L 61?
|
Thanks for your comments. I've got a commit ready to push, subject to your feedback on a couple of the comments (the serial number, and checking the return from ctrl_transfer in sniffer_off). |
Updated after code review: - Removed redundant code. - Check state of capture in close() and sniffer_off(). - Perform channel change during capture.
|
I've pushed another commit, which I believe addresses all of your review comments. |
|
Thanks. |
This adds support for packet sniffing for USB dongles based
on the TI CC2530 and CC2531 chips.
Note that the FCS received from these dongles is in TI CC24XX
format, so for wireshark to display the FCS information correctly,
the "TI CC24XX FCS format" in Preferences->Protocols->IEEE802.15.4
must be selected.