monk-dot / killerbee

Automatically exported from code.google.com/p/killerbee
0 stars 1 forks source link

From zbdump: UnboundLocalError: local variable 'response' referenced before assignment #1

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Just checked out the code from svn today (12 Feb 2011). I'm getting the 
following error message on a Ubuntu 10.4 All the dependencies are up-to-date as 
of 12 Feb 2011.  I also have a simple fix below.

$ zbdump  -f 20 -w out.dump

Traceback (most recent call last):
  File "/usr/local/bin/zbdump", line 87, in <module>
    kb.set_channel(arg_channel)
  File "/usr/local/lib/python2.6/dist-packages/killerbee/__init__.py", line 345, in set_channel
    self._set_mode(RZ_CMD_MODE_AC)
  File "/usr/local/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/local/lib/python2.6/dist-packages/killerbee/__init__.py", line 224, in __usb_write
    if response != RZ_RESP_SUCCESS:
UnboundLocalError: local variable 'response' referenced before assignment

Cause: it seems that 'response' is not defined when it is used at line 224 of 
file killerbee/__init__.py. This is because of the bogus 'No error' exception ( 
http://bugs.debian.org/476796 )

Solution: if a 'No error' exception is thrown, assume response is 
RZ_RESP_SUCCESS. Add the following two lines in killerbee/__init__.py at line 
222:

else:
  response = RZ_RESP_SUCCESS # assume success on 'No error' exception

Original issue reported on code.google.com by jdesbon...@gmail.com on 12 Feb 2011 at 3:53

GoogleCodeExporter commented 9 years ago
Do you still have this issue still exist in the new trunk code or in the 
/tags/killerbee-1.0 release?

Original comment by rmspe...@gmail.com on 12 Mar 2011 at 5:54

GoogleCodeExporter commented 9 years ago
The above problem still exists with the code. I've tried the fix and it gives 
the same error.  Has there been any other work arounds?

Thanks,

Original comment by warez...@gmail.com on 17 May 2011 at 2:12

GoogleCodeExporter commented 9 years ago
It looks like an issue with timing on the USB bus, or similar. From our email 
conversation, this seems to be happening with default RZUSBSTICK firmware, 
right? Let me know if you have these issues with the flashed RZUSBSTICKS, or if 
the suggested workaround of adding a simple time delay before this line, or 
catching the exception and retrying for a few times, helps.

Original comment by rmspe...@gmail.com on 8 Jun 2011 at 2:30

GoogleCodeExporter commented 9 years ago
Closing as no further activity seen on this issue. Please reopen if needed. 
Also please consider trying/testing the new pyUSB1 branch that offers support 
for the new pyUSB.

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