Closed SpencerMichaels closed 3 years ago
The jammer_on() and off() functions were part of the sample firmware from Atmel, and when I tested them I saw similar results to what you report. I never investigated it further. If you have an AVR Dragon or mkII ICE JTAG debugger, it might be interesting to see what happens in the firmware, and if it can be corrected to update the firmware with jammer functionality.
-Josh
I do have an AVR Dragon, but I doubt I have the skill to investigate this in too much depth... I did, however, find that in the data sheet, there's a section (Appendix, A.3) that says
The functionality of the Continuous Transmit Mode is not characterized by Atmel and therefore not guaranteed.
I take this to mean "continuous transmit mode just might not work"..?
Meanwhile, I suppose there is not any other way to get an RZRaven to transmit and ignore CSMA/CA?
We generally use other firmware/hardware for jamming, so I’ve never looked at changing it in the Atmel. Other chips like the CC2420 have a flag to disable CSMA/CA, as well as to place it into “test mode” which generally allows jamming transmissions.
On Jun 24, 2016, at 4:47 PM, Spencer Michaels notifications@github.com wrote:
I do have an AVR Dragon, but I doubt I have the skill to investigate this in too much depth... I did, however, find that in the data sheet, there's a section that says
The functionality of the Continuous Transmit Mode is not characterized by Atmel and therefore not guaranteed. I take this to mean "continuous transmit mode just might not work"..?
Meanwhile, I suppose there is not any other way to get an RZRaven to transmit and ignore CSMA/CA?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/riverloopsec/killerbee/issues/69#issuecomment-228457924, or mute the thread https://github.com/notifications/unsubscribe/AJbQCWTjS26OJN9mC1OICaguqcn3mZANks5qPEJdgaJpZM4I-Dtl.
Any pointers in how to implement jammer on rzusb?
According to my research at the time, jamming is impossible on the RZUSB, at least by default, because there's no way to disable CSMA/CA, meaning it always waits for a clear channel before sending (see my previous post just above). However, I did not do much investigation on whether or not it's possible to correct the firmware to enable a proper continuous transmit mode. Regardless, Atmel's datasheet seems to suggest that for hardware reasons this may not be possible.
My suggestion here would be to look at the chip, and figure out how to put it into test mode. Most RF chips have a test mode that is required for use during FCC certification. When used, this can also make a jammer, of course that is not the intent, nor is it supposed to be used outside of a test lab. Remember to implement and use legally. Anyways, having said all of that, I think you will have the best success by changing the firmware to allow it to go into this mode in order to do your jamming. I have not looked at the data sheet however, and Spencer may have already found this to not be there for some reason on that chip. On Thu, Feb 9, 2017 at 12:22 AM Spencer Michaels notifications@github.com wrote:
According to my research at the time, jamming is impossible on the RZUSB, at least by default, because there's no way to disable CSMA/CA, meaning it always waits for a clear channel before sending (see my previous post just above). However, I did not do much investigation on whether or not it's possible to correct the firmware to enable a proper continuous transmit mode. Regardless, Atmel's datasheet seems to suggest that for hardware reasons this may not be possible.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/riverloopsec/killerbee/issues/69#issuecomment-278550388, or mute the thread https://github.com/notifications/unsubscribe-auth/AGo9gy2W0K11ana9TdF-4HKjO3kdCBz1ks5raqKqgaJpZM4I-Dtl .
@arunmagesh , @sxmichaels , etc - see the new firmware 004 being merged shortly and try that. Please inform if that resolves.
closed - long idle
I am trying to implement a jammer using Killerbee on an RZRaven USB. In
dev_rzusbstick.py
,jammer_on()
andjammer_off()
are marked as unimplemented. However, in the firmware (air_capture.c
), it appears that everything necessary for jamming — as detailed in theAT86RF230
datasheet section on PBRS mode continuous transmission — is implemented there in C. I have manually implemented the necessary parts of the Python code to run those C functions, but (as can be seen through Wireshark) only a single packet is sent, rather than what I assume should be a continuous stream. Is there some additional coding that needs to be done, and that's why the jamming functions are still considered unimplemented? It seems like everything that needs to be implemented is there.