Jump to content

[Support] Connect: A client mode WiFi manager script


SymPak
 Share

Recommended Posts

Connect

Version 1.1

Features

Connects to networks with the strongest signal

Save preferred networks with -W option (Open and password protected)

Add commands to be run by the pineapple after the script completes.

Upon successful connection, failed connection or both run specified commands

Macchanger support

Upon connection, start karma (PineAP not yet supported)

Prevent connection to certain access points with blacklists

Check Internet connection status with -s

Monitor internet connection status with -m and specify how many failed attempts to retry. 0 = infinite

Auto retry tries to connect to an access point if the connection fails. Use -a and specify the retry amount

Internet connection monitoring pings 8.8.8.8 a few times every 30 seconds. After 5 successful ping attempts, connection testing occurs every 5 minutes. After 3 more successful ping attempts, connection testing occurs every 10 minutes. If pings fail the access point is disconnected, temporarily blacklisted and a new access point is located. After 3 failed attempts to connect to a new access point, the temporary blacklist is removed and the pineapple reconnects to the original access point. Note: Only open access points and whitelisted access points work with internet connection monitoring.

Commands can now be added therough the infusion. Use -C to add commands. Script variables can also be passed to commands to be run.

Possible variables that can be passed: "$ESSID" "$PASSWORD" "$PWD" "$WIFI_BSSID" "$WIFI_CHANNEL" "$WIFI_INT"

To add an access point to the whitelist after a successful connection use: pineapple infusion connect -w "$ESSID" -p "$PASSWORD"

Usage

pineapple infusion connect [-BRWckrs] [-i Interface] [-e ESSID] [-p Password] [-t Interface] [-b SSID] [-w SSID]...

OPTIONS:
-B Backup /etc/config/wireless
-C Add commands to be run upon successful, failed or all connections
-R Restore /etc/config/wireless from backup
-W Checks for and connects to networks specified in the whitelist
-c Run commands specified in commands.txt upon successful connection
-k Start Karma
-r Random MAC
-s Check internet connection status.
-a num Auto retry. Specify how many failed attempts to try to connect
-e essid ESSID of target wifi
-i iface Interface. Default wlan1
-m num Monitor connection and reconnect. Specify how many failed attempts to retry. 0=infinite
-p pass Wifi Password
-t iface To interface for ICS. From interface is specified with -i
-b essid Blacklists AP by SSID. Scans with first available interface if no interface is specified
-w essid Whitelists AP by SSID. Prompts for password when required. Password can also be set with -p

Future plans

Disconnect from access point

Bug fixes and general optimizations

Connection monitoring with -e

If you encounter any errors please report them here. Also feature requests or improvement suggestions are always welcome!

If you would like to use parts of this script for a script or infusion of your own, contact me by a PM.

-SymPak

Edited by SymPak
Link to comment
Share on other sites

  • 4 months later...

From what little info there is about this infusion, it sounds fantastic.

I do have a question or two:

1. If this is the case, "-w Whitelists AP by SSID. Prompts for password when required", then why "-W Checks for and connects to networks specified in the whitelist. Unencrypted netowrks only"? If the AP is whitelisted with password/crypto, why can't it be used with it? Or can it?

2. Could this, by chance, be easily daemonized, to run in a loop, -s every 30 seconds (check for net), and if not connected, immediately -W, otherwise sleep 30 and -s again? Or would this need to be scripted externally?

Link to comment
Share on other sites

Thank you for pointing that out. Whitelists do work with passwords. I forgot to remove that once I got the passwords working. Early versions for the MKIV did not work with passwords.

I could implement a loop to search for networks. It would be a startup option with a retry value. 0 would be an infinite loop until it connects. To run the script in the background "&" would need to be used

Link to comment
Share on other sites

That'd be great! Kinda' like the old autoap scripts for openwrt, we'd just have to whitelist all approved AP's as we came upon them, and let 'er rip!

I live full-time in a camper, and move about quite a bit, so this would be of great benefit to me, but I'm sure that others could benefit from it as well!

Link to comment
Share on other sites

Here's a script I found, that I thought might be somewhat easily used in conjunction with your infusion:

https://forums.hak5.org/index.php?/topic/34276-script-client-mode-wifi-check/

Here is my semi-educated idea of how it worx:

1. script pings 8.8.8.8, if good, sleeps till next run. Or,

2. pings $gateway next, if good, tells you to check house AP's WAN connection. Or,

3. checks for existence of the interface it believes it should see, and if not present, reboots pineapple.

And here is how I envision it used here:

