usb bulkread failing

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Installed latest killerbee version on ubuntu 11.10 virtual machine on Mac OS 
X

2. Ran with default atmel firmware, and with killerbee firmware

user@machine:~/killerbee-1.0$ sudo zbdump -f 20 -w test
Traceback (most recent call last):
  File "/usr/local/bin/zbdump", line 87, in <module>
    kb.set_channel(arg_channel)
  File "/usr/local/lib/python2.7/dist-packages/killerbee/__init__.py", line 348, in set_channel
    self._set_mode(RZ_CMD_MODE_AC)
  File "/usr/local/lib/python2.7/dist-packages/killerbee/__init__.py", line 264, in _set_mode
    self.__usb_write(RZ_USB_COMMAND_EP, [RZ_CMD_SET_MODE, RZ_CMD_MODE_AC])
  File "/usr/local/lib/python2.7/dist-packages/killerbee/__init__.py", line 222, in __usb_write
    response = self.handle.bulkRead(RZ_USB_RESPONSE_EP, 1)[0]
IndexError: tuple index out of range

It seems the bulkRead is returning an empty tuple.
Also, unrelated but is the killerbee LED supposed to be blue like the default 
firmware?

Original issue reported on code.google.com by nick.g...@gmail.com on 22 Dec 2011 at 6:28

[GoogleCodeExporter]

Nick, is this on the RZUSBSTICK device? Is this also an issue under native 
Ubuntu 11.10, or are you able to check that? Are you using the KillerBee 
checkout from SVN?

Original comment by rmspe...@gmail.com on 20 Feb 2012 at 11:41

[GoogleCodeExporter]

I know this is an old posting but I am having the same issues and I did not see 
a resolution. I too installed the new firmware on a RZUSBSTICK and when I run 
zbstumbler I get the error"tuple index out of range". I am working under 
backtrack 5.0. Also, like Nick, I am curious to know if the LED is suppose to 
be blue or amber/yellow? I've written the firmware to 4 sticks and none of them 
light up the blue led. According to the ATMEL docs amber/yellow indicates 
buffer overflow in either the zigbee coordinator more or Aircapture mode. Also, 
is stick suppose to show up as an available network device for use with 
wireshark? If so, its not showing up as such. It does show up as usb0 if I 
write the 6lowpan firmware to it though; so I know the stick is working and the 
header is soldered on correctly.

Listing the available devices with zbid works just fine - 
Dev Product String  Serial Number
002:007 KILLERB001  0004251CA000

When I execute zbstumbler I get this - 

zbstumbler: Transmitting and receiving on interface '002:007'
ERROR: Failed to set channel to 11
tuple index out of range

When I try a different channel I get this - 
zbstumbler: Transmitting and receiving on interface '002:007'
Traceback (most recent call last):
  File "/usr/local/bin/zbstumbler", line 163, in <module>
    kb.set_channel(channel)
  File "/usr/lib/python2.6/dist-packages/killerbee/__init__.py", line 345, in set_channel
    self._set_mode(RZ_CMD_MODE_AC)
  File "/usr/lib/python2.6/dist-packages/killerbee/__init__.py", line 261, in _set_mode
    self.__usb_write(RZ_USB_COMMAND_EP, [RZ_CMD_SET_MODE, RZ_CMD_MODE_AC])
  File "/usr/lib/python2.6/dist-packages/killerbee/__init__.py", line 219, in __usb_write
    response = self.handle.bulkRead(RZ_USB_RESPONSE_EP, 1)[0]
IndexError: tuple index out of range

Any assistance would greatly be appreciated.

Original comment by komp...@gmail.com on 16 Mar 2012 at 9:55

[GoogleCodeExporter]

Hi. I will test this out as close as I can to your environment. However, are 
you using KillerBee 1.0 or the latest version from SVN trunk? Please use the 
SVN version and reinstall KillerBee if you are not using that already. I'll get 
a Backtrack 5 loaded in the meantime.

Original comment by rmspe...@gmail.com on 17 Mar 2012 at 3:04

[GoogleCodeExporter]

Issue 11 has been merged into this issue.

Original comment by rmspe...@gmail.com on 17 Mar 2012 at 3:21

