falkecarlsen / chwifi Goto Github PK

At time of writing, only [a-z]+[0-9]+[a-z]+ is matched as a passphrase. This should be user-configurable and as such set in config.

When not connected to any network, the script will nevertheless disconnect from the opposite network, e.g., disconnects from home if work is given.

This should be fixed, to reduce inadvertently locking up execution.

A partial API documentation has been provided by @jenrik: https://gist.github.com/jenrik/663af358468b28c50c745e529bf3d926.

This could be an interesting development.

Some commands used in chwifi may no be guarranteed to be on every installation. A check for these and rework if found should be done.

Turns out that any passwords with $ in are not escaped and result in a variable lookup.

Provided regression test for cashandler.sh and passwordhandler.sh to cover the case that https://wifipassword.aau.dk/oneday changes layout

Simple aliases that enhances the show command:

• chwifi show today should be equivalent to chwifi show 0
• chwifi show tomorrow should be equivalent to chwifi show 1

At line 52: printf '%s\n' "$network_manager_location$1 $2", probably from implementing internal sudo.

Currently, macchanger is always run when calling connection_routine, this functionality should be enabled by a flag and prompted for during setup

If fetching fails due to credentials, page not set up as expected, or otherwise, including success, a good status should be printed to user.

Randomize the interface mac address to avoid having you network traffic tied to you through it

Some users might not want their machine to do a DHCP handshake on their home-network each time they connect at home.

Selectively choosing to change MAC on profile and reapplying the specific MAC-address for a given profile should be supported. This requires yet more bookkeeping and is probably bound to be a bloated feature.

Get a feel for the difficulties in writing chwifi in Python or similar PL.

As seen during #29 there is no handling for an erroneous CAS site, there should exist some functionality to correctly handle this case. If chwifi is to work with other services, this cannot be very sensitive to the content of the page.

Return codes for each redirect could be a good minimally-working implementation.

This would disallow connecting to home with no-args but improve usability for inexperienced users.

Some users may have different adapter device names or profile naming schemes. This should be supported

Argument parsing currently simply uses imperative and nested if-statements - this is somewhat ad-hoc and unwanted. getops may very well be a solution.

• show can no longer take no arguments
• Run output does not mention config existence anymore
• Updated help-message

Could be similar to this approach, but probably not as heavy https://github.com/lfkdev/bashtemplate

When attempting to connect to a network that is in any way unavailable, chwifi will proceed to wait for a network connection. This will obviously continue until the process is killed. A sample run of this error is shown below.

[user@hostname ~]$ chwifi profile
Connecting to profile
Stopping all profiles
New MAC-address: 08:11:96:46:30:b1
Connecting to profile: profile
Job for [email protected] failed because the control process exited with error code.
See "systemctl status "[email protected]"" and "journalctl -xe" for details.
Waiting for network connection...
^C

With #33, it is possible to connect to any netctl profile using the argument [-p|profile]. Implementing an array as a case would allow the parser to check for any netctl profile, and render the aforementioned argument obsolete, and would allow any profile to conform to the chwifi <PROFILE> syntax. Additionally, the home profile could be merged into the other profiles, as the routine for these are identical.

Might just be a temporary bug or seasonal, as summer break is in effect.

chwifi throws this error but correctly identifies the update as failed:

/tmp/chwifi-passwords.html:6: HTML parser error : Unexpected end tag : meta
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"></meta>
                                                                              ^
XPath set is empty
Failed to update cached passwords!

AAU OneDay throws this 500 error upon logging in:

500 Internal Server Error

The server encountered an unexpected condition which prevented it from fulfilling the request.

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/cherrypy/_cprequest.py", line 670, in respond
    response.body = self.handler()
  File "/usr/lib/python3/dist-packages/cherrypy/lib/encoding.py", line 217, in __call__
    self.body = self.oldhandler(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/cherrypy/_cpdispatch.py", line 61, in __call__
    return self.callable(*self.args, **self.kwargs)
  File "/srv/web/AauWifi/aauwifi/lib/fast/cas/cas.py", line 64, in wrapper
    return func(*args, **kwargs)
  File "/srv/web/AauWifi/aauwifi/aauwifi.py", line 177, in oneday
    db = fast.db3.FastDB(psycopg2.connect(**cherrypy.config['dbinfo']))
  File "/usr/lib/python3/dist-packages/psycopg2/__init__.py", line 164, in connect
    conn = _connect(dsn, connection_factory=connection_factory, async=async)
psycopg2.OperationalError: could not connect to server: Connection refused
	Is the server running on host "db1.adm.es.aau.dk" (130.225.51.117) and accepting
	TCP/IP connections on port 5432?

Powered by CherryPy 3.5.0 

This should probably be handled better, somehow identifying whether the site is functioning properly instead of failing on unexpected input.

Restarting connection is currently not supported and it is required to use netctl. Restart opts e.g. chwifi -r home | work, or simply chwifi -r with automatic detection of active profile could be a solution.

Since e75633d installations can have differing configs which may break functionality. Versioning should therefore be implemented, such that setup can be forced, if it is found that an existing user-config does not match the version of the script.

Python could be a contender for quick prototyping and good learning opportunities

Other profiles should be supported. This could be implemented by preloading an array during setup.sh with local profiles in /etc/netctl and update it if needed during each run.

• Requires sudo
• Requires changes to parser to accept dynamic input
• Dispatch needs to differentiate on connect. Could be done by catch-all for all except work

Often, switching networks is a part of a transition when using a portable machine. There should be a way to execute external scripts on network changes.

E.g., when connecting to home, call a monitor-script to configure displays for home setup.

bc is not listed as a dependency in PKGBUILD, which renders connection-time calculation broken.

The current parser does not allow for no argument to the show-command. This requires a lookahead of 1 and may need some major rework.

As I've switched to Fedora, I now use networkmanager and therefore nmcli for configuring both wired and wireless network connections.

This should TM be fairly straightforward as it seems that the netctl actions currently used can be straightforwardly be mapped. However, some functions should be guarded for compatibility reasons, e.g., reading profiles from /etc/netctl/ as this only applies to netctl-systems.

The mapping could look like this:
sudo netctl start $profile -> nmcli con up $profile
sudo netctl stop $profile -> nmcli con down $profile
sudo netctl stop-all -> ?
sudo netctl restart $profile -> ?
However, profile-creation and connection is possible as a one-liner under nmcli
? -> nmcli device wifi connect $SSID password $password - this seems to update an existing SSID's password as well, being another way to trigger a daily-password update on an SSID.

Note, $profile for nmcli can be either SSID or UUID, which could be pretty nifty.

The update at e75633d, allowing toggling macchanger disables macchanger if using config from before update during connection routine as it checks for an empty variable, and as such does not execute a MAC change although it is default in previous versions.

This is minor but underlines the need for #27 or similar solution.

Both KDE and Gnome has a keyring for storing secret such wifi passwords, and mail credentials. I propose adding a option for store credentials in the keyring. This will solve the problem of having to store username and password in a clear text file.

Rather than having no-args mean 'connect to home', as per issue #3, syntax should be generalised.

This should take the form of: ./chwifi ssid passphrase?, where a question-mark signifies optionality.

Currently, the script has the main functionality of handling a use-case of a user primarily using two wireless networks, which is not very extensible. Implementing this syntax allows connecting to arbitrary networks, both networks that are already configured and unknown networks.

This would result in the script becoming a CLI-wrapper for network managers with the enhanced feature of auto-caching passwords for rolling password networks.