Get "usb.USBError: Connection timed out" when executing zbdump

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install prerequisites, install from KB source, plug in RZUSBSTICK
2. Run "sudo zbid", returns "007:002 RZUSBSTICK 00DEADBEEF00"
3.Run "sudo zbdump -c 25 -w test.pcap", returns a USB timeout

What is the expected output? What do you see instead?
Not sure what to expect, it's never ran successfully, but here is what I get:

---
Traceback (most recent call last):
  File "/usr/local/bin/zbdump", line 5, in <module>
    pkg_resources.run_script('killerbee==2.5.0', 'zbdump')
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 528, in run_script
    self.require(requires)[0].run_script(script_name, ns)
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1401, in run_script
    exec(script_code, namespace, namespace)
  File "/usr/local/lib/python2.7/dist-packages/killerbee-2.5.0-py2.7-linux-x86_64.egg/EGG-INFO/scripts/zbdump", line 71, in <module>

  File "build/bdist.linux-x86_64/egg/killerbee/__init__.py", line 249, in set_channel
  File "build/bdist.linux-x86_64/egg/killerbee/dev_rzusbstick.py", line 383, in set_channel
  File "build/bdist.linux-x86_64/egg/killerbee/dev_rzusbstick.py", line 299, in _set_mode
  File "build/bdist.linux-x86_64/egg/killerbee/dev_rzusbstick.py", line 263, in __usb_write
usb.USBError: Connection timed out

---

What version of the product are you using?
[ ] KillerBee 1.0 (from TAR file)
[X] KillerBee beta (from SVN checkout) Revision # ? (used the latest version as 
of 2014-11-09 via svn using the command line listed in the "Source" web page)
[ ] Other:

On what operating system?
Ubuntu 14.04 LTS, 64 bit
With what Python version? (python -V)
2.7.6

Is scapy-com installed?
Yes

Please provide any additional information below.
Tried this on two different systems, the 2nd being a "clean" install on a fresh 
machine.  Have tried using different versions of pyusb, error messages are 
slightly different but the end result is the smae (it's not working).

Original issue reported on code.google.com by jmidkif...@gmail.com on 9 Nov 2014 at 11:26

[GoogleCodeExporter]

Is this running inside a VM? If so, which hypervisor?

Original comment by r...@riverloopsecurity.com on 11 Nov 2014 at 11:57

[GoogleCodeExporter]

Also, it looks like the RZUSB you are using is one which is not flashed with 
the KillerBee firmware. That should still work for zbdump, but I haven't tested 
on that recently and most users have flashed RZUSBs.

Original comment by r...@riverloopsecurity.com on 11 Nov 2014 at 11:59

[GoogleCodeExporter]

Thanks for looking into this!  Both systems are physical machines, the first 
being an laptop while the second is a desktop.  And you're right, I am using 
the standard RZUSB firmware... sniffing traffic is my initial focus area and I 
don't have easy access to a programmer to flash a KillerBee image to it.  As a 
result I'm really hoping the stock firmware will still work for this...

Original comment by jmidkif...@gmail.com on 11 Nov 2014 at 11:52

[GoogleCodeExporter]

I've looked at it but don't have any good news -- I'm unable to reproduce this 
-- I suspect because I don't have any stock (unflashed) sticks. It looks from 
your crash like the issue is changing the channel. If you email my company, 
team@riverloopsecurity.com, we may be able to help flash the sticks for you. I 
can't promise that will fix it, however.
The other thing you could do is comment out the contents of set_channel so it 
just does nothing, and then reinstall. However, it will then be on whatever 
channel it defaults to (likely 11 I'd guess), and won't get your traffic on 25. 
However, if you can get traffic on whatever it sniff's on (transmit using 
another stick or move your devices to that channel), then you could test it's 
an issue with set_channel and not sniffing.

Original comment by r...@riverloopsecurity.com on 16 Nov 2014 at 6:52

[GoogleCodeExporter]

Ah, gotcha. I'll try commenting out the set channel call & see what that
does.  I had tried something similar with the code that catches the timeout
after looking at some of the earlier commits that seemed related. I'll also
follow up with you via email as well.  Thanks again for the assist!
 On Nov 16, 2014 10:52 AM, <killerbee@googlecode.com> wrote:

Original comment by jmidkif...@gmail.com on 16 Nov 2014 at 7:41

[GoogleCodeExporter]

I also had this problem initially - exact same errors but zbid working (with a 
flashed stick though).

I eventually found that there had been a version control slip up somewhere in 
my installation process.  Starting again from a clean system and ensuring I 
used svn to obtain the r95 download for everything including the firmware and I 
have now got a working system... or rather working to an extent!

The USB timeout errors have been resolved at least but a problem remains which 
makes me think it may be related to the set channel aspects discussed above:
 - if I run zbid no issues, all returns as expected.
 - if I run any other tool (eg zbstumbler / zbfind) the scripts start as expected, have no errors, but do not report traffic (zbfind has issues quitting)
 - if I use python to run the zbtestpkts script (-r -c 12 --my network is on channel 12) I receive traffic
 - if I run zbfind immediately after stopping the zbtestpkts tool, the zbfind window shows the last packet from the buffer still but not not capture anything further...

I hope this is relevant and helps you to identify your problem a little more.

Original comment by tdperr...@gmail.com on 21 Nov 2014 at 5:27

[GoogleCodeExporter]

@tdperrin2 - I'd suggest trying to use zbdump to debug this issue -- see if you 
get packets via that. zbstumbler and zbfind both switch quickly between TX and 
RX, zbdump doesn't -- it's similar to zbtestpkts in -r mode.

If you have trouble with that, try using the -i argument to zbdump (and most 
scripts) to tell it the address of the USB stick (that you get from zbid). This 
shouldn't be needed most of the time, however.

Original comment by rmspe...@gmail.com on 26 Dec 2014 at 2:58