Closed GoogleCodeExporter closed 9 years ago
Initiated branch and made patches for backwards compatibility but now works
with enumeration. But, after the first read or write over pyUSB1, all future
read/writes appear to fail. Branch is in SVN at http://bit.ly/VKl7Wj.
Original comment by rmspe...@gmail.com
on 16 Jan 2013 at 4:54
Original comment by rmspe...@gmail.com
on 16 Jan 2013 at 4:54
Checked out r52. zbdump and zbreplay seem to work with little issue. I did
receive a timeout error after a replay, ctrl-c before completion, and the next
replay:
Traceback (most recent call last):
File "/usr/local/bin/zbreplay", line 99, in <module>
kb.set_channel(arg_channel)
File "/usr/local/lib/python2.7/dist-packages/killerbee/__init__.py", line 245, in set_channel
self.driver.set_channel(channel)
File "/usr/local/lib/python2.7/dist-packages/killerbee/dev_rzusbstick.py", line 359, in set_channel
self._set_mode(RZ_CMD_MODE_AC)
File "/usr/local/lib/python2.7/dist-packages/killerbee/dev_rzusbstick.py", line 275, in _set_mode
self.__usb_write(RZ_USB_COMMAND_EP, [RZ_CMD_SET_MODE, mode])
File "/usr/local/lib/python2.7/dist-packages/killerbee/dev_rzusbstick.py", line 259, in __usb_write
response = self.dev.read(RZ_USB_RESPONSE_EP, self.dev.bMaxPacketSize0).pop() #1, 0, 500)
File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 654, in read
self.__get_timeout(timeout)
File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb10.py", line 541, in bulk_read
timeout)
File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb10.py", line 641, in __read
timeout))
File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb10.py", line 403, in _check
raise USBError(_str_error[ret], ret, _libusb_errno[ret])
usb.core.USBError: [Errno 110] Operation timed out
Only thing I notice is the new device ID does not contain leading zeros, but
seems compatible across all tools so not an issue.
Original comment by larry.pe...@gmail.com
on 7 Feb 2013 at 2:25
r53 should be the right one -- r52 still had a bug.
https://killerbee.googlecode.com/svn/branches/pyUSB1/killerbee
Original comment by rmspe...@gmail.com
on 7 Feb 2013 at 2:46
My bad. That report does come from r53. It was checked out and installed 13
minutes after r53 was checked in. :-)
Original comment by larry.pe...@gmail.com
on 7 Feb 2013 at 2:50
FWIW, I'm using pyUSB 1.0.
Original comment by larry.pe...@gmail.com
on 7 Feb 2013 at 2:51
Does your environment match the one below?
$ python
Python 2.7.3 (default, Aug 1 2012, 05:14:39)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import usb.core
>>> print(usb.core)
<module 'usb.core' from '/usr/local/lib/python2.7/dist-packages/usb/core.pyc'>
>>>
$ sudo zbreplay -r sample/control4-sample.pcap -f 11 -i 3:14
Warning: You are using pyUSB 1.x, support is in alpha.
Warning: You are using pyUSB 1.x, support is in alpha.
zbreplay: retransmitting frames from 'sample/control4-sample.pcap' on interface
'3:14' with a delay of 1.000000 seconds.
^C12 packets transmitted
$ lsusb -s 3:14 -v
Bus 003 Device 014: ID 03eb:210a Atmel Corp.
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x03eb Atmel Corp.
idProduct 0x210a
bcdDevice 2.00
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
...
Also, I tried the replay, cancel, and then replay again -- it seems to work:
$ sudo zbreplay -r sample/control4-sample.pcap -f 11 -i 3:14
Warning: You are using pyUSB 1.x, support is in alpha.
Warning: You are using pyUSB 1.x, support is in alpha.
zbreplay: retransmitting frames from 'sample/control4-sample.pcap' on interface
'3:14' with a delay of 1.000000 seconds.
^C13 packets transmitted
$ sudo zbreplay -r sample/control4-sample.pcap -f 11 -i 3:14
Warning: You are using pyUSB 1.x, support is in alpha.
Warning: You are using pyUSB 1.x, support is in alpha.
zbreplay: retransmitting frames from 'sample/control4-sample.pcap' on interface
'3:14' with a delay of 1.000000 seconds.
^C7 packets transmitted
I've committed a r54 that adds debugging code where you saw the error.
Original comment by rmspe...@gmail.com
on 7 Feb 2013 at 3:03
Updated output from r54:
lpesce@Gekko:~/killerbee-read-only$ sudo zbreplay -f 11 -R 11.dt -i 2:5
Warning: You are using pyUSB 1.x, support is in alpha.
Warning: You are using pyUSB 1.x, support is in alpha.
DEBUG: Received operation timed out error, and response is:
Traceback (most recent call last):
File "/usr/local/bin/zbreplay", line 99, in <module>
kb.set_channel(arg_channel)
File "/usr/local/lib/python2.7/dist-packages/killerbee/__init__.py", line 245, in set_channel
self.driver.set_channel(channel)
File "/usr/local/lib/python2.7/dist-packages/killerbee/dev_rzusbstick.py", line 368, in set_channel
self._set_mode(RZ_CMD_MODE_AC)
File "/usr/local/lib/python2.7/dist-packages/killerbee/dev_rzusbstick.py", line 284, in _set_mode
self.__usb_write(RZ_USB_COMMAND_EP, [RZ_CMD_SET_MODE, mode])
File "/usr/local/lib/python2.7/dist-packages/killerbee/dev_rzusbstick.py", line 267, in __usb_write
print "DEBUG: Received operation timed out error, and response is:", response
UnboundLocalError: local variable 'response' referenced before assignment
Original comment by larry.pe...@gmail.com
on 8 Feb 2013 at 2:33
r55 committed to try some other things. I'm not able to reproduce the bugs on
my Ubuntu machine running the 3.2.0-36-generic kernel. If you're having issues
still, let me know or try playing with the parameters (timeout, length of the
sleep statement, what to do if errno==110 occurs, etc) near line 267 of
killerbee/dev_rzusbstick.py. You may have better luck manipulating it to avoid
your issue, but let me know and I'll keep trying things.
Original comment by rmspe...@gmail.com
on 12 Feb 2013 at 2:25
This is being closed as the new version supporting pyUSB1.0 as well as the
older 0.x has been out for a while now and is now in the trunk SVN. People
report good success. Please post if you have issues.
Original comment by rmspe...@gmail.com
on 22 Nov 2013 at 12:18
Original issue reported on code.google.com by
larry.pe...@gmail.com
on 19 Dec 2012 at 1:29