[GoogleCodeExporter]

Initially I was using the firmware from the tar file, running Backtrack 5 
(32bit) VMware on a MacBook Pro with killer bee installed via apt-get. The 
results were as I posted. 

I have dl'd the firmware version from the trunk and I just wrote it to the 
RZUSBSTICK via a JTAGICE3 programmer again just in case I screwed something up 
last night. I figured that a virtual machine may not be playing nice with your 
firmware so this time I am working on a physical system running Backtrack 5 R2 
(64bit).

Running zbid from the trunk version I get the following - 
root@bt:~/killbeeSRC_fromSVN/killerbee/tools# ./zbid
Traceback (most recent call last):
  File "./zbid", line 12, in <module>
    show_dev()
  File "./zbid", line 5, in show_dev
    kbdev_info = kbutils.devlist()
AttributeError: 'module' object has no attribute 'devlist'

I don't get favorable results from the zbstumbler from the trunk version either 
-

root@bt:~/killbeeSRC_fromSVN/killerbee/tools# ./zbstumble
zbstumbler: Transmitting and receiving on interface '003:004'
Traceback (most recent call last):
  File "./zbstumbler", line 204, in <module>
    recvpkt = kb.pnext()
  File "/usr/lib/python2.6/dist-packages/killerbee/__init__.py", line 398, in pnext
    self.sniffer_on()
  File "/usr/lib/python2.6/dist-packages/killerbee/__init__.py", line 296, in sniffer_on
    self._open_stream()
  File "/usr/lib/python2.6/dist-packages/killerbee/__init__.py", line 268, in _open_stream
    self.__usb_write(RZ_USB_COMMAND_EP, [RZ_CMD_OPEN_STREAM])
  File "/usr/lib/python2.6/dist-packages/killerbee/__init__.py", line 225, in __usb_write
    raise Exception("Error: %s" % RESPONSE_MAP[response])
Exception: Error: Semantical Error

Now if I run the versions installed via apt-get I get the following -

root@bt:~# zbid
Dev     Product String  Serial Number
003:004 KILLERB001      0004251CA000

When I run zbstumbler from the trunk version or from the version installed 
under pentest in back track I get the same results ...

root@bt:~# zbstumbler 
zbstumbler: Transmitting and receiving on interface '003:004'
Traceback (most recent call last):
  File "/usr/bin/zbstumbler", line 203, in <module>
    recvpkt = kb.pnext()
  File "/usr/lib/python2.6/dist-packages/killerbee/__init__.py", line 398, in pnext
    self.sniffer_on()
  File "/usr/lib/python2.6/dist-packages/killerbee/__init__.py", line 296, in sniffer_on
    self._open_stream()
  File "/usr/lib/python2.6/dist-packages/killerbee/__init__.py", line 268, in _open_stream
    self.__usb_write(RZ_USB_COMMAND_EP, [RZ_CMD_OPEN_STREAM])
  File "/usr/lib/python2.6/dist-packages/killerbee/__init__.py", line 225, in __usb_write
    raise Exception("Error: %s" % RESPONSE_MAP[response])
Exception: Error: Semantical Error

What version of linux did you dev/test killerbee on? 

Original comment by komp...@gmail.com on 18 Mar 2012 at 1:12

[GoogleCodeExporter]

Hi,

We develop and test on Ubuntu variants of Linux. So, Backtrack should work fine.

The first issue you had off of trunk:
"root@bt:~/killbeeSRC_fromSVN/killerbee/tools# ./zbid
Traceback (most recent call last):
 File "./zbid", line 12, in <module>
   show_dev()
 File "./zbid", line 5, in show_dev
   kbdev_info = kbutils.devlist()
AttributeError: 'module' object has no attribute 'devlist'"

That looks at first glance like it may not have had the trunk version installed 
with sudo python setup.py install. 

However, I'll aim tonight or tomorrow to do a full install on Backtrack 5 R2 64 
bit and test all of this for you and see if I run into any issues.

Sorry that it isn't going smoothly!

Original comment by rmspe...@gmail.com on 18 Mar 2012 at 4:56

[GoogleCodeExporter]

No worries if it isn't hard to figure out it ain't worth spending time one it 
.....I appreciate you taking the to assist.