1. Script or infusion runs, somehow AUTO-determines appropriate $interface and $gateway (seems connect already does this?), pings 8.8.8.8 (or any other public IP), if good, sleeps until next run. Or,

2. pings $gateway, if good, tells you to check house AP's WAN. Or,

3. checks for existence of the interface, and if available, runs "pineapple infusion connect -W", auto-determines $interface and $gateway. Or,

4. Asks if another $interface should be used, or maybe even switches on own to first (or maybe last) available, and starts over.

I've VERY seldom seen any need to reboot the pineapple for interface detection, but we might need to keep a step 5 for worst-case reboot.

I'm interested to know what you think of this! I'm gonna put some of these suggestions in the script's original thread as well.

edit: Realized, after reading further, that Connect already does a full and complete auto-detection and connection checking routine! This tells me that if we can daemonize, maybe just add an option to momentarily reject currently connected AP if it shows local access only? That way, it keeps associating and checking until it finds one with valid net? Not always appropriate, of course, but in my case most often so.

Edited by patriotek
Link to comment
Share on other sites

Question:

Can ESSIDs be listed white/black instead of BSSIDs? I've whitelisted a few APs, and they all get listed by MAC/BSSID with no reference made to the ESSID.

I'm wondering if, in the listing process, the ESSID could at least be shown as a comment for user reference. As well, if and ESSID could be utilized in situations where a single network has multiple APs to roam between, or open hotspots at chain stores where BSSID changes but ESSID remains same...

Link to comment
Share on other sites

The point of using a MAC address is that it never changes. ESSIDs can change whenever someone wants the network to broadcast under a different name.

Forgive me, but that was not my question. I know why, what I asked was could it be made either optional (give user the choice), or if it's capable already by manual editing of the white/blacklists.

Link to comment
Share on other sites

I am still working on the retry feature. I am basically calling the script again within itself and once I get that working I will simplify my function calls. Then I can work on a daemon function. Adding the ESSID into the blacklist and whitelist shouldn't be a problem. Ill look into adding that to my next release. It also technically uses the ESSID for connection so that wouldn't be a big deal to look into either. Ive also got my commands feature figured out. You can add commands through the script and can run them if the connection is successful, if it fails or both. Hopefully I will have something ready in a couple days.

-SymPak

Link to comment
Share on other sites

Status update! Working on implementing the retry feature is proving to be more difficult than I had originally anticipated. I have also added the essid to the whitelist and blacklist files. Last, the commands feature. You will be able to pass variables from the script into your commands. So if the connection is successful you could say run 'pineapple infusion connect -w "$ESSID"' and have that access point added to the whitelist after the fact.

More to come

-SymPak

Link to comment
Share on other sites

  • 4 weeks later...

Update submitted and awaiting approval! Approved!

This update brings internet connection monitoring, auto rerty reconnection, commands to be run depending on connection status, adding commands through the infusion, monitor interface support and general improvements. See original post for more details.

-SymPak

Edited by SymPak
Link to comment
Share on other sites

The reason I ask if it could be added in a release ( while I do see you have an AP_MAC variable, so I assume it will be used for such ) is there are multiple ap's with the same essid, and I need to connect to a certaon node, and a certain one with the certain BSSID. while its not an inconvenience for me personally to just add the option bssid 'examplemacaddress' my self, it will help others I'm sure. but at the current state, its very troublesome

to connect to the certain one, if there are multiple of same essid with no bssid rule to follow often will not connect to the one needed or even at all

Link to comment
Share on other sites

The feature is there I just had trouble getting it to work. I can look into it tomorrow. In the meantime I think you can use -M (might be -m I can't remember what monitor uses) to specify the bssid.

Link to comment
Share on other sites

Yeah it can cause some quirky things to happen. And it probably because of a few things. If the essid option is there, I get rid of it, so it only searches for bssid. Sometimes option bssid favors the card in wds mode. But wds mode can be a headache aswel. And then I've also seen option macaddr get put into the mix, and that line causes issues for option bssid as well

Edited by DataHead
Link to comment
Share on other sites

So after looking into it a little I have found that using -M <BSSID> with -e <ESSID> should work as you would like. The problems start when encryption details differ. For instance my lab setup had two routers one with WPA2 and the other with WPA and both had the same ESSID and password. The infusion searches for ESSID only and configured /etc/config/wireless with the wrong configuration. After changing both routers to WPA I was able to selectively connect using the BSSID. I will include BSSID searching and configuration in the next version. However it is likely that for your setup there shouldn't be a problem. You do need to specify the ESSID when using BSSID.

On a side note I have updated the original post with details about the new version.

-SymPak

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...