_bugs_

Correct, that infusion updates the DNS server that is used by your Pineapple. It does it in 3x places (/etc/resolv.conf, dnsmasq and dhcp) so it also updates the DNS server that will be provided to your DHCP clients. It is useful if you have a different DNS server running dnsspoof (i.e.: on your laptop or somewhere else) and also in situations where only specific DNS servers are allowed by the surrounding network (i.e.: OPENDNS). Cheers, Bugs.

Version 1.2 is now available from the Pineapple bar.

Yes I think it has been taken down until I submit the newer version, which I just did, so it is waiting for review. Unless I screwed up something it should be up shortly! I will put something here when I receive the confirmation.

Submitted version 1.2: - Forgot to update the internal version of the infusion - Updated the info displayed in the large tile to explain how to reset to default DNS settings. Cheers, Bugs.

There was a problem with the directory structure of version 1.0, there is now a new version available which fixes the install problem. Version 1.1 - Updated file structure, so it can now install from the Pineapple bar! - Cleaned the HTML code a bit - Added a Changelog I might add another option to revert back to default settings if anyone request it, in the mean time you just need to update your DNS with 172.16.42.1 to get back to what it was. The reason you might want to do that is if you use something like the DNS Spoof infusion, if you specify a different DNS server (i.e.: OpenDNS) then DNSspoof will not work as it uses the Pineapple as a DNS server to change domain names' resolution. Bugs.

Hi, I created a new infusion a months ago and I am just wondering if there is a process to submit it, in case it can interest others? The infusion is very simple and automates the process of changing the DNS entry used by the Pineapple in 3 places: /etc/resolv.conf, dnsmasq.conf and dhcp. I created this infusion because I once encountered a network where they were only allowing OpenDNS as a DNS server. With this infusion I can quickly change the DNS server to be used by the Pineapple as well as the dhcp clients connecting to the Pineapple. It is a very simple script, my first for Pineapple so hopefully it isn't too ugly! :) I started by looking at the Network infusion to build that one. [EDIT] I have now submitted the infusion through the right process and it should be available from the Pineapple Bar. Cheers, Bugs.

Hi again, In case people want the files I used, here is a fairly simple version: https://app.box.com/s/1haizi1c5lfvcjl24krdhkrvnj21kta9 There is a README file explaining what to do: copy the files/directory from that archive to your pineapple. 1.sd card copy all the content of sdcard_files/ to /sd/web/ ln -s /sd/web/* /www/ 2.copy nodog/ in /tmp/ 3./etc/nodogsplash/htdocs/ replace the splash.html with the /tmp/nodog/splash.html 4./etc/nodogsplash/nodogsplash.conf redirectURL to http://172.16.42.1/myevilpage.html to force user to the "improved" splash/auth page in /www of the pineapple 5.Go! Enable nodogsplash from the web gui, set it to autostart, check the /sd/web/auth.log from time to time :) Bugs.