Do you have the firmware source posted somewher? Is the amber led suppose to 
light up or the blue? 

Original comment by komp...@gmail.com on 19 Mar 2012 at 1:54

[GoogleCodeExporter]

The light color question is the easy one, so let me answer that first. My 
devices light up amber when operating properly.

I have also confirmed this in the source. Josh's modifications to the source 
code aren't posted online, but I have looked through the modifications. I see 
that indeed, the code is changed in that regard...

diff AVR2017_RZRAVEN_Firmware/application/rzusbstick/rzusbstick.c 
AVR2017_KB_RZRAVEN_Firmware/application/rzusbstick/rzusbstick.c
129c129
<     LED_BLUE_ON();
---
>     LED_ORANGE_ON();

Original comment by rmspe...@gmail.com on 19 Mar 2012 at 3:01

[GoogleCodeExporter]

I have tested under BackTrack. The issue is, as I suspected, that the old 
KillerBee code (release 1.0) was running. Despite you updating properly from 
SVN, when the zbid script got run (which was installed by setup.py from the SVN 
head so that the new version of zbid ran), it still ran the KillerBee 1.0 
libraries. This is because of a Python path (in the order it looks for 
libraries) as well as the fact that the BackTrack 5.2 shipped with KillerBee 
1.0 installed to the system-wide python directories.

You can fix this issue by doing:
# rm -r /usr/lib/python2.6/dist-packages/killerbee
and then, in the up-to-date SVN checkout, run your setup.py install:
> sudo python setup.py install

Please confirm that this fixes it for you as well.

Original comment by rmspe...@gmail.com on 25 Mar 2012 at 3:48

• Changed state: Accepted

[GoogleCodeExporter]

Greetings,

Thank you for following up and apologies for the delay. I had deleted the "old" 
Zigbee prior to installing the version form SVN. But for some reason it still 
was giving me issues. I did figure out that there were several libraries that 
were not installed in the backtrack distro. I wanted to get this working ASAP 
so I switched to Ubuntu 11.10 and after executing the following commands I did 
get the tools to work more or less - 

apt-get update
apt-get upgrade

apt-get install python-cairo
apt-get install python-crypto
apt-get install python-gtk2
apt-get install python-usb
apt-get install libgcrypt11
apt-get install libgcrypt11-dev

cd to the directory trunk/killerbee
sudo python setup.py build
sudo python setup.py install

I say more or less because some work great while others are a bit finicky; for 
example -

- zbid; works with no issues

- zbfind; works sometimes. When it does it does detect the Zigbee network 
however it won't close properly; GUI stays open and won't close even if I kill 
the process. 

-zbwireshark; when executed the named pipe is created, I can point Wireshark to 
it how ever I do get a URB error stating that it can't allocate memory.

- zbstumbler; seems to work. When stops it indicates that it send X # of 
packets and received Y # of packets. Does not display the information as you 
have it illustrated in your KillerBee presentation

- zbdump; works very well.

I am still working on the rest of the tools. I will let you know if I run into 
any problems.

Thanks again for following up with me.

Original comment by komp...@gmail.com on 1 Apr 2012 at 10:16

[GoogleCodeExporter]

Hi,

Thanks for the update. I've gotten it to work on my Backtrack 5R2 VM, using the 
procedures I documented on this thread. I'm interested in what the issues are 
there, or if you figure them out -- perhaps we did something slightly different 
or I need to make an "upgrade" script or something for BT users.

On the finiky ones:
- zbfind: yes, that is one I haven't touched since Josh wrote it. I actually 
had it on my radar to tackle soon.
- zbstumbler: do you have a ZigBee device within radio range that is turned on 
and is responding to beacon requests? For debugging, try sniffing using a 
second interface RZUSBSTICK running zbdump on the channel the ZigBee device is 
on while you let zbstumbler run for a bit. Feel free to upload logs and PCAP. 
There are some edge-case issues when testing devices with very fast or hardware 
accelerated beacon responses and it seems to happen more if you're zbstumbler 
computer is too close to the device under test. Odd. From the PCAP I should be 
able to tell.
- zbwireshark: will add to test under Ubuntu 11.10. I'm assuming you ran it as 
sudo? Did the error produce a line number?

