Darren Kitchen

It used to be pretty straight forward. Desktops, laptops, servers. Now smartphones, tablets, raspberry pis -- what's a computer anymore *chuckle* If it has an IP stack and a web browser it'll most likely play nice with the pineapple ;)

DNS seems unhappy or so says Chrome. It resolves no less.

Can you document the steps you took to create the error? I'll try to reproduce it / debut it on my end. Thanks!

You're right - our lack of documentation and support for this feature is appalling. Getting a USB Modem can feel like magic when you get one working, because so many don't and the ones that do require a lot of tweaking. This is a very difficult feature to tackle because there are so many variations from manufacturer to product to product version plus all of the carriers. I have 4 or 5 that work great, and have more on the way. It's sort of the thing that once you find one that works you just stick to that. I'll be picking up some more today and should have a video up tonight on the ones I have in my collection. It's my hope that we can put together a list of supported out-of-the-box modems from which you can select default configs from a drop-down in the mobile broadband menu. Doing to will require breaking the menu out into an updatable infusion and adding some way for others to share their known working configs. I'm all ears on a good method for this. One of the issues is that carriers, at least here in the states, have for the most part dropped traditional usb modems. Mostly what you see now are "personal wifi hotspots" like the MiFi since consumers couldn't figure out how to install windows/mac connection software *facepalm*. Thankfully some of these support usb tethering, which is actually a better solution for us as we don't need to micromanage the connection. Per the USB Modeswitch device reference: http://www.draisberghof.de/usb_modeswitch/device_reference.txt ####################################################### # Pantech UML290 # # Contributor: Davis Ford DefaultVendor= 0x106c DefaultProduct=0x3b11 TargetVendor= 0x106c TargetProduct= 0x3718 MessageContent="5553424312345678000000000000061b000000020000000000000000000000" So yes, it should be supported. That said you'll need to know the carrier specific configuration options. I can only guess at those as I don't have Verizon service nor this dongle. I'm going by T-Mobile today to buy their latest dongle for *hopefully* approved and fully supported status. I'll see if I can't do the same with Verizon. D

Thanks, we appreciate your praise. When you look at the big picture I guess we have come a long way since September 7, 2008 :) http://hak5.org/episodes/episode-401-wi-fi-pineapples

The pineapple software should run on similar openwrt hardware though it may take some tweeking to get it going. No guarantees but you should be able to copy over /pineapple to a 54gl with ease. Support for third party hardware is outside the official scope of this really small team. Still, would love to hear more about your wifi triangulation project. Cheers!

I'll have the source to the modified openwrt base available tomorrow and we'll follow up with a cross-compile / build guide. Edit: source has been updated on the wiki

From the way I've interpreted the rules the regulations governing point-to-point vs point-to-multipoint are on a radio basis. Seeing that the MK5 is the only dual-radio WiFi system on the market I can't see how legally it would be any different than two separate systems attached. For example two MK4s connected by Ethernet. I have successfully made long distance repeater links with MK5s using wlan0 as AP and wlan1 as client. I can't imagine adding a third interface would be any different.

Yes. Ad nauseam. I've exhausted every aspect of the radios on that list and have even come back around to gather power consumption data as well. Supported == Initializes, Scans, Associates, Transfers data at rate above that of wlan1. Unsupported == Fails to initialize, Initializes but fails to scan, scans but fails to associate, associates but fails connection drops (usually resulting in wlan2 becoming wlan3, wlan3 becoming wlan4, etc...) Channel conflicts, polarization mismatch, antenna closer than half a wavelength to radiator of similar frequency, overhead (don't expect 50 Mbit with, say, SSLStrip running - that's just not going to happen on 400 MHz MIPS), bad cable, general protocol unhappiness (AP configured for N only?), alignment of Jupiter... Are you getting better speeds from the AWUS036H connected to a different machine? Tried a different cable, card, location, orientation, access point? Let us know what you've tried and we'll be as helpful as possible figuring it out.

IIRC 1.8v. Let us know how your tinkering goes and feel free to reach out to me directly (email is best) if there's anything else we can help with pre-HDK. Cheers!

Updated with a link to a video I made demonstrating full saturation at low power consumption. Check it out https://www.youtube.com/watch?v=L3D84g0ZYrE& Xcellerator, we plan to expand on the pineapple ecosystem including higher power radios. Our hope is to have an HDK available by defcon.

