DataHead

I've done this, and it works fine for me. If you can ensure that your sdcard is properly functioning, it should work no problem.

That graphic sure beats the hell out of my ><v's lol

The sensitivity on wlan0's ar9331 chip is a lot higher. The range on wlan1's rtl8187 chip is higher. They have their pros and cons. But things to keep in mind. Higher dbi antennas start to work differently. They will not be transmitting in a perfect 360 of all axis. Instead they start to narrow. Think of the 9dbi looking like this when it emits: >|< it spans out in kinda a sideways v. And once you hit 12dbi, the signal becomes more like a V shape, shooting up into the air ( so putting the 12dbi antenna upside down and up high from the ceiling will get you better WiFi results ) So when this becomes a factor from omnidirectional antennas, placement becomes more of an art lol, rather then just setting an antenna down any old place and forgetting about it. You will want to try a find a good height for it. The antenna you use and where you place it, is going to be a key element if you are going to use higher dbi antennas. I do this with my 9dbi all the time, and it's a difference of 1ft in height that will show 20+ more networks, or get me a further broadcast range, depending

The CM team is rather quick to implement fixes before it's implementation in the official android repo, so seeing fixes in their 4.x builds, would not surprise me.

I'm almost certain that the txpower on wlan0 is hardware locked ( I might be wrong, it's been a while since I've tried on that interface) but i know for fact that you can up the txpower of wlan1 nicely :-) And another note, country code BO has changed in its limitations, it can not do 30dBm. I'm not sure if the crda in 2.4 firmware has updated to reflect this change, but for now you can use country code BZ just incase.

There are security updates on android for this. I've flashed a few roms on different phones, and all except one of the 3 seem fixed in 5.0+ But lower versions, on my phone, are vulnerable.

-vv gives more output on what's going on with a default attack, and -vvv is for pixiewps related output and enabling. Some things to take note here, is to ensure you have a correct WPS setup on the target AP, as you are timing out. Also, try some different commands. ( I always add -vv to see more of what's going on ) And to be sure, reaver -i mon0 -a -N -vv -b A0:F3:C1:B1:3A:62 The new firmware released for the pineapple, is much more recommended. As it handles interface monitormodes a bit better ( no wlan1 down etc before use ) And would become wlan1mon instead It is also worth noting, that you can also be too close to the target AP.

If you also use reaver via ssh cli, please show me the full command you are using. If you add -vv or -vvv to the reaver command, does it give you more output? Does bully work and not reaver? How close is the access point and how good is the signal? I apologize the amount of questions asked, but I can not reproduce the issue, and have done numerous fresh installations to try this. Also, via ssh, before you are using reaver , are you changing your txpower? If not, could you try upping it to 30dBm and then trying and posting results

Okay, doing a wash scan via ssh, try taking down the monitor mode enabled device before using wash / reaver / bully. in this example, I will use wlan1 airmon-ng start wlan1 #to start monitor mode ifconfig wlan1 down #to bring down the wlan1 interface wash -i mon0 -s #then the scan And let it sit for a minute. If still nothing, try wash -i mon0 -C -s Sit for a minute, and if nothing again, can you verify that you do have enough space on the internal storage? I have noticed on very low space on internal installs, wash and such will fail to produce results, and reaver / bully functionality seems to get faulted. Not just with this version, but with original versions also. If you had installed the portal auth infusion, that also seems to take a hunk of the internal storage when first installed, and was a common scenario of the internal space being filled up quickly from several troubleshooting sessions with others. And some, were just too many other packages installed, etc.

Can you please explain the process you are using in full step by step detail? Have you any prior installs? Did you do an sd install? If so, did you do the proper symlinking afterwards?

I think they mean, if you are on Windows, open up a command prompt and type ipconfig Then look at your internet connected device, and find the ip address of the "Default gateway" Then type http://DefaultGatewayIPhere where DefaultGatewayIPhere, replace it with the Default gateway ip address you see on your connected / internet connected device. it will probably be similar to the ones below. If not, then still use the Default gateway you see from ipconfig 192.168.0.1 192.168.1.1 192.168.10.1 192.168.100.1 10.0.0.1 10.0.1.1 10.0.2.1 10.0.2.2 Those are the defaults I can think of at the moment But just do ipconfig

How much free space do you have left on internal storage? I've replicated the issue on low internal space left with reaver / wash installed on internal, caused no wash output. Also, I have not yet verified this to replicate the issue, but have you removed the sdcard install of reaver prior to the internal install? I'd check to see if the binaries are still left behind on the sd if not. Maybe there is a conflict of which wash is currently being executed?

You can clone the page with the portal-auth infusion :-)

If you did an sdcard install, can you verify that all symlinks are in place from following mkdir /etc/reaver ln -s /sd/etc/reaver/reaver.db /etc/reaver/ ln -s /sd/usr/bin/reaver /usr/bin/ ln -s /sd/usr/bin/wash /usr/bin/

And what if you run wash via the command line?

I had taken down the fork

We didn't change much of the old functionality of reaver in our fork. The only changes were made that we did for the old reaver functionality is all bug fix / improvement, but wash has had a change in its -C switch being default implied ( reverse functionality ). But we've added a ton of new features to reaver. So the old syntax is pretty much the same except for wash -C. We didn't make it so it requires new aircrack-by 1.2 rc2, the wlan0mon etc references in the documentation, are there because now since 1.2 rc2, wlanXmon is the new standard default for airmon-ng interface naming. So you can use older versions of aircrack / airmon ( mon0 interfaces etc ) Regarding the infusion, I couldn't tell you what all will be done by whistlemaster, but all that needs to be done to bring it up to date, is just a bit of extra parsing / make use of and for the new commands we've added. But that all depends on how he wants the infusion to functionally work.

Walt, I assume you clicked the "show" link in the available user infusions in screenshot #3? If not, click that

I had followed the process as it is outlined, only thing I could think of is grabbed the wrong version of hostapd and didn't pay much attention, since it patched through, and compiled. I will try again later today, but when I am able to personally test it first before sending it off on here.

link removed due versioning issues

The NH is much more stable than the nha , my personal preference is the NH

I'll try a cross compile :-)

Endian 1 in the repos is the latest version, that 2 was a naming incremental from my compiles. If you need, follow the proper install chain ( just some proper symlinks). This has been an issue for over a year or so, but not an issue with reaver or wash. It's across tons of different packages that if installed to sd, aren't linked properly to internal root Another note, -C is now reverse functional. -C in the command disables, no -C in the command enables. Try the wash command without -C

Ah yes, when a diy solution like this is made, with the satellite dishes and a biquad, you have to be rather precise with the angling you put the biquad so it's signal is coming from the direct center of the dish. it will be rather directional. They will do better if it is high in the air, like on your rooftop so it doesn't have too much blocking the signals, and with a slight angle downwards from the horizon line ( depending on your surroundings of course ) And in regards to the op, the best omni directional will probably be a 9dbi standard like that in the hakshop, I think it's at 12dbi with omnidirectional antennas that the signals start to "V" upwards. And if that's no problem with the upwards type "V" signal, just place the antenna high ( maybe rooftop high ) and upside down, and you will get better results as such in that scenario. Just remember the higher the dbi in standard omnidirectional, the more narrow the signals gets and tighter in that V shape waveform. Now there are things that try to surpass this bit, and the are ones such as this WiFi discone omnidirectional antenna, and this is even an easy diy solution, but is better for signal quality at this than range ( schematics for range probably exist, but I haven't looked ) https://youtu.be/IaFSX7ycj0I

you mean a Tube 2H?