Original comment by rmspe...@gmail.com on 2 Apr 2012 at 10:44

[GoogleCodeExporter]

Greetings,

I'm just using root for now under BT5R2 VM; so zbwireshark is running with the 
correct privileges. As soon as traffic stops wireshark stops capturing with the 
error - "As no data was captured, closing the temporary capture file!" - now I 
know that traffic is being transmitted because I can see it with my Zen sniffer.

By the way I am using 2 Digi Xbee Pro S1 Modules to gen the traffic. 

Here's a scenario -

Executing this works just fine - 
root@bt:~# zbwireshark -f 12 -i 002:002
Point Wireshark to read from the pipe file: /tmp/tmpGGaV5E/zbwireshark

But when I execute this -> wireshark -k -i /tmp/tmpGGaV5E/zbwireshark; I get 
the error from wireshark that I mentioned above and zbwireshark crashes with 
this error -

Traceback (most recent call last):
  File "/usr/local/bin/zbwireshark", line 85, in <module>
    kb.set_channel(arg_channel)
  File "/usr/local/lib/python2.6/dist-packages/killerbee/__init__.py", line 231, in set_channel
    self.driver.set_channel(channel)
  File "/usr/local/lib/python2.6/dist-packages/killerbee/dev_rzusbstick.py", line 329, in set_channel
    self._set_mode(RZ_CMD_MODE_AC)
  File "/usr/local/lib/python2.6/dist-packages/killerbee/dev_rzusbstick.py", line 245, in _set_mode
    self.__usb_write(RZ_USB_COMMAND_EP, [RZ_CMD_SET_MODE, RZ_CMD_MODE_AC])
  File "/usr/local/lib/python2.6/dist-packages/killerbee/dev_rzusbstick.py", line 203, in __usb_write
    response = self.handle.bulkRead(RZ_USB_RESPONSE_EP, 1)[0]
IndexError: tuple index out of range 

Mind you I did not install killerbee via apt-get. Rather I dl'd it from svn; 
revision 30 is what I used. I first ran python setup.py build then I ran python 
setup.py install; both commands completed with no errors after I 
updated/upgraded BT (i.e. apt-get update and apt-get upgrade).

These issues are on a BT5r2 VM, but the tools do work on my Ubuntu 11.10 box. 
For obvious reasons I want to get this working on BT5R2. 

As for zbstumbler - if I execute it with no parameters I get this -

root@bt:~# zbstumbler
zbstumbler: Transmitting and receiving on interface '002:002'
ERROR: Failed to set channel to 11
tuple index out of range

If I execute it with parameters I get this -

root@bt:~# zbstumbler -i 002:002 -c 12
zbstumbler: Transmitting and receiving on interface '002:002'
Traceback (most recent call last):
  File "/usr/local/bin/zbstumbler", line 163, in <module>
    kb.set_channel(channel)
  File "/usr/local/lib/python2.6/dist-packages/killerbee/__init__.py", line 231, in set_channel
    self.driver.set_channel(channel)
  File "/usr/local/lib/python2.6/dist-packages/killerbee/dev_rzusbstick.py", line 329, in set_channel
    self._set_mode(RZ_CMD_MODE_AC)
  File "/usr/local/lib/python2.6/dist-packages/killerbee/dev_rzusbstick.py", line 245, in _set_mode
    self.__usb_write(RZ_USB_COMMAND_EP, [RZ_CMD_SET_MODE, RZ_CMD_MODE_AC])
  File "/usr/local/lib/python2.6/dist-packages/killerbee/dev_rzusbstick.py", line 203, in __usb_write
    response = self.handle.bulkRead(RZ_USB_RESPONSE_EP, 1)[0]
IndexError: tuple index out of range

Yes the interface is correct becuase zbstumbler -D matches with what lsusb 
provides -

root@bt:~# lsusb
Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 002 Device 002: ID 03eb:210a Atmel Corp. 

root@bt:~# zbstumbler -D
Dev Product String  Serial Number
002:002 KILLERB001  0004251CA001

Also another interesting this is that zbid yields an error such as this - 

