Error: network down

[sn0ren]

After running successfully for a few minutes it shuts down saying "Error: network down". Using an Alfa AWUS036H running the precompiled binary angryoxide-linux-x86_64.tar.gz on kali linux

Also it would be nice to have a whitelist for networks you don't want to attack.

[Ragnt]

Any dmesg output at around the time of the drop? I’ve heard this one before but can’t reproduce locally yet.

Whitelist is totally possible. I’ll start working that and reply here when it is pushed.

[Ragnt]

Also is that kali in a VM or bare metal?

[sn0ren]

It's kali running on a thinkpad (x201) I just get device wlan1 entered promiscuous mode device wlan1 left promiscuous mode

[Ragnt]

Thanks,

The Network Down literally is the kernel reporting that the interface is down. The only time I have been able to reproduce this error is by actually unplugging the interface. Interestingly enough the last user to report this was also on a thinkpad running kali.

I'll continue to look into this and work on getting it figured out. In the meantime if any more information comes out that may be useful feel free to share, every little bit helps.

[Ragnt]

I imagine this is similar to the issues present here:

https://github.com/ZerBea/hcxdumptool/issues/12

But obviously I can't say for sure until I setup a Kali system.

[Ragnt]

Also it would be nice to have a whitelist for networks you don't want to attack.

v0.7.4 integrates this. I have tested it a bit but am not 100% confident it is bug free.

[Ragnt]

Alright, I have pushed a hacky fix that may work.

Basically I can reproduce this error by bringing the interface down while AO is running. However, if I bring it back up AO will continue as normal.

I think this is being caused by some other process attempting to take control of the interface, possibly doing a scan or something.

But just in case this is AO my hacky solution is that when that error is encountered AO will display the error in the status messages and attempt to immediately bring the interface back up. I don't like this solution but it's worth seeing if this resolves the issue. Obviously this is just a band-aid solution though.

[sn0ren]

Thanks, the hack works. I occasionally get the error message that network is down in the status messages, but the application continues to work.

Can't get whitelist to work however. When I start it up defining a whitelisted mac i get:

$ No target list provided ... everything is a target Whitelist xxxx is a target. Cannot add to whitelist. $ No whitelist list provided

Also I'm a bit confused as to why I'm getting multiple instances of the same access point and client in handshakes tab, with different status's. Some might have M1 and M3, some might have M2, some might have all and OK. But their SSID and macs are identical. Is that intended functionality?

[Ragnt]

Thanks, the hack works. I occasionally get the error message that network is down in the status messages, but the application continues to work.

This is good to know. I still am unsure what might be bringing that interface down, but I'll wait for more info or the ability to reproduce locally.

Can't get whitelist to work however. When I start it up defining a whitelisted mac i get:

$ No target list provided ... everything is a target Whitelist xxxx is a target. Cannot add to whitelist. $ No whitelist list provided

What is the full command you are running?

I'll test this out some more, but that is undefined behavior.

Also I'm a bit confused as to why I'm getting multiple instances of the same access point and client in handshakes tab, with different status's. Some might have M1 and M3, some might have M2, some might have all and OK. But their SSID and macs are identical. Is that intended functionality?

Yes! This is intended. The Handshakes list is a collection of every EAPOL message that is seen- IE every check mark is a unique EAPOL.

Check marks that are aggregated into a single row are assessed to be a part of a a single authentication sequence.

The goal is to receive EAPOL messages, validate they are of the same sequence using several validation techniques, and then confirm that we have all required parts of that sequence to form a valid hashline. This is when they are marked as "OK".

Seeing lots of EAPOL is the result of multiple sequences existing, and can be the result of frame retries or multiple attack attempts (because we are not seeing the entire authentication sequence and need to retry some time later).

When an AP has a 4wHS or PMKID it is no longer attacked, but you may still see passively collected EAPOL for that network.

[Ragnt]

Can't get whitelist to work however. When I start it up defining a whitelisted mac i get:

This was a logic error on my part that has been resolved in v0.7.5.

[sn0ren]

Thanks for clearing that up, and thanks for your great work on this application.

[Ragnt]

No problem!

If you have any other questions feel free to hit me up on Discord.