Ragnt / AngryOxide

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

Crash with Kali Linux (fully updated - last version of AngryOxide) #27

Closed dominikheiss closed 5 months ago

dominikheiss commented 6 months ago

Describe the bug It crashes right after the start:

image

thread 'main' panicked at src/main.rs:1095:48: called Option::unwrap() on a None value
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Hardware (please complete the following information):

The wlan drivers work as far as I can tell in other tools. Regards and thanks for you effort

Ragnt commented 6 months ago

Looking into this

Ragnt commented 6 months ago

Can you resend that same screenshot (the startup messages) but after doing the following:

  1. sudo ip link set wlan0 down
  2. sudo iw dev wlan0 set type monitor
  3. sudo ip link set wlan0 up
  4. sudo iw dev wlan0 set channel 1

That will show me that nl80211 is correctly identifying the frequency/channel data set by an outside program.

Running AngryOxide again after that, does it crash, and is it immediate? Can you determine which channel it crashes on (if not immediate).

dominikheiss commented 6 months ago

Hey, thanks for your help. Sadly, it didn't work either.

image

at first I could see the boarder of your tool... (and I thought "now it works") but like 1 seconds later, same error.

image

All further attemps did crash like 1 second after the "Sockets opened" message. I tried with only Band 2 or 5 parameters - no change.

Ragnt commented 6 months ago

It's failing to retrieve the frequency (or deduce the channel, not sure which) from netlink. You aren't the only person experiencing this issue, but it is (seemingly) only happening with Realtek out-of-kernel drivers.

I'm digging into it and trying to find a fix, if you want to continue to help you can pop into the discord, otherwise I'll update here when I get somewhere on this.

Ragnt commented 5 months ago

The latest commit enables tracing and may give me the information I need to fix this. If you could rebuild from the master branch and run like the following:

export AO_LOG_LEVEL=debug
sudo angryoxide -i wlan1

This will create a directory named "logs" in your current directory, and if you send me that log directly as a private message (for privacy reasons) I may be able to look through it and identify the issue.

Thanks!

SrgSkittles commented 5 months ago

Hello, I am experiencing the exact same issue and cannot find a solution to get angry oxide to run

SrgSkittles commented 5 months ago

I tried running export AO_LOG_LEVEL=debug sudo angryoxide -i wlan1

but it still has the exact same error as in the screenshot from the person above

Ragnt commented 5 months ago

I tried running export AO_LOG_LEVEL=debug sudo angryoxide -i wlan1

but it still has the exact same error as in the screenshot from the person above

Did you build it from the latest source? The crash will still exist, but it will print a debug log that we can use to help troubleshoot.

dominikheiss commented 5 months ago

I rebuilt it from the master branche with these instructions:

# Install Rust
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# Clone this repo
git clone https://github.com/Ragnt/AngryOxide.git

# Build/Install
cd AngryOxide
make
sudo make install

Then I that:

export AO_LOG_LEVEL=debug
sudo angryoxide -i wlan0

But I don't see any logs directory...where should it be?

image

Ragnt commented 5 months ago

Unfortunately I had to pull the tracing from the repo, as there was a conflict that caused another more widespread crash.

I'm working on pushing some updates to the underlying library that may resolve this, but I also need to try and reproduce it locally to make sure.

One thing I will ask is that you run:

iw --debug list > iw.log 2>&1 and send iw.log, which may help me determine where the failure is happening.

Ragnt commented 5 months ago

I have sent an update that may correct this error, but I'm not positive.

Additionally I added a catch for this specific error that will give some more information whenever the crash happens.

Ragnt commented 5 months ago

After some more testing I am concluding for now that this is a driver issue, and suggest to avoid Realtek out of kernel drivers that seem to not be sending channel information in monitor mode (or in station mode, maybe?)

When I get my hands on a Realtek adapter again I will rerun thorough testing locally and try and resolve this on my end.