lunokhod

That's a shame.

No... I can't see it either! I hope this does make it's way back in here. I'm going to miss it if it's a no show. I wonder if it is included in the Tetra and Nano version of the firmware.

Thanks for that!

I've got a question about the radio configuration used in the Tetra. I'm a long time Mk V user and remember needing to get a third radio for the the WiFi Client connection as wlan1 couldn't be used in client mode AND be used for PineAP simultaneously. wlan0 is the access point. wlan1 is used for PineAP, injection/deauth/etc. wlan2 is used to connect to my local friendly WiFi internet source. I'm presuming a third WiFi radio needed for the Tetra if I want to configure it in a similar fashion? I'm using the Beta 3.0.0 firmware on my Mk V at the moment and am VERY happy with what it does for my older Pineapple. Lunokhod.

Yes I did. I've been playing with it at work today and am most impressed with it's stability. I used to be plagued with the Wireless Client connection to the internet dropping out randomly with the 2.x firmware. No issues with that at all so far.

Thanks for that. I worked around the issue. I rebooted without the NEH plugged in and the RTL8187 was still coming up as wlan2. I then "Reset WiFi Configs to Default" in the Advanced section of Networking. This reset the RTL8187 as wlan1. Plugging in the NEH after resetting the WiFi Config resulted in it coming up as wlan2. All good. Now the two MKV radios remain at wlan0 and wlan1 regardless of the external radio being plugged in at boot or not. Lunokhod.

How have I missed this for two months? :-) I've just flashed my Wifi Pineapple MkV with the Beta Firmware 3.0... and it's working very nicely. I was even able to update the MkV with my wacky +9.5 hours ahead of UTC time zone. One thing that is a bit strange... my external AWUS036NEH USB Wireless radio is wlan1. The MkV AR9331 radio is wlan0 (as expected), but the built in RTL8187 radio is now wlan2. phy0 wlan0 ath9k Not pci, usb, or sdio phy0 wlan0-1 ath9k Not pci, usb, or sdio phy1 wlan1mon rt2800usb Ralink Technology, Corp. RT2870/RT3070 phy2 wlan2 rtl8187 Realtek Semiconductor Corp. RTL8187 I've yet to power up the MkV without the external radio connected to see what happens.

Will an attached USB Ethernet adapter be able to be configured for both direct connection to a computer (inbuilt DHCP "classic" mode) and also direct to an existing Ethernet network with it's own DHCP server/gateway etc?? I'm glad you've decided to use RP-SMA connectors... I never fully understood why the Mk V had "normal" SMA sockets when 99.99% of all other WiFi SMA implementations are RP-SMA. Not overly keen with dropping of the native Ethernet port, nor the dedicated DC jack... but this being said, I'll still buy one!

Have you enabled Client Mode in the Wired tab, in the Network tile? Classic Mode is the original (classic) Wired network mode where eth0 is bound to br-lan and the inbuilt DHCP server. This is the mode to use if you want to connect a computer directly to the WiFi Pineapple via Ethernet. Client Mode is for when you want to connect the WiFi Pineapple to an existing wired network. You can then enable DHCP (the WiFi Pineapple will get an IP address, gateway, etc. for eth0 from an existing DHCP server on the wired network)... or you can set a Static IP address, Netmask, Gateway and DNS entries manually if you wish. You don't want to have Classic Mode enabled when you connect to an exisiting wired network. Two competing DHCP servers on the one network will only invite confusion. Lunokhod.

I've seen this behavior as well. Both on my Nexus5 phone (5.1.1) and a no-name generic Android tablet. In my experience, it seems to happen after an undetermined time. Right after boot, I can see and connect to the spoofed SSIDs generated by the WiPi without a problem... but after a time, I get the same result as you see in the video.

What kind of power supply did you use? Was it a regulated power supply? A high current un-regulatated wall wart power supply can have an open circuit voltage of 16V or higher. You should never use an un-regulated power supply... unless you are 100% sure the device you are using it with can handle it.

I notice you have wlan1 enabled. I believe that Dogma and Beacon Response uses wlan1 as part of it's operation. I have wlan1 unchecked and I seem to have no (short term) trouble with PineAP doing it's thing, I have seen many clients connect. Try and uncheck wlan1 and see what happens. Could be that if wlan1 is enabled... PineAp cannot use it?

I think there is still an issue with the current firmware. I posted about my problems last year in this thread :- https://forums.hak5.org/index.php?/topic/34070-how-can-i-help-the-mk-v-be-more-reliable/ I flashed my WiFi Pineapple last night with V2.3.0, left it running in my car at work... exactly the same as in the post linked above... and after a handful of hours you cannot connect to either the wlan0 open access point, the management (secured) access point or any of the PineAP created/spoofed SSIDs. You can see all the available SSIDs being broadcast... but you cannot connect to them. I've tried on my Android Phone, an Android tablet, an iPhone and a Windows laptop. A reboot will fix the problem, as will disabling and enabling wlan0 (and then restarting Karma and PineAP).

Is PineAP supposed to (or able to) use the Karma SSID/Client Black/White lists when harvesting SSIDs? I'm using my WiFi Pineapple at work and have it connected to my works WiFi connection. I don't want PineAP to harvest and then spoof the works WiFi SSID. Is there any way to prevent this? I've put the SSID in the Karma Black List and it still appears in the PineAP SSID Management window.

I've been playing around with the WPS infusion these last few days... it seems to be working mostly OK. I have an external radio (wlan2) a client interface (disabled), wlan0 is also disabled (no Pineapple AP operating), I'm connected to the WiFi Pineapple via eth0. Reaver and Bully are installed and working (as confirmed with a SSH session). enable wlan1, enable mon0 on wlan1, scan for WPS vulnerable access points, pick a "target", bring down wlan1, select program, monitor interface, ensure BSSID, SSID and channel are correct, Press Start! Reaver works as expected. Bully works but does not seem to update the xxxxxxxxxx.run file in /root/.bully/ properly. The .run file gets created, but there are times when the xxxxxxxxxxxx.run file appears to get corrupted (or not closed off properly) and Bully will not start when you try and "crack" that AP mac address again. Has anyone else seen this? I seem only to be able to run Bully (via WPS infusion) only once per WiFi Pineapple boot... after stopping it (within the infusion), it does not start again... although I can start a CLI Bully session and it will continue. I've seen the posts in this thread about creating symlinks for reaver and bully... does the WPS infusion work "better" when installed in internal memory than the SD card? Lunokhod.