Packet sniffing with the CC2530 USB Stick

So yesterday I blogged about discovering that what I thought was a CC2531 USB dongle was actually a CC2530 dongle. And today I managed to get packet sniffing working under Linux!

Start Point

I used this CC2531 packet sniffing utility as a starting point:

• https://github.com/christianpanton/ccsniffer

I have chosen this as it is a very straight-forward python script, so adapting it for use with the CC2530 should be relatively simple, depending on what differences I find from the CC2531.

However, I can't use it as-is, because the idVendor and idProduct identifiers for the CC2530 and CC2531 are different, and (as I quickly found), there have been some changes to PyUSB 1.0 (the python USB support library) between when 'ccsniffer' was originally written (looks like it was written using one of the 1.0.0 alpha versions), and the official 1.0.0 release.  So I forked the github project, and created a branch so that I could work on it:

• https://github.com/Scytmo/ccsniffer/tree/support-cc2530

So I made the modifications for PyUSB and updated the idVendor and idProduct for my CC2530 USB Stick, and ran ccsniffer.

End Point

Running the modified ccsniffer now gives me the following error when the PyUSB 'read()' function is called to read packet data.

ValueError: Invalid endpoint address 0x83

I see that ccsniffer has defined the data endpoint as 0x83, and it seems my CC2530 dongle doesn't have a USB endpoint with that identifier.  I can find out the endpoints supported on my CC2530 dongle with 'lsusb' on Linux:

$ lsusb
Bus 001 Device 002: ID 0e0f:000b VMware, Inc. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 006: ID 11a0:eb20 Chipcon AS 
Bus 002 Device 004: ID 0e0f:0008 VMware, Inc. 
Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

So the CC2530 is on bus 2, device 6 (my Linux system is a virtual machine running under VMware, hence the VMware devices), so lsusb can show me more details of that device:

$ lsusb -v -s 2:6
Bus 002 Device 006: ID 11a0:eb20 Chipcon AS 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x11a0 Chipcon AS
  idProduct          0xeb20 
  bcdDevice            0.50
  iManufacturer           1 Chipcon AS
  iProduct                2 SmartRF04EB
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x40
      (Missing must-be-set bit!)
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               5
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               5
Device Status:     0x0000
  (Bus Powered)

This shows that the CC2530 USB Stick is made by Chipcon (a company that was acquired by TI, so that makes sense) and it only has a single input endpoint, with identifier 0x82, supporting bulk data transfer.  So this seems like a good candidate (the only candidate!) for the data endpoint used for  packet sniffing.

Result

Modifying the data endpoint in ccsniffer from 0x83 (for the CC2531) to 0x82 (for the CC2530) was the last change necessary - it seems that the CC2530 and CC2531 firmware is sufficiently similar for the remainder of the USB control commands to work, and ccsniffer (in my github branch above) now works for my CC2530 dongle.