-
Notifications
You must be signed in to change notification settings - Fork 405
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Timeout problem with RT3570 Wireless card #303
Comments
this suggests the driver generates bad packets. it would be interesting to know which exact packet caused this.
this is interesting, i can't see an association response in the ra3570.pcap |
The pcap I uploaded was taken during the attack, I can take one during the aircrack association test if you need it? Editing to attach new pcap: rt5370_assoc.pcap.gz |
i assumed you used reaver for the association step, since your command line lacks -A parameter |
That's correct, I did not use -A with reaver. The first pcap I uploaded is from the failed reaver commandline you quoted above:
The rt5370_assoc.pcap is from the aircrack association test using this commandline:
|
please checkout git commit fd5dc95 |
Edited - correct pcaps are attached. Thanks -- pcap from newly compiled reaver with -O: pcap from concurrent tcpdump: Thanks! |
Reaver output:
|
the FCS checksum thing was a red herring. it's been fixed in the very next commit: i guess a 1.6.6 release is really due... the tcpdump capture is interesting. we have the first assoc request packet immediately followed by EAPOL start, as if reaver would misinterpret one of the authentication success packets as an association success one. |
I just compiled the latest commit and tested. It still fails but the errors are much different now. Attaching console output and pcaps: reaver_g6191595_console.txt |
you need -N, its omission caused the premature abort you're seeing |
Thanks! I added -N back, and at first saw the same errors as previous builds. After crtl-C and restarting reaver 3 times, I had success. After rebooting the router to repeat the tests, it appears that I need to stop and restart reaver multiple times before it succeeds, so the success is intermittent. I started taking pcaps again until I could get a second success. It took 10 tries, with the 10th one being the success. I've attached all 10 related pcaps and the output from the 7th try through the successful one (My buffer cut off all of failures before I thought to copy and paste them all, but the errors prior to success are all the same). Any ideas how I can get more consistent results? reaver_with-N_1-10.pcaps.tar.gz Thank you!! |
Good morning! Just wondering if you have any suggestions for how to get more consistent results with the ra5370 wireless card? |
Just came to update that it appears to be any card that uses the rt2800usb driver. I have also tested a ra5372 card with the same inconsistent results. Approx 10% success rate against known, vulnerable APs. 100% success rate against the same networks with cards that use rtl8812au drivers. Unfortunately, I can't just use the known good card. My use case requires the cards that use the rt2800usb driver. Any updates would be most appreciated! Thanks! |
have you guys tried null pin.....so far all TP LINK's routers have been a pain,especially the vendors RalinkTe and AtherosC |
@mtnsec if you have 2 adapters try attacking a TP LINK router at the same time, for one of the terminals specify the argument -p as (-p '') without the brackets and include the quotation marks.....the TP LINK router should give up the pin. |
Though this is out of topic.........is there a way you can Crack a captured PMKID offline from a router....using the same consept as the pixiewps employs without the time consumption in hcxdumptools and hashcat and the possibility of a trillionth passphrase actually getting to work. |
The problem happens only with wifi cards that use the rt2800usb driver. The exact same attacks against the exact same networks succeed with wifi cards that use the rtl8812 driver. I'll double check null pin attacks, but I vaguely remember that particuar attack fails against the targets we're testing regardless of whether we're using a Ralink or Realtek wifi card? I have other WPS targets (not TP-link) that we can test and the results are consistent. The Ralink cards have about a 10% pixie dust success rate when the Realtek cards have a 100% success rate. What we really need is a solution for the Ralink cards, because we don't have the option to buy enough Realtek (or other working chipset) cards for this project. :( |
Okay...lemme see if i can find a method to help. |
send me your Ralink specs i.e range,version number...etc. I need to buy the exact one(s) your using. |
I've tried these three cards: https://www.amazon.com/Panda-Wireless-PAU06-300Mbps-Adapter/dp/B00JDVRCI0/ https://www.amazon.com/Tenda-W311MA-150MBPS-Wireless-Adapter/dp/B006GCY9PS/ And this is the one that I collected all of the above packet captures with: Thanks! |
got it....i've already ordered the tenda and panda.....will get back to you if i find a solution. |
I appreciate the help! |
mtnsec, try this patch |
case 4:
- ret = process_authenticate_associate_resp(0);
+ ret = process_authenticate_associate_resp(1); this looks like (0) was an oversight to begin with, and we should apply it generally, don't you think? |
Yes. |
Thanks! The patch provided by @1yura fixed it for me. :) |
@1yura any chance you could get the patch into an upstreamable form ? |
Of course ) |
Just checking in to see if there's a plan to incorporate this patch into the official release? I have multiple devices to install, and I've been holding off waiting for the ability to just clone and build, instead of clone, patch and build... |
i was hoping that @1yura prepares a PR with commits explaining the single changes he made and without //HACK comments, i.e. "upstreamable" |
This patch was created several versions ago. Now I discovered it is enough just
And use -N option. |
This problem only occurs with RA5370 (driver rt2800usb, I have two of these made by different manufacturers and both have the same problem) wireless cards (I have more than one, and they all exhibit this behavior). I have success with rtl8812au cards. I went through your troubleshooting guide here: https://github.com/t6x/reaver-wps-fork-t6x/wiki/Troubleshooting
My results are below:
First, info about my setup:
Kali 2020.1 on a Raspberry Pi4, kernel info:
Wireless card driver info:
I had previously been trying to use wifite2, and the WPS tests with reaver have been failing so I'm now working directly with reaver and not wifite. Here is the error/problem (I'm using -N because I saw in an older issue here that Ralink cards require it. All adding -N did was increase the amount of time before it times out and fails):
Here is the aireplay injection test result:
Here is the association test result:
The next step says to take a packet capture and determine if there is a reply to the EAPOL messages. I've attached my capture, I see the router responding but not the same way that it does in a successful attack.
Also for your reference, I'm attaching a packet capture of the same attack against the same router using a rtl8812au wireless card. This attack succeeds, so it rules out the problem at the router. I have tested both of these cards against multiple WPS-enabled routers with the same results.
For your reference for filtering the captures:
Router MAC = d8:0d:17:14:2f:6e
RA5370 MAC = 1c:bf:ce:90:1e:8a
rtl8812au MAC = 00:c0:ca:96:67:27
captures.tar.gz
The text was updated successfully, but these errors were encountered: