The Speedport Entry 2 is an entry level modem/router produced by "Deutsche Telekom".
This device is quite bad and its performances tend to degrade over time.

The most common solution to this problem is made of several steps:

• Stand up
• Reach the Speedport Entry 2
• Pull the plug
• Wait few seconds
• Plug it back again
• Get back to what we were doing

Although this solution proved to be quite effective, it turned out to be also quite annoying.
For this reason, the "Fickport" project was born :)

There are different ways to use the Fickport tools.
The next paragraphs describe the possible uses.

The simplest way to use the Fickport tools is to manually run the fickport.sh bash script, everytime we start noticing the first signs of slowness in the network. It's important to specify the correct device password for our Speedport router in the script, so that it will be able to succesfully login and reboot our beloved router.

Unfortunately, this solution can be used only before the network becomes so slow to be actually unusable. In this case, only 2 possibilities are left:

• Stand up and follow the "most common solution" steps written above
• Ask someone to perform the "most common solution" steps above

The real (dirty) solution would be preventing the performance degradation by daily rebooting the router.

If in your network there's an always alive and connected linux device, you could use it to periodically run the fickport.sh script and automatically reboot the router.

In my real scenario, a "Fritz!WLAN Repeater" is always connected to the local network, so I decided to use it to run the "fickport.sh" rebooting script.

Have a look at the fritz-image sub-folder files to learn more about it

Wanna know more about techy stuff behind this project?
Read further!

Have I already said that the Speedport Entry 2 is a shitty router?
Let's talk about how it is working under the hood.

In this paragraph we describe the login logic behind the Speedport Entry 2 web interface.

The following Javascript code is a slightly simplified version of the real one used on the speedport:

function hash(devpwd, challenge){
 var hash_pwd = devpwd+challenge;
 var password = sjcl.codec.hex.fromBits(sjcl.hash.sha256.hash(hash_pwd));
 return password;
}

so the typed in device password is:

• concatenated with a challenge value generated by the server (obtained through a XmlHttpRequest)
• this combination is then hashed (sha256)
• sent to the server as HTTP POST request.

The POST request is similar to this one:

wget --save-cookies cookies.txt \
     --keep-session-cookies \
     --post-data "password=${hashpwd}&showpw=0&csrf_token=sercomm_csrf_token" \
     --delete-after \
     "http://${speedport}/data/Login.json?lang=en"

To perform any further operation, the speedport requires a "CSRF token" to be passed together with the HTTP request to prove that the request actually came from the Speedport Web interface.
This token is stored directly in the "index.html" page source served by the speedport and is generated everytime the "index.html" is requested by a client.

Badly enough, only the last generated CSRF token is considered valid by the server.

It means that if we continuosly request the "index.html" to the server, we would easily cause a Denial of Service, making any login attempted by any user fail, even with the proper password.

The CSRF token is programmatically extractable in this way:

csrftoken=$(wget --load-cookies cookies.txt -q -O - "http://${speedport}/html/content/overview/index.html?lang=en" | grep "var csrf_token " | cut -d "'" -f 2)

With this token we are now able to programmatically reproduce any action available on the web UI, otherwise only manually triggerable.

In our specific use case, we need to request a "reboot" action.
The HTTP call to perform a reboot is the following one:

wget --load-cookies cookies.txt \
     --post-data "reboot_device=true&csrf_token=${csrftoken}" \
     --delete-after \
     "http://${speedport}/data/Reboot.json?_time=1511727315027&_rand=666&csrf_token=${csrftoken}&lang=en"

Read the content of fickport.sh to know more about the HTTP calls used to execute commands on the Speedport device.