Below is a list of supported and unsupported WiFi hardware for use with the WiFi Pineapple Mark V client mode (firmware 1.4.0+). Background: If you've been following this thread you may know that the Realtek wireless interface (wlan1) on the MK5 has a throughput limitation of 11 Mbps. This is due to the reference designs implementation. Our development focus has been on stability, with the wlan0 interface intended to act as an access point while the wlan1 interface plays a supporting role as both monitor mode and frame injection. The later will come into play more with the coming Karma-NG update (code name Karmadactyl) set to address the ever changing wireless landscape. Edit: Now known as PineAP. wlan1 is still capable of acting as a relay from a nearby AP (client mode) however the throughput is limited to 11 Mbps. This does not affect the MK5 when using Ethernet, Tethered Android or USB 3/4G Modem as the Internet gateway. High throughput client mode can be achieved by using one of the approved external radios below. This list is not complete and will be updated as new hardware is tested. It is likely that if you come across similar hardware using a supported chipset, that hardware should work as well. Manufacturer Radio Chipset Status Power Consumption ALFA AWUS036NHA Atheros AR9271 Supported 100mA Average ALFA AWUS036H Realtek RTL8187 Supported ? TP-LINK TL-WN722N Atheros AR9271 Supported 170mA Average TP-LINK TL-WN721N Atheros AR9271 Supported ? ALFA AWUS036NEH Ralink RT3070 Supported 160mA Average ALFA AWUS036NH Ralink RT3070 Supported ? Generic Generic Realtek RTL8188CUS Unsupported ? TP-LINK TL-WN823N Realtek RTL8192CU Unsupported ? TP-LINK TL-WN725N Realtek RTL8188EUS Unsupported ? ALFA AWUS036NHR Realtek RTL8188RU Unsupported ? Hak5 will soon offer a branded AWUS036NHA in the HakShop at cost for MK5 customers. In the future we hope to produce an integrated solution with a WiFi Pineapple sporting additional interfaces using the latest chipsets. Given the time and cost of development we do not expect this to be ready in 2014. As this project evolves we listed to your feedback closely and will make changes to the WiFi Pineapple product / ecosystem accordingly. Thank you so much for making this community what it is - we couldn't do this without you. Video: https://youtube.com/watch?v=L3D84g0ZYrE

Actually it's lower than 2.5v from what I understand. I'll have more details on SPI/I2C when our engineer gets back to me with the code. It should be nearly as straight forward to speak to in openwrt as, say, the LEDs. FWIW, I was able to find the torrent for Spiderman 3 on Google in less than a second. So much for being 'copyrighted'.

We're putting in a request with Qualcomm legal to release the pinout proper as well as continuing work on our API which will allow you to interface with the pins from our openwrt build. As soon as we have something workable well release the code/docs with the hardware to follow. Interesting reading over at https://forum.openwrt.org/viewtopic.php?id=36471&p=1 Edited for compliance.

Seb showed me a demo using some code that makes the main interface look better on a phone, but then the large tiles look terrible. A more mobile responsive design is on the list - but it's a long list. If anyone happens upon magic code that "does the thing" without compromise we're all ears.

Unfortunately due to NDAs that must be signed with some of the vendors (like Atheros and Realtek) it can't be true open hardware - however a schematic should be totally doable. I'll see what I can get together from our hardware guy. Sorry if it seemed like it's secretive - it's not it's simply that I don't have the information else I'd be publishing it here. From what I understand from our engineer the expansion pins are rather sensitive and operate in a sort of non-standard way. We really won't want anyone bricking things because they hooked a 3.3v TTL or something to it. I'll see what I can get leading up to the official HDK release. That's some formidable kit! I love the I2C bus. Congrats. What's the language?

There's a coming feature that will more easily allow you to switch the Ethernet interface from a static IP to obtaining one from DHCP. For most cable modem configurations I've seen this would do the trick. ADSL is much more difficult due to PPPoE.

Thanks for providing detailed logs. I apologize for the inconvenience. Please contact shop@hak5.org with your order # and we'll make sure you get a working unit ASAP.

The MK5 needs ~8-10 Watts to be happy. Watts = Volts * Amps. Some laptops only supply a half amp, so 5v * 500mW = 2.5W -- not enough. Most modern cell phone chargers / power banks work well.

The first expansion board is based on Arduino and so far so good - we hope to have it ready for defcon. The hold up right now is industrial engineering wise - getting all the pins to fit and what not. External processor? Maybe as a different module. We're looking into all sorts of opportunities for expansion.

I wish I had a good answer regarding the MK4. Right now our focus is on building in the advanced MK5 features that will enable the next generation of wifi attacks. My hope is that when we've stabilized that platform we can backport any of the features that aren't reliant on the MK5s enhanced hardware, however I sadly can't make any guarantees as to that timeline. My intention isn't to abandon the product or plan obsolescence - it's just that in this game of cat and mouse we need to continuously innovate on both the software and hardware side. This is resource intensive and comes at considerable cost to our very small team. The MK4 can make a formidable companion to the MK5 in fact. The MK6 isn't coming out for a very long time. I too have a drawer full of old smartphones - and while I wish I could still be rocking my OG Motorola Droid, there's just no way in hell that hardware could ever run Kit Kat. I don't mean for you to feel like we've left you in the dust, but we're full steam ahead on the new MK5 features right now and if we slow down to focus back on the MK4 we'll miss our deadlines and upset those users as well.

Dress the pineapple and battery up in a similar shade plastic housing and pipe clamp it to a utility pole*. Instant urban camouflage. *Except don't unless you work for said utility.

Perhaps the WiFi Pineapple is morphing into the Wireless Pineapple? =) "Sniff ALL THE PACKETS!" I must say this complaint turned intellectual discussion ended very well and I must also commend ZorprimeSDF1 for both expressing his feelings and being open enough to see everyone elses point of view. This is why our community rocks! You should all be proud.

You can specify the location of the Karma log in configuration. You can tail that in the command line or watch the output from the Karma tile. Click the tab heading to refresh.

Awesome infusion. Can you give me an example of how you would put this into practice? Perhaps it could make a good segment on Hak5. /me imagines a beowulf cluster of WiFi Pineapple SDR nodes!