Darren Kitchen's post in Does anyone know what filesystem the mk2 sd card is meant to be formatted to? was marked as the answer
A few key points to note when using a MicroSD card with the Bash Bunny Mark II:
Payloads are executed from internal storage only. If a MicroSD card is present at boot in arming mode, it will be passed through to the host. To load payloads, boot the Bash Bunny without a MicroSD card present. Payload Modes
If the STORAGE ATTACKMODE is active, the udisk will be presented to the target as a mass storage device. In the case that a MicroSD card is present, the udisk presented to the target will be the MicroSD card In the case that a MicroSD card is not present, the udisk presented to the target will be the internal udisk partition. By default the udisk is not mounted on the Bash Bunny regardless of the ATTACKMODE specified. To mount the udisk from the perspective of the Bash Bunny, issue the command `udisk mount`. Mounting Considerations
The udisk partition — whether internal or MicroSD — can only be mounted on one device at a time. By default in all switch positions the udisk is not mounted on the host (the Bash Bunny itself). The /root/udisk directory will appear blank unless `udisk mount` has been executed. Writing to /root/udisk when unmounted will have no effect on the actual udisk partition. If both ATTACKMODE STORAGE and `udisk mount` are used — unexpected behavior may occur as the partition cannot be handled by both the target and host simultaneously. Formatting Considerations
The MicroSD card should be partitioned with a single partition formatted with a filesystem appropriate to the target e.g. for Windows targets: FAT32, ExFAT, NTFS e.g. for Mac targets: FAT32, ExFAT, APFS e.g. for Linux targets: FAT32, ExFAT, EXT While the target may support various filesystems, the host (Bash Bunny) currently only supports EXT and FAT32. Additional filesystems (ExFAT) may be included in future firmware versions.
Darren Kitchen's post in Trouble with WAIT_FOR_PRESENT and WAIT_FOR_NOTPRESENT was marked as the answer
I should have clarified this earlier. I've written up an article to help clear this up.
The bottom section on how it works explains the function of the extension.
Darren Kitchen's post in Pineapple, Raspberry, and More! was marked as the answer
A key component in our 6th generation plan is a companion device, currently code named the "Pineapple Core", that'll offload certain functions and add enhanced data gathering and analysis capabilities. Think of it as a database engine to an application server.
The Pi2 is formidable hardware for a Kali install and something I'm sure you could easily see some use out of when connected upstream from the WiFi Pineapple. Perhaps something like:
Internet--> AP <--> ALFA <--> Pi2 <--> NANO <--Client
Darren Kitchen's post in Client Mode on wlan2 was marked as the answer
What you're describing is a Preferred Network List - something a WiFi network manager would handle.
There's a network manager on the WiFi Pineapple in the form of /etc/config/network and /etc/config/wireless -- but since it's a router OS they are static by default.
Another way to handle this would be to have a daemon or constantly running script that starts on boot to monitor wlan2 WiFi (or possibly Internet) connectivity, and when unavailable move to the next AP in the list. This could be done by bypassing the built-in WiFi client mode manager that references /etc/config/wireless and rather interface directly with "iw".
I recommend making a feature request at wifipineapple.com/bugs -- it'll help us know what to prioritize on with the next firmware update.
Darren Kitchen's post in Nano with Stubby antenna's? (and/or dome antennas) was marked as the answer
In addition to what CulinaryOutlaw said, those FPV style antennas are RHCP or LHCP cloverleafs with circular polarization. Keep in mind most devices has liner polarized antennas (vertical, horizontal or both). It probably won't make a huge deal in the real world, but if you're noticing reduced range it can be a factor.
Also FWIW if you're only doing passive scanning from aerial platforms like a RC planes or quadcopters, it won't interfere with typical 2.4 GHz Spektrum control signals ;-)
Darren Kitchen's post in Recon Tab was marked as the answer
I hope this will provide some clarification on how Recon works:
When a Client & AP scan is initiated, the monitor interface will begin channel hopping, listening for data frames between clients and access points. It will then display the access points and clients seen, as well as their child-parent relationship. The longer the scan, the longer the monitor interface will listen on each channel. If no data is exchanged between client and AP during this time, it will not be displayed after the scan. This is why clients will seemingly drop and re-appear when running a continuous scan. Your clients may be associated with the nearby AP, but if they aren't communicating during the scan window for their specific channel, we won't see them.
While we could "remember" clients for a period of time after first seen, then fade them away after X minutes if not seen anymore, this would be based on a guess and not actual data. We prefer to show what we are 100% confident is in the air at that time. If this is requested enough, we can consider a way to implement it visually without causing issues when clients do eventually drop or become out of range. Let us know your thoughts!
Welcome to the community! Apologies for the spam bot 3-post limit, it will go away shortly now that we're 65% certain you're human. ;-)
Darren Kitchen's post in Nano endless blinking led was marked as the answer
Sorry this is happening to you man. I know how it goes when you're anxious to get it going! A factory restore should put everything back in order.
You're doing everything right except for setting the IP address.
When you hold down the RESET button while plugging the NANO into your computer, it goes into bootloader mode. From there you can recover the firmware from a web interface -- but it's at 192.168.1.1, not 172.16.42.1
You'll need to specify a static IP address in the 192.168.1.x range, like 192.168.1.2
Then navigate to http://192.168.1.1and you'll have the option to recover the firmware :)
Darren Kitchen's post in Shipping Delay for WiFi Pineapple TETRA was marked as the answer
You beat me to it -- THEY'RE HERE!!! Been busy busy busy all morning. Labels are printing, boxes are packing, and Sara is super happy to have the back-orders clearing out of the ship queue!
We're full steam ahead shipping every order and hope to have them all out today
Darren Kitchen's post in What log files does the Nano write to, and where are they stored? was marked as the answer
The PineAP log is stored in /tmp along with all of the other log files. You'll have the ability to choose a different location for this in 1.0.2
Darren Kitchen's post in Script kiddy - dhclient was marked as the answer
root@Pineapple:~# udhcpc --help BusyBox v1.23.2 (2015-08-21 19:26:26 PDT) multi-call binary. Usage: udhcpc [-fbqRB] [-t N] [-T SEC] [-A SEC/-n] [-i IFACE] [-s PROG] [-p PIDFILE] [-oC] [-r IP] [-V VENDOR] [-F NAME] [-x OPT:VAL]... [-O OPT]... -i,--interface IFACE Interface to use (default eth0) -s,--script PROG Run PROG at DHCP events (default /usr/share/udhc pc/default.script) -p,--pidfile FILE Create pidfile -B,--broadcast Request broadcast replies -t,--retries N Send up to N discover packets (default 3) -T,--timeout SEC Pause between packets (default 3) -A,--tryagain SEC Wait if lease is not obtained (default 20) -n,--now Exit if lease is not obtained -q,--quit Exit after obtaining lease -R,--release Release IP on exit -f,--foreground Run in foreground -b,--background Background if lease is not obtained -S,--syslog Log to syslog too -r,--request IP Request this IP address -o,--no-default-options Don't request any options (unless -O is given) -O,--request-option OPT Request option OPT from server (cumulative) -x OPT:VAL Include option OPT in sent packets (cumulative) Examples of string, numeric, and hex byte opts: -x hostname:bbox - option 12 -x lease:3600 - option 51 (lease time) -x 0x3d:0100BEEFC0FFEE - option 61 (client id) -F,--fqdn NAME Ask server to update DNS mapping for NAME -V,--vendorclass VENDOR Vendor identifier (default 'udhcp VERSION') -C,--clientid-none Don't send MAC as client identifier Signals: USR1 Renew lease USR2 Release lease
Darren Kitchen's post in Can't Download Modules was marked as the answer
I do apologize everyone. I made an update to the module_list file on github adding the clomac and upnp-portfwd modules. Immediately after the commit realized I had made the mistake of leaving the (') in (client's) which of course breaks the script. I made a follow-up commit removing the character however it never propagated to the gh-pages branch. After a half hour I figured it was just cached and would resolve itself but I guess not. I'm learning a lot about github's idiosyncrasies and it's a bit of a growing pain / learning curve. Making an additional commit (this time adding the ddnsc module) fixed the issue. Really sorry about that!
TL;DR: My mistake. Github is slow. It's fixed now. There are 3 new modules to check out.