Open GoogleCodeExporter opened 9 years ago
Is this running inside a VM? If so, which hypervisor?
Original comment by r...@riverloopsecurity.com
on 11 Nov 2014 at 11:57
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
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
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
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
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
@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
Original issue reported on code.google.com by
jmidkif...@gmail.com
on 9 Nov 2014 at 11:26