OscarAkaElvis
commented
5 years ago Hi, you've violated our policy talking about other tools here.... but I will not close it directly this time (is what is supposed must be done due an issue creation policy violation)... the people say sometimes I'm a hard bone as admin... 🙄 And I must add that I saw you even didn't starred our repo... I must admit that I don't like people who is spending time to write long issues but is not able to spend a second to click on "star" to support the project... yeah I know, maybe I should add it to the issue creation policy...
Anyway, I'll try to answer to you. Yeah, as you said this chipset is blacklisted... so consider this answer as an "extra bonus".
-
I know the problem very well. Time ago, that chipset was not compatible at all with airmon... and that was better because since version 8.11 airgeddon is able to detect it and if a card is not compatible with airmon, and if it is not compatible it handles it in the way you suggest (ifconfig down, iwconfig mode monitor, ifconfig up). During that days even this chipset was working fine in this way. Some time after that, another update of the driver came up making that chipset compatible to airmon.... but, that was tricky! because it is not fully compatible, it just partially compatible and here the problem comes... airgeddon now is detecting it as airmon compatible and of course is handling it as "full compatible" but it is not, and the problems arises. Again, the problem is not on airgeddon's side. "Dirty" stuff needs to be done to solve this and as we said many times, we are not going to do customizations for a specific chipset. We like standard stuff. Anyway, maybe a possible solution comes for all the RTL8812AU users due the new feature we are developing. Did you checked it?: https://github.com/v1s1t0r1sh3r3/airgeddon/issues/308 So we must wait until the release of that feature. Evel further, I bought a dirty RTL8812AU card... I hate myself for doing that, but I'll try to do it again for you (all that chipset users). I'm planning to create a plugin with all the needed dirty stuff to work flawlessly with this damn chipset. But this will take some time yet... first release of the plugins system, then I need to receive the dirty card (it comes from China, it will take some time), and then the problem needs to be analysed closely doing tests to create the plugin. So grab some popcorn and be patient.
-
The DoS is a tricky thing. What works for one scenario is not working for another. Sometimes a DoS attack is not affecting some clients, sometimes the attack is not affecting the AP. Sometimes some clients are beaten and others don't on the same attack. It depends of the kind of attack, the chipset, the kind of client, the AP and even the signal to the AP is affecting to this. So what I can say is... if some DoS is not working for you, try another one. In my experience aireplay attack is usually a good choice to deauth Android clients but I can't deauth using it a windows with an Alfa card as client. For that is better mdk. I tried all the commands inside airgeddon and outside airgeddon and the effect is exactly the same... so airgeddon is not the problem here. As I said, DoS is tricky. Anyway, if you feel that a command is working for you out of airgeddon, paste it here and let me to check. I'll try it out of airgeddon and I'll modify airgeddon to test it inside it (I can bet the result will be the same because airgeddon is just a wrapper). Another more advice for you: maybe mdk4 is not working well for you. Many people said that using it with some chipsets the results are pretty bad. Maybe it's your case, I can suggest to use mdk3 instead and try again. You can change it from the options menu or modifying the option AIRGEDDON_MDK_VERSION on .airgeddonrc file as explained in Wiki: https://github.com/v1s1t0r1sh3r3/airgeddon/wiki/Options
-
Not sure to understand this point... sound to me exactly like the point 2. Paste a command working for you outside airgeddon or the opposite, paste here a command from airgeddon which is not working for you. As I already said, all the existing commands in airgeddon were tested outside airgeddon and inside airgeddon and they worked at some scenario. Maybe the problem is not airgeddon, is just the scenario which we already said is tricky to know. Believe me... I have more than 3 alfa cards, more than 6 different models of Access Points, some different victims to add as clients (windows, windows vms, linux, different versions of Android, etc) and I tested all with all my possible scenarios. Of course there are more scenarios than what I'm able to test but is all I can do... test as much as possible with the hardware I have. Soon I'll have a card with the cursed chipset and I'll be able to do more tests... anyway, using the logic, if what is now in airgeddon is working outside and inside airgeddon with all of that scenarios, using more than 3 different wireless cards with different chipsets... do you really think the problem is airgeddon? I think the problem is RTL8812AU chipset again... and again... and again.... I can understand the frustration of the RTL8812AU users of buying an expensive card and then to find the surprise that the card was not the best choice... sorry but is the truth.
I'll leave this open for a while maybe somebody could want to add some interesting data... but you must understand that we do our best, spending our own money on our free time to give to the community a handy tool compatible with many Linux and with many cards. We try to do the best to work with a standard "base line" and we can't start making exceptions with crappy cards/chipsets. I think the plugins system will be the solution for many problems. We need to wait! 😸
Hulkstance
ghost
What is your airgeddon version?
9.23
What is your Linux O.S. and which version?
Kali Linux 2019.3
Which is the chipset of your wireless card?
Realtek RTL8812AU (AWUS036ACH)
Describe the issue and the steps to reproduce it
I know that this chipset is on your blacklist but still it's worth reading what I wrote below.
As some people suggested, driver v5.2.2 works fine. https://github.com/aircrack-ng/rtl8812au/tree/v5.2.20
Problems: 1) If you use monitor mode option in airgeddon and then fetch connections, it will slow the fetching for like 5-8 seconds. If you manually start monitor mode with the commands below, that problem won't exist and it will fetch connections instantly. AWUS036NHA doesn't have that problem.
2) Airgeddon doesn't actually deauthorize. I tried all 3 options (mdk4, etc.). The problem persists even with Alfa AWUS036NHA. When I attempt to handshake my own network, it doesn't throw me out of the Wi FI connection, so it can reconnect my device and successfully handshake afterwards. Only AWUS036NHA and Fluxion 2.9 is working fine (https://github.com/wi-fi-analyzer/fluxion) are it throws me out as well as it automatically handshakes after that. Note that Fluxion 5.9 is not working either.
The problem is that if it doesn't deauthorize me properly (throw me out)), it won't succeed to handshake at all. I know that because I tested it a few times by disconnecting my device manually and then reconnecting while it is still handshaking. It handshakes right after I reconnect.
3) Specific problem to AWUS036ACH and 1). Assume that I have manually started monitor mode. It won't fetch any stations until I manually execute
aireplay-ng -9 wlan0in a separate terminal window while I'm handshaking. I think the problem is inconsistency between airgeddon's commands and aircrack's.The driver itself is working fine when you manually type stuff but not when you do that through airgeddon. Is there any way to handle this? The second problem I mentioned is not related to that problematic chipset, what about it?