Ragnt / AngryOxide

802.11 Attack Tool
GNU General Public License v3.0
957 stars 47 forks source link

Radiotap: UnsupportedVersion #38

Closed bogu88 closed 2 months ago

bogu88 commented 2 months ago

Trying to run it on a Pi 4 gives this error: Error | Couldn't read packet data with Radiotap: UnsupportedVersion. I built from source using the steps listed.

Expected behavior Works normally running on a laptop on Kali, but installing on rpi gives the error Radiotap: UnsupportedVersion. As well as 0 ERs.

Hardware (please complete the following information):

Thanks

Ragnt commented 2 months ago

Likely that network manager is controlling the interface still. Ensure it is not running, or anything else that may try and control the interface (such as dhcpcd).

On Mon, Jun 3, 2024 at 12:01 AM, bogu88 @.***(mailto:On Mon, Jun 3, 2024 at 12:01 AM, bogu88 < wrote:

Trying to run it on a Pi 4 gives this error: Error | Couldn't read packet data with Radiotap: UnsupportedVersion. I built from source using the steps listed.

Expected behavior Works normally running on a laptop on Kali, but installing on rpi gives the error Radiotap: UnsupportedVersion. As well as 0 ERs.

Hardware (please complete the following information):

  • Device: Raspberry Pi 4
  • OS: DietPi
  • Interface: Alfa AWUS036NHA

Thanks

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

bogu88 commented 2 months ago

So stopping dhcpd did solve the error, but still getting bad performance out of the pi with 0 ERs, so I'm assuming its just a problem with cpu speed or sd card performance is too slow.

Ragnt commented 2 months ago

Yeah, CPU speed is likely the culprit, optimization is an issue on this version when it comes to embedded systems. Headless mode helps there. I’m building the next version from the ground with embedded optimization in mind.

On Mon, Jun 3, 2024 at 12:55 AM, bogu88 @.***(mailto:On Mon, Jun 3, 2024 at 12:55 AM, bogu88 < wrote:

So stopping dhcpd did solve the error, but still getting bad performance out of the pi with 0 ERs, so I'm assuming its just a problem with cpu speed or sd card performance is too slow.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

olivervbk commented 1 month ago

I have the same issue: Couldn't read packet data with Radiotap: UnsupportedVersion

Platform: Raspberry Pi 4 OS: ArchlinuxARM (6.9.8-2-aarch64-ARCH) Device: AWUS036ACM (wlan1)

I have iwd running, but it shouldn't be managing the wlan1 interface...

I tested with tshark (tshark -I -i wlan1 -w tshark.pcapng), and looking at the pcapng I see the radiotap data included: Radiotap Header v0, Length 30

tshark seems to create a monitor interface mon0 and uses that. At one point iwconfig wlan1 mode monitor also seems to have created mon0 but then it stopped creating it, idk. Tried with airmon-ng start wlan1, which seems to rename the interface to wlan1mon, and tried to use that for angryoxide, but then things seg faulted and borked the driver/network stack.

Ragnt commented 1 month ago

That should be classified as a warning instead of as an Error, probably.

This usually happens (I think) because the driver is sending frames without radiotap headers to the buffer, but usually only the first few are effected. After that the rest come through fine.

If this is happening during the middle of running, then it almost certainly is iwd placing the device back into station mode.

TLDR; this is safe to ignore if you get it at the beginning of the runtime.

You don’t need to worry about the creation of a VIF for monitor mode. Tshark and Airmon do that, but we don’t. We set the interface into monitor mode directly. AO won’t start unless the driver is reporting that it went into monitor mode.

On Tue, Jul 9, 2024 at 2:01 AM, Oliver Kuster @.***(mailto:On Tue, Jul 9, 2024 at 2:01 AM, Oliver Kuster < wrote:

I have the same issue: Couldn't read packet data with Radiotap: UnsupportedVersion

Device: Raspberry Pi 4 OS: ArchlinuxARM (6.9.8-2-aarch64-ARCH) wifi: AWUS036ACM (wlan1)

I have iwd running, but it shouldn't be managing the wlan1 interface...

The interesting this is that I was testing this using tshark, and looking at the pcapng I see the radiotap data included: Radiotap Header v0, Length 30

tshark seems to create a monitor interface mon0 and uses that. At one point iwconfig wlan1 mode monitor also seems to have created mon0 but then it stopped creating it, idk. Tried with airmon-ng start wlan1, which seems to rename the interface to wlan1mon, and tried to use that for angryoxide, but then things seg faulted and borked the driver/network stack.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>