Hi All, It is an old thread but in case some people still have a problem making it work, this is what I have done to get the nodogsplash working. 0. The original splash page You can edit that orginal splash page in the Web Gui or in /etc/nodogsplash/htdocs You can make it look like a specific ISP if you want or, my preference, just a generic one. This page will be the Splash page, telling the customer they are about to enter a free wifi zone. Any images needs to be referenced by $imagesdir/filename.png and $imagesdir = /etc/nodogsplash/htdocs/images/ My experience, is that for nodogsplash to block the customer/client, make it click on something (link or the dog picture), and THEN allow it to access the internet, that link must retain the "$authtarget" variable. I tried to get the user_login.php to load directly from the /etc/nodogsplash/htdocs/splash.html but that did not work... So instead, I kept the original splash page and made it look more "professional"/legit. The problem is that after the client clicks on the splash page links it then gets to the page he/she wanted to go... without being prompted for his credentials. This is where the next steps comes in. 0 Edit the nodogsplash config file in the Web GUI or in an SSH session: /etc/nodogsplash/nodogsplash.conf redirectURL to http://172.16.42.1/myevilpage.html to force user to the "improved" splash/auth page in /www directory of the pineapple it means the original splash page still has the "$authtarget" reference, but the client does not get redirected to his/her original page, instead they now get a page asking them to authenticate them. You can model that page on the example given in the first post. Or you can build a very simple HTML page with a form asking for username and password. Create a logo with the ISP you are targeting, or let them choose what mobile network they want to use from a drop down list! :) Call the user_login.php script when then submit the form Et voila... their credentials will be saved in /www/auth.log The remaining problem is what do you do after they submited their credentials? Go to the next step 3. Create a succes page. The problem is that I couldn't get $authtarget to work outside of the original splash.html page. I don't think that "variable" gets propagated through the linked pages, so I had to settle with a generic success page. Just created a success.html page stating that they now have access to the internet and call it from the last user_login.php script. (if you are using several, i.e. 2x as per the original example). 4.Go! Enable nodogsplash from the web gui, set it to autostart, check the /www/auth.log from time to time :) So it is not perfect, and it does feel a bit like a work around... There is probably other options in nodogsplash so you can run user_login.php directly from the /etc/nodogsplash/htdocs and directly referenced from splash.html There is also probably a way to pass on the $authtarget to the different web page you are calling. But that's a way to make it work... quick and dirty :) Hope it helps some of you.

Hi BeNe, I can now clean my SSID but it only works if PineAP is enabled. Have you tried rebooting your Pineapple without the WLAN2 connected? If I set up WLAN2 and power off, remove WLAN2, power on, then the WLAN2 settings are somehow pushed to WLAN0. I tried setting my Internet connection with WLAN1, but as soon as I start PineAP+Beacon, this interface is disconnected. I coudln't see an option to change which interface PineAP uses to harvest and sends beacon, would be nice to be able to change it from the Web GUI. For the Recon mode, I still don't see much associated clients although there are plenty of computer connected to a WIFI network around my pineapple. Cheers, Bugs.

Hi, Thanks for this new release! Not sure if I have found bugs or if I am doing something wrong: (I am on the latest firmware version and updated all my infusions). 1. Clear SSID for PineApp This does not work for me, I click on the clearSSID and nothing happens, the list of managed SSID are still there. 2. Using an extra WIFI dongle to connect to the internet. I only tried that once I upgraded to the latest firmware, so cannot say this was broken or not before. Setup: MarkV + Battery + USB Alpha WIFI This creates Wlan2. Wlan0 broadcast my pineapple hostpot (i.e.:PineWIFI) Wlan1 is disabled so it can be used by beacon/harvester Wlan2 ... I wanted to use that to associate to a wireless network and thus not having to connect to Pineapple to my laptop. (i.e.: StarbuksWIFI) I can configure Wlan2 fine in the Network -> Client mode. Everything works and everyone is happy... until you reboot the device! Regardless if the USB Wifi dongle is connected or not when you reboot teh device, the settings for Wlan2 seems to be assigned to Wlan0 after reboot. What I mean is that Wlan0 now broadcast StarbucksWIFI and not PineWIFI anymore. Trying to fix it is also a nightmare as the interface then get unresponsive (even after several rebooting and regardless if you try to change the WIFI settings from Network or Wifi Manager), in the end I had to reset the WIFI settings to factory default (from the network tab... infusion?) I am just wondering if it is because the MarkV upon reboot does not see Wlan2 straight away and then transfer its settings to an existing interface (i.e.: wlan0). One thing I haven't tried is to have the following setup: wlan0: Pinewifi wlan1: starbukswifi setup wlan2: leave as disable for beacon/harvester. Maybe that would work better. But then again, maybe I am not doing something right! Oh, and the first few times I have nodogsplash enabled, but then disabled its autostart and it didn't seem to make any difference. 3. DeAuth in Recon Mode Might not be a bug... but the mac address of one of my laptop which was definitely connected to an AP (not the Pineapple) was still listed as "not associated". Even if I was using the laptop to browse the internet. I guess recon mode cannot see all association and needs to see some specific type of packets? (i.e.: during WIFI association). Cheers, Bugs.