root@bt:~# zbid
Traceback (most recent call last):
  File "/usr/local/bin/zbid", line 12, in <module>
    show_dev()
  File "/usr/local/bin/zbid", line 5, in show_dev
    kbdev_info = kbutils.devlist()
  File "/usr/local/lib/python2.6/dist-packages/killerbee/kbutils.py", line 79, in devlist
    dev.open().getString(dev.iProduct, 50),    \
usb.USBError: error sending control message: Connection timed out

If you have any ideas please do share. I will continue to tinker with it 
tomorrow night and will let know of any other results. 

Cheers.

Original comment by komp...@gmail.com on 3 Apr 2012 at 4:56

[GoogleCodeExporter]

Thanks for the update.

All of the tuple index errors are an old bug in the RZUSBSTICK read code. I've 
never totally looked into it, as it was from the original KillerBee code, but 
I'll try to figure out what is going on there. I think it's possibly an issue 
with how KillerBee talks to the firmware in terms of timing/waits.

Original comment by rmspe...@gmail.com on 3 Apr 2012 at 11:03

[GoogleCodeExporter]

That is interesting. But the kicker is that these are errors I'm getting using 
BT5R2 32bit VM on a Mac Pro. I don't get those errors using the same code on 
Ubutnu 11.10 running on a physical system. I'm starting to wonder if the VMWare 
virtual drivers running on a Mac has something to do with it. But then again it 
worked for you on a similar platform correct? 

On a side note have you had issues writing the kb fw with the JTAG programmer 
to one of the sticks? Yet on the same stick I am able to write the default fw, 
6lowpan fw or the 15dot4 fw with no issues. However when I write the kb fw I'm 
getting a red led instead of the amber/yellow. Have you come across this?

Original comment by komp...@gmail.com on 3 Apr 2012 at 1:58

[GoogleCodeExporter]

For the life of me I could not get this to work with BT5R2 under VMWare 4 on my 
Macbook Air. Capturing USB packets with usbmon and Wireshark showed malformed 
packets and responses indicating protocol error and broken pipe messages. 
Switched to Virtualbox at the suggestion of rmspeers and everything has been 
running flawlessly.

Original comment by melgares on 12 Apr 2012 at 3:53

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

melga...@gmail.com -

Interesting. I posted a hypothesis in Comment 14 regarding the VMWare drivers. 
To expand on it; in particular how resources are allocated and 
translation/interpretation of the killerbee firmware. But then again 
rmspe...@gmail.com posted in Comment 10 that he got it to work on a BackTrack 
VM. I got it to work pretty well on Ubuntu 11.10 (see Comment 11) but had not 
success with the 64bit BackTrack 5r2 on VMFusion. I am working on trying it on 
the 32bit version of Backtack. I will post my results.

rmspe...@gmail.com -

Could you share the version of BT 5r2 (64bit vs 32bit) and the VM tech you 
used? Any caveats we should take into consideration?

Thanks.

Original comment by komp...@gmail.com on 12 Apr 2012 at 5:58

[GoogleCodeExporter]

komp...@gmail.com -

It was BT5R2, both 64 and 32 bit, under VirtualBox like melgares
mentioned I suggested to him. Sorry for not making that clear. No issues
under VirtualBox -- and I've had it up for a while doing stuff recently.

Original comment by rmspe...@gmail.com on 12 Apr 2012 at 11:35

[GoogleCodeExporter]

And yes, VMWare in general has a bad history of USB support. I did notice that 
disabling USB 2.0 support seemed to help some (saw less malformed packets and 
what not), but that still didn't fix the issue.

Original comment by melgares on 12 Apr 2012 at 11:44

[GoogleCodeExporter]

Thank you for all the assistance.I have not moved to creating a zigbee network 
simulating the smartgrid profile using arduino and Xbee modules. If anyone 
knows of any good resources please do share and I will do the same as a make 
progress.

Original comment by komp...@gmail.com on 26 Apr 2012 at 2:52

[GoogleCodeExporter]

Closing due to no further posts. Last notes showed users having success in 
VirtualBox even when some edge case issues appeared in VMWare. See above thread.

Original comment by rmspe...@gmail.com on 12 Feb 2013 at 3:09

• Changed state: Done