wifi pineapple firmware for ar-150 http://sapinski.com/2016/02/13/wifi-pineapple-firmware-for-gl-inet-gl-ar150/
the sapinski.com link no longer works (404 Not Found), i found out a github page at GitHub - kow/glinetpineapple: Wifi Pineapple firmware for for GL.iNet GL-AR150 but the build instructions are also at that link… if u have the build instructions and want to share i would really appreciate that 
@bs0d we’re in the same boat you and I both trying to get this to work; here’s the recovered text from the original page:
The AR150 uses an AR9331 SoC, the same processor found in the WiFi Pineapple.
Without too much effort, you can install the WiFi Pineapple firmware on an AR150. The procedure goes like this:
build firmware-mod-kit from https://code.google.com/archive/p/firmware-mod-kit/wikis/Documentation.wiki
extract wifipineapple firmware (https://www.wifipineapple.com/nano) with firmware-mod-kit
clone https://github.com/domino-team/openwrt-cc
cp firmware-mod-kit/fmk/rootfs/* openwrt-cc/files/*
and finally, build openwrt-cc.
Or download the prebuilt bin from here:
https://github.com/kow/glinetpineapple
However I don’t know how this guy got this to ever work, for starters the firmware-mod-kit does not work at extracting the image. However I was able to use BinWalk to extract the SquashFS and then used the unsquashfs toolset to extract the contents of the image. However I’m not sure where to go from there.
If you try to use the images from GitHub you’ll find that a bunch of functionality is missing (like IPTables) you’ll find that its because the kernel modules failed to load. This appears to be caused by “grace” failing to load for some unknown reason. You can confirm this by performing “lsmod” from an SSH session. Furthermore any attempts to load another kernel module via “insmod” fails.
Grace is part of the kmod-fs-nfs and kmod-fs-nfs-common packages; because I have no need for these packages (they’re for network file support) I attempted to remove them via opkg with the following command
opkg remove kmod-fs-nfs kmod-fs-nfs-common
However in doing this you’ll send the router into a constant reboot loop. Hooking up to the Serial output shows that we’re getting a Kernel Panic:
[ 16.050000] PPP generic driver version 2.4.2
[ 16.060000] CPU 0 Unable to handle kernel paging request at virtual address 4
[ 16.070000] Oops[#1]:
[ 16.070000] CPU: 0 PID: 723 Comm: kmodloader Not tainted 3.18.23 #2
[ 16.070000] task: 82c5c9b0 ti: 82c58000 task.ti: 82c58000
[ 16.070000] $ 0 : 00000000 00000000 00000002 00000000
[ 16.070000] $ 4 : 00000001 00000000 00000000 0000ca04
[ 16.070000] $ 8 : 00000000 80064f50 8391ae10 72697665
[ 16.070000] $12 : 00000000 00000031 00000000 20766572
[ 16.070000] $16 : 8384c48c 8291ba00 82924d78 80360000
[ 16.070000] $20 : 0000000c 8036d128 82924df0 00000021
[ 16.070000] $24 : 00000003 8007acf0
[ 16.070000] $28 : 82c58000 82c59cf0 00000000 8022d214
[ 16.070000] Hi : 00000002
[ 16.070000] Lo : 00000000
[ 16.070000] epc : 8291e020 0x8291e020
[ 16.070000] Not tainted
[ 16.070000] ra : 8022d214 ops_init.constprop.11+0xfc/0x140
[ 16.070000] Status: 1000fc03 KERNEL EXL IE
[ 16.070000] Cause : 00800008
[ 16.070000] BadVA : 00000000
[ 16.070000] PrId : 00019374 (MIPS 24Kc)
[ 16.070000] Modules linked in: ppp_generic(+) pl2303 nf_nat_ipv4 nf_conntrach
[ 16.070000] Process kmodloader (pid: 723, threadinfo=82c58000, task=82c5c9b0)
[ 16.070000] Stack : 803dbbc8 00000006 82924d78 00000000 8384c48c 8022d214 000
803b4292 82924d78 803dbbc8 82924d78 803dbbc8 fffffff5 80360000 0000000
00000000 8022d2d8 00000000 00000000 82924df0 00000021 8291e090 82924d8
80370000 8022d3a4 8291ba80 803b0000 82924998 82c59d7c 8291e090 8292000
00000000 8291e0bc 00000000 00000001 8291ba00 0000ca04 80354c60 800f01c
...
[ 16.070000] Call Trace:
[ 16.070000] [<8291e020>] 0x8291e020
[ 16.070000]
[ 16.070000]
Code: 8c830368 10400003 24040001 <8c640000> 0082202b 00040336 24420001 000
[ 16.330000] ---[ end trace ce2e51dc5a261a1d ]---
[ 27.020000] CPU 0 Unable to handle kernel paging request at virtual address c
[ 27.030000] Oops[#2]:
[ 27.030000] CPU: 0 PID: 988 Comm: netifd Tainted: G D 3.18.23 #2
[ 27.030000] task: 82c5d360 ti: 8292a000 task.ti: 8292a000
[ 27.030000] $ 0 : 00000000 00b82eb4 00000400 00000000
[ 27.030000] $ 4 : 8298bf5c 00000000 00000000 80330000
[ 27.030000] $ 8 : 00000000 8298bf5c 00000000 00000000
[ 27.030000] $12 : 7fd97d78 8283c81c 00000000 7fd97d58
[ 27.030000] $16 : 8298bf40 8036d36c 828d9000 82d36220
[ 27.030000] $20 : 00000000 8036d128 00000000 00000000
[ 27.030000] $24 : 00000000 776d07d0
[ 27.030000] $28 : 8292a000 8292ba68 8036d128 82d1327c
[ 27.030000] Hi : 00000000
[ 27.030000] Lo : 00000038
[ 27.030000] epc : 82d132ac ip6_route_get_saddr+0x12c/0x760 [ipv6]
[ 27.030000] Tainted: G D
[ 27.030000] ra : 82d1327c ip6_route_get_saddr+0xfc/0x760 [ipv6]
[ 27.030000] Status: 1000fc03 KERNEL EXL IE
[ 27.030000] Cause : 80800008
[ 27.030000] BadVA : 00000408
[ 27.030000] PrId : 00019374 (MIPS 24Kc)
[ 27.030000] Modules linked in: ppp_generic(+) pl2303 nf_nat_ipv4 nf_conntrach
[ 27.030000] Process netifd (pid: 988, threadinfo=8292a000, task=82c5d360, tl)
[ 27.030000] Stack : fffffff8 00000000 00000008 00000000 0000000c 00000002 000
83807000 00000000 000152d0 00000003 80358630 00000000 00000000 8036d3c
82966a80 82d37eb8 82d36220 00000000 82966a00 00000200 828d9000 82d13ac
00000000 00000141 803580f0 00000000 00000000 00000000 00000018 000003c
5719b34c 00000000 00000002 00000000 00000008 82d14718 828d9240 8024ae0
...
[ 27.030000] Call Trace:
[ 27.030000] [<82d132ac>] ip6_route_get_saddr+0x12c/0x760 [ipv6]
[ 27.030000]
[ 27.030000]
Code: 8e220050 10400003 00000000 <08b44cae> 8c420008 00001021 a2020014 024
[ 27.300000] ---[ end trace ce2e51dc5a261a1e ]---
[ 27.300000] Kernel panic - not syncing: Fatal exception in interrupt
[ 27.300000] Rebooting in 3 seconds..
This looks to be related to the PPP generic driver; again since I have no use for this driver I intend to remove it; I’ll try to keep you updated on where this ends up at, but frankly its not looking good.
If you end up with a better way to rebuild firmware that’s the route I’d take, it seems like there are a ton of modules included in here that just aren’t needed.
I had similar issues with the .bin that @kow posted on github. However, I followed the instructions he provided and was able to compile a fresh image. I ran into issues with kernel modules, however, because the 1.0.6 pineapple firmware used an older kernel than the openwrt-cc source I cloned from the domino-team github; the modules I needed in the pineapple image wouldn’t load, so I had to add the modules manually with make menuconfig before building. At the end of it all, I have a working image. I added an Alfa AWUS036NEH to the USB port and I am able to do client scan and MitM. Without another radio all you can do is scan AP. If you give me a day I can have my (working) bin up on github as well.
EDIT:
https://github.com/agentsac/AR150pineapple
Let me know if it works for you or not.
@forrestrangerben the instructions @kow provided seem to work on Linux Mint only. Well actually it’s fmk that seems to work with no issues with Linux Mint. I tried Kali Liinux, Parrot OS, Ubuntu 16.04, and Linux Mint. It weirdly works without issues just with Mint.
@agentsac thanks for sharing, once i get my AR-150 i’ll let you know if your firmware works
this reaver version works or not? i’ve already tried one of the pineapple files and got usual endianess bug with reaver including other broken things like mac address inconsitency. do you guys have a working image or patch?
@agentsac Thank you I’ll try that firmware tonight; would you mind sharing your .config file (ideally on github) that you used with the domino-team openwrt-cc make file? It’d be the easiest way to see what modules were required.
EDIT: On the surface it seemed to work, however I was unable to get some of the injections working; like RandomRoll and I was unable to get PineAP to turn on to capture probe requests, I’ll take a look more into it this weekend.
No worries. I pushed the .config to GitHub. I will admit, however, that I have no clue what I am doing - just messing around. How I managed to compile a working .bin is beyond me. If something doesn’t work I will try to help, but I’m not sure how much help I will be. The only advice I can give is if/when you do the upgrade that you make sure not to keep configuration files as I did that without thinking the first time I flashed it. As stated earlier, most Pineapple NANO features won’t work without another radio, so you will need something like an ALFA card for that. I only added the kernel modules for the one I’m using (I think), so if you aren’t using the chipset that I am (AWUS036NEH - rt2800usb) you will have to include the modules needed for your build. Good luck!
Hey Sorry I didn’t see your post and had edited my original one:
On the surface it seemed to work, however I was unable to get some of the injections working; like RandomRoll and I was unable to get PineAP to turn on to capture probe requests, I’ll take a look more into it this weekend.
I’m just hacking around here too; to be honest I’ll eventually pick up a Pineapple probably, but I’m using this as an excuse to learn more about OpenWRT and Linux in general.
Sorry to hear that @forestrangerben. I haven’t tried any of the modules, because the default for the Wifi Pineapple NANO is to install them on an SD card, of which there is none on the AR-150. I’m sure I can find a way to install on flash, but I haven’t gotten there yet. The Pine AP, however, I was able to use successfully. I just confirmed this a few minutes ago. I was able to scan for APs and clients and deauth a client and get it to associate to me. I was also able to log probe requests, as well as automatically add them to my pool. Assuming we are using the same firmware and AR-150, the only other thing I can think is are you using the same Alfa wireless dongle as me?
I do have a Wifi Pineapple NANO and TETRA, but like you I used this as an opportunity to learn more about OpenWRT and make something cool at the same time. I like the Pineapples for their ease of use, but they are not always the best tool for the job.
Hey guys,
I am bothering because you are the last resource before destroying my ZSUN due to anger 
The initial idea was to port hostapd-mana to openwrt and susbtitute the original hostapd within the ZSUN in order to use it also for pentesting 802.1x networks during engagements at work… sadly I got stopped due to diffing/merging issues while porting hostapd-mana to its OpenWRT version.
However, googling aroung I have figured out that one guy managed to modify the Wifi Pineapple Nano (same Atheros SoC of our ZSUN) to push it in another AP:
http://sapinski.com/2016/02/<wbr />13/wifi-pineapple-firmware-<wbr />for-gl-inet-gl-ar150/
https://github.com/kow/<wbr />glinetpineapple
And this guy did the same:
https://github.com/smrx86/<wbr />STPF2
I was wondering if you could give a look at the procedure to patch the Pineapple Nano original fw.
I was following the guide in the URL above…
- build firmware-mod-kit from https://code.google.com/<wbr />archive/p/firmware-mod-kit/<wbr />wikis/Documentation.wiki
- extract wifipineapple firmware (https://www.wifipineapple.<wbr />com/nano) with firmware-mod-kit
- clone https://github.com/domino-<wbr />team/openwrt-cc
- cp firmware-mod-kit/fmk/rootfs/* openwrt-cc/files/*
- and finally, build openwrt-cc.
Would be really nice if you could experiment as well, since you are much more skilled in the ZSUN than me.
Pushing the Wifi Pineapple fw into ZSUN will make MANY people really happy!