TorBox v.0.4.0 released — welcome TorBox Wireless Manager!

In the last months, we travelled around, and with this release, we tried to implement some improvements based on our experience with the daily application of the TorBox. The most significant improvement is abolishing wicd and introducing our new TorBox Wireless Manager (TWM). Not only is the TWM much easier to use, but it also doesn’t need so much power. Another pleasant novelty is the support of Azur-Meek and Snowflake, which should also work in China. During our travels, we have noticed incorrect DNS resolution regarding torproject.org in some countries. Probably, this is a kind of cheap censorship mechanism. For this reason, during the installation and updates, local DNS resolutions are made through Google’s and Cloudflare’s Domain Name Servers instead of using the Internet Providers presetting delivered by DHCPImportant: these settings are only for TorBox local traffic; all data from the clients are routed through Tor (including DNS requests). Nevertheless, some user complained about using Google’s and Cloudflare’s DNS servers and requested to implement other DNS servers. In the FAQ, we explain our decision in detail and how someone, who cannot live with it, has the possibility to change these settings.

Over the following weeks, we will update the TorBox website to reflect all the changes introduced with TorBox v.0.4.0. Until then, some information could be outdated and refer to the older version.

TorBox Image (about 1 GB): v.0.4.0 (10.04.2021) – SHA-256 values
TorBox Menu only: v.0.4.0 (10.04.2021) – SHA-256 values

We strongly recommend using the new image rather than updating an existing system. 

The new TorBox Wireless Manager, which replaces wicd.

• • •

Changelog:v.0.3.2 (24.08.2020) –> v.0.4.0 (10.04.2021)
  • Update: The system is based on Raspberry Pi OS “Buster” Lite with a Linux Kernel 5.10.17 and Tor version 0.4.5.7. The Tor Project fixed in this latest version two critical denial-of-service bugs: TROVE-2021-001 and TROVE-2021-002, of which only the first one is relevant for clients.
  • New: wicd has been replaced by the TorBox Wireless Manager (TWM). We like to hear your feedback.
  • New: Support for Meek-Azure and Snowflake implemented, which should also work in China. Meek uses a technique called “domain fronting” to send a message to a Tor relay in a way that is hard to block. Meek-Azure makes it look like you are browsing to Microsoft’s Azure server  instead of using Tor. Snowflake is an improvement upon Flashproxy. It sends your traffic through WebRTC, a peer-to-peer protocol with built-in NAT punching. However, because Meek-Azure and Snowflake are slower, OBFS4 bridges should be used first. If not needed, the best is not to use bridges in the first place. Please, tell us about your experiences with the use of bridges to circumvent censorship.
  • New: Based on several user requests, the configuration sub-menu (entry 11) comprises now an option to block all HTTP plain text traffic through Tor. This should avoid unencrypted data traffic at the Exit Node, which could break your anonymity (see here). However, it is possible that not only http-requests but also other tools, such as VPN clients, will no longer work. Where possible, we recommend installing HTTPS Everywhere in the Browser. We like to hear your feedback on your experiences about that feature so that we can decide if we should block all HTTP plain text traffic by default, starting with one of the next releases.
  • New: Based on several user requests, TorBox can be configured to be accessed with SSH from the Internet.
  • New: Based on several user requests, support for additional network driver were added: Realtek 8188eu, 8188fu, 8192eu, 8812au, 8814au, 8821au, 8821cu, and 8822bu.
  • New: It is now possible to connect/disconnect the TorBox from a VPN using the countermeasure sub-menu without changing Tor’s primary interface to the Internet. With this feature, the user can influence the route of the local network data from the command line and, for example, circumvent censorship measures that don’t allow updating TorBox. Additionally, it gives the possibility to completely disconnect the TorBox from a VPN after finishing using main menu entry 9, which enables TorBox to use route Tor over VPN (for more information about Tor over VPN / VPN over Tor, see here).
  • New: In the main menu, in the top of the right corner, a message shows not only if Tor is working (meaning https://check.torproject.org returns a positive result), but also if the TorBox is connected to a VPN (meaning that local network data from the command prompt is routed through VPN).
  • New: Installation script for Debian 10 (Buster) and Debian 11 (Bullseye) – for more information, see here.
  • Fixed: The user “torbox” was not a member of the group “netdev”, which causes a display error in the entry 1 and 3 in the update and reset sub-menu.
  • Fixed: During the installation of TorBox with the installation script, Tor will be compiled because the the Tor Project doesn’t provide a binary version for the Raspberry Pi. We had this option before in the update and reset sub-menu but not in the installation script, which leads to missing tor packages.
  • Fixed: Fixed the download path for the TorBox menu in the installation as well as in the update and reset sub-menu. We also changed the GitHub download path for the Raspberry Pi Framebuffer Copy needed for AdAfruits Pi TFT installation. GitHub is suddenly changing URLs, which is a pain in the ass.
  • Fixed: Missing path to torbox.lib in some scripts, which use Bridges and prevented Tor from restarting automatically.
  • Fixed: Wrong  menu entry relating to the countermeasure against a disconnection when idle after a restart.
  • Improved: During the installation and updates, local DNS resolutions are made through Google’s and Cloudflare’s Domain Name Servers to avoid cheap censorship mechanism. Important: these settings are only for TorBox local traffic; all data from the clients are routed through Tor (including DNS requests). For more information and an explanation of how it is possible to change it, see here.
  • Improved: The support for Sixfab Shields/HATs for cellular connections can now be installed offline.
  • Improved: The script to install the Adafruit PI TFT is now locally stored and not fetched from the Adafruit Github Repository (Adafruit changed it, and it was broken). However, an Internet connection is still necessary for the installation.
  • Improved: The support for installing TorBox on a Ubuntu 20.04 / 20.10 or Debian Buster/Bullseye system. TorBox’s implementation on other systems and hardware is experimental because we do not have the resources to check all details on all different installations. You can help us with reporting errors back to us.
  • Improved: Cleaned up the code and outsourced more essential functions into the TorBox library or separate sub-scripts. This will help to maintain the code in future releases properly.
  • Improved: The appearance of all menus has been streamlined, and in the files, we fixed some minor errors.
The Countermeasure sub-menu of TorBox v.0.4.0.
The countermeasure sub-menu of TorBox v.0.4.0 with Snowflake and Meek-Azure.

• • •

Known problems and bugs
  • LIMITATION: If HTTP plain text traffic is blocked (configuration sub-menu entry 11), .onion addresses, which use “http://”doesn’t work anymore directly with Chrome and Chromium. Both browsers will behave like all other browsers by default, because based on IETF RFC 7686, applications that do not implement the Tor protocol generate an error upon the use of .onion and do not perform a DNS lookup. However, .onion addresses using “http://” can be used through SOCKS 5 even if the HTTP plain text traffic is blocked. Onion addresses using “http://” can also be used with the Tor Browser – with or without its own Tor instance – running on a client. 🙂 In other words, blocking HTTP plain text traffic does not work if SOCKS 5 proxy functionality or Tor Browser is used on a client. 🙁 WARNING MESSAGE ADDED✔︎
    .
  • PROBLEM: People running an OBFS4 bridge relay will probably encounter the following hourly error message: “Unable to find IPv6 address for ORPort xxxx.” It seems that with Tor version 0.4.5.* the Tor Project focuses on improving the IPv6 support (until now, a Tor relay needs a public IPv4 address). At the same time, they changed the address auto-discovery behaviour (see here, here and here), which probably leads to this hourly error message. Even, the Tor Project writes in the Changelog for 0.4.5.7 that they removed “a spammy log notice falsely claiming that the IPv4/v6 address was missing”, it doesn’t seem to work completely. However, this error message has no negative on the operation and the status on Metrics. PROBLEM SOLVED✔︎
    .
  • BUG: Entry 5 in the update and reset sub-menu, which should update the TorBox menu fails to remove the old lib/__pycache__ directory. Even if saying yes to remove it, the update will be incompleted because it cannot replace the old lib directory. Unfortunatelly, all files in that directory except lib/__pycache__ are deleted, so that the TorBox menu will not properly work anymore. It can be fixed with the following procedure:
    – Leave the TorBox menu by pressing ESC
    – Type sudo chmod a+w -R lib
    – Start TorBox menu again by typing ./menu
    – Start the update and reset sub-menu and execute entry 5
    .
    After this procedure and the succesful update, the bug is fixed. We will update the image in the next days. BUG STILL OPEN IN THE IMAGE FILE
    .
  • BUG: This affects only Bridge Relay operators: due to a bug in the main menu script, every second time when the main menu was started, the OBFS4 and ORPort was blocked, which set the Bridge Relay offline. You can fix these bug by updating the TorBox menu (update and reset sub-menu entry 5). The current image is updated.  BUG FIXED✔︎
    .
  • BUG: Already in TorBox v.0.3.2, main menu’s start-up can be stuck on the message “Checking connectivity to the Internet – please wait…” for an annoying amount of time if TorBox has no Internet connection. In TorBox v.0.4.0, the introduced timeout had no effect because we did it in a wrong way. You can fix these bug by updating the TorBox menu (update and reset sub-menu entry 5). BUG FIXED✔︎
    .
  • LOOK&FEEL: Because we offer several install scripts, which dependent on the operating system, install Tor in different ways, we decided to put the repository for Tor’s binaries and sources, knowing that, for example, on Raspberry Pi OS with apt-get update an error message is shown, which does not affect. However, inexperienced users might be discouraged by the error message. See also issue #36. You can fix these bug by updating the TorBox menu (update and reset sub-menu entry 5). CLOSED✔︎

Update your TorBox

We have good and bad news…

Bad News
The next TorBox release (v.0.3.3 or v.0.4.0) will probably not be published before the end of March 2021. The reason is that, currently, we travel around and test TorBox in real-world use. The drawn lessons learned will be implemented in the next releases. At the same time, as bandwidth spoiled freaks, we realized that in some places in the world the Internet connections are suicidally slow. This makes a release during our trip pretty much impossible.

Good News
If you have TorBox 0.3.2, you don’t need to wait to update the base system or the Tor version on your TorBox. First, choose entry 1 in the Update and Reset submenu to update your base system (to Linux Kernel 5.4.83). However, this will not update Tor because, for whatever reason, the Tor Project repository doesn’t support armhf anymore. To update Tor, choose entry 3 in the Update and Reset submenu. This will update Tor to the version 0.4.4.6. This version has an improved guard selection algorithms, adds v3 onion balance support and includes fixes for TROVE-2020-005.

The status message seen under entry 3 in the Update and Reset submenu after the update to the newest Tor version.

Travelling around, we expired in some countries a wrong DNS resolution regarding torproject.org. Probably, this is a kind of cheap censorship mechanism. This is why we added to our update script a set of open name servers. In other words, if entry 3 in the Update and Reset submenu produce an error and refuse to update Tor, try first entry 4, leave the Update and Reset submenu (it has to be reloaded) and try entry 3 again. In the next TorBox version, these set of open name servers will be installed as default. Important: these open name servers are only used for the DNS requests directly from the command prompt of the TorBox (during installations, updates, administrative work etc.), but not by the clients. Clients DNS requests are resolved through Tor.

We are working hard to replace wicd with our own lightweight wireless manager for TorBox v.0.4.0. The main reason is that it seems that wicd is not developed further. Several attempts to contact the developers went unanswered. The current version of wicd doesn’t support Python version 3, which produces some headaches under Ubuntu. At the same time, however, it is also an opportunity to significantly simplify the handling of wireless networks in TorBox.

Test version of the new TorBox Wireless Manager, which is replacing wicd in the next major release of TorBox.

TorBox v.0.3.2 released — all about user wishes

We are very dependent on your feedback! In this release, we have made an effort to implement your requests and improve the usability of TorBox based on your feedback.

If you download the new TorBox image or install it with our TorBox installer, it is important to notice that for security reasons, we locked/removed the user “pi”. To log into TorBox, you have to use the username: torbox / password: CHANGE-IT. Please, do not forget to change the default passwords as soon as possible (the associated entries are placed in the configuration sub-menu). Since we had to install additional software packages and update the configuration files, we recommend using the new image rather than updating an existing system. However, we have added a short guide at the end of this post for those who absolutely must update from the previous version (not older!).

TorBox Image (about 1.2 GB): v.0.3.2 (24.08.2020) – SHA-256 values
27.08.2020: the image has been updated with Tor version 0.4.3.6

TorBox Menu only: v.0.3.2 (24.08.2020) – SHA-256 values

Main Menu TorBox v.0.3.2
Main Menu TorBox v.0.3.2

• • •

Changelog: v.0.3.1 (30.05.2020) –> v.0.3.2 (24.08.2020)
  • Update: The system is based on Raspberry Pi OS “Buster” Lite with a Linux Kernel 5.4.51 and Tor version 0.4.3.6.
  • New: Based on several user requests, TorBox supports now internet connectivity over a VPN. Nevertheless, we do NOT recommend using a VPN. If Tor entry guards cannot be reached for censorship reasons, we recommend using OBFS4 bridges. Nevertheless, we consider the additional risk of this “Tor over VPN” situation  to be proportionate.
  • New: Also, based on user requests, we added in the configuration sub-menu the possibility to deactivate the TorBox access point functionality. In other words: you can now disable TorBox’s WiFi, which only makes sense, and is only possible, with (a) cable-connected client(s). 
  • New: Based on another user request, we added a new SOCKS v5 port to support destination address stream isolation. It can be chosen, if the old port 9050 without stream isolation or the new port 9051 with stream isolation should be used. We consider the implementation as “experimental” because we are worried about a possible negative impact on performance when using stream isolation. We like to hear your feedback on your experiences about that feature so that we can decide if we go to enable it for the entire data streams, not only for that particular socket.
  • New: Support for 3.5“ no-name TFT displays. Please let us know if you wish to have support for additional displays.
  • New: A new feature enables the functionality to add a new OBFS4 bridge automatically. Because we do not want to overload the Tor Bridge database unnecessarily with requests, this function only returns one bridge every 24 hours.
  • New: Slowly but steady, TorBox is becoming more system and hardware independent. For that reason, the login to administer the TorBox is new „torbox“ (with the default password „CHANGE-IT“). For security reasons, on the Raspberry Pi OS, the user „pi“ is locked (TorBox installer) or even removed (TorBox image).
  • Improved: Based on several user feedback, we changed again how TorBox reconfigures its network settings. Honestly, the rewriting and fixing of the  involved scripts was a real pain in the ass, and extremely time-consuming. Hopefully, the changes will smooth the user experience once more. Additionally, we also implemented a new failsafe mechanism, which should avoid lockout events. Before this update, that mechanism was implemented in the configuration script. Now, we moved it into the rc.local, so that TorBox can fix itself at startup.
  • Improved: Also, based on user requests, we improved the way how the completion of the various operations in the update and reset sub-menu is communicated to the user. We also improved the way TorBox’s configuration files are being updated / reset. Finally, we added a time synchronization feature in the update and reset sub-menu under the entry 10 “Just fixing and cleaning”. In case of a time synchronization problem, just open the sub-menu, mark entry 10 with the space key, and press “Enter” to fix it.
  • Improved: We also improved the DHCP server capabilities, which should minimize cases in which TorBox has to be restarted when switching from one connectivity setting to another.
  • Improved: To make TorBox more hardware and system independent, we modified how the user password get changed.
  • Improved: The indicators in the configuration sub-menu are now updated after each change. This prevents incorrect entries after changing the configuration.
  • Improved: The reboot and shutdown functions have been combined in one single menu entry to save space on the main menu. 
  • Improved: The installation scripts.
  • Fixed: There was an error in the Internet indicator. When wlan1 was chosen as a source, the indicator was set to eth1 and vice versa.
  • Fixed: There was another error in the INTERNET <-> WLAN0  <-> ETH0 <-> CLIENT configuration, which could prevent a trouble-free operation.
  • Fixed: We forgot to update the package lists before  we started to update to the newest version of Tor in the update and reset sub-menu. That was not very smart and, finally, broke the update functionality. We also forgot to inform the user to which version we would update Tor, which gave the whole operation a “Russian roulette” feeling.  We now also check if we could successfully download the Tor source files and display a message if something went wrong. Moreover, because of a typo, the folder “~/debian-packages” was not removed after the operation.
  • Fixed: By choosing iOS Tethering or an USB adapter using the eth1 interface (main menu entry 8), a wrong info-screen was displayed.
  • Fixed: We switched from “service rsyslog stop” to “systemctl stop rsyslog” to change logging from high to low in the configuration sub-menu. The former worked under Raspberry Pi OS, but not under Ubuntu.
  • Fixed: An error in the installation script for the Raspberry Pi OS  prevented to set the hostname to TorBox031. Because we use the installation script to build our image, this error was also on the image.
  • Experimental: A new installation script for installing TorBox on a hardware-independent Ubuntu-system (Ubuntu 20.04 LTS 32/64 Bit) is available. 
With TorBox version 0.3.2 no-name 3.5" TFT displays will be supported.
Starting with TorBox version 0.3.2, no-name 3.5″ TFT displays will be supported (the image is from the 0.3.2 pre-version).
How to update from TorBox v.0.3.1 (30.05.2020)?

To update a TorBox v.0.3.1 (30.05.2020) installation, you can perform the following tasks. This deletes all your custom made configuration, but not alter your bridge relay keys. Nevertheless, we recommend, if possible, to use the new image.

  1. Please, make sure that TorBox has Internet connectivity.
  2. Update the system: Go to the TorBox update and reset sub-menu (main menu entry 12) and update the base system and also the TorBox menu (entry 1 and 4). This will update TorBox’s packages and the Linux kernel to version 5.4.51.
  3. To ensure that all necessary packages are installed, execute the following commands (please, make sure that you copy the entire line!):
sudo apt-get -y update
sudo apt-get -y install hostapd isc-dhcp-server obfs4proxy usbmuxd wicd-curses dnsmasq dnsutils tcpdump iftop vnstat links2 debian-goodies apt-transport-https dirmngr python3-setuptools python3-pip python3-pil imagemagick tesseract-ocr ntpdate screen nyx git openvpn
sudo pip3 install pytesseract
sudo pip3 install mechanize

  1. Replace the changed configuration files:
sudo cp etc/tor/torrc /etc/tor/
sudo cp etc/dhcp/dhcpd.conf /etc/dhcp/
sudo cp etc/rc.local /etc/

The three commands above should work. Alternatively, you could also go to the TorBox update and reset sub-menu (main menu entry 12) and reset the entire TorBox configuration from there (entry 6).

  1. Restart TorBox
New: Automatically add a new OBFS4 bridge (the image is from the 0.3.2 pre-version).
Your feedback is welcome!!

We hope this version pleases you. However, we are dependent on feedback. It is not just about fixing bugs and improving usability, but also about supporting additional interfaces and hardware in future releases:

  • What do you like?
  • What should be improved (and how)?
  • What would you like to see next? Which features do you request?
Known problems and bugs
  • BUG – Entry 1 and 3 in the update and reset sub-menu should display the version of the installed Kernel, Tor, and Wicd. At the place of the wicd version, the following message is displayed: ERROR: wicd-curses was denied access to the wicd daemon: please check that your user is in the "^[[1;34mnetdev^[[0m" group. This bug has no consequences on the update procedure, but can be easily fixed with the following command at the command prompt: sudo adduser torbox netdev. To take effect, you have to reboot the TorBox. The installation scripts are already fixed – the current image is updated. BUG FIXED ✔︎
  • BUG – Additionally to the bug above, entry 3 in the update and reset sub-menu does not display the correct version of the newly available Tor version. This bug has no consequences on the update procedure. We fixed the script, which can be updated with the entry 4 in the update and reset sub-menu. The current image is updated. BUG FIXED ✔︎
  • BUG -Another little bug (actually, it was only a typo), prevented installing the newly available self-compiled Tor version (menu entry 3). We fixed the script, which can be updated with the entry 4 in the update and reset sub-menu. The current image is updated. BUG FIXED ✔︎
  • BUG – The Adafruit’s PiTFT installer script (entry 12 in the configuration sub-menu) aborts because it tries to work with the /home/pi directory, which does not exist anymore. We fixed the script, which can be updated with the entry 4 in the update and reset sub-menu. The current image is updated. BUG FIXED ✔︎
  • BUG – We discovered in the script, which is responsible for restoring the bridge relay configuration an error, which, in some situations, prevent the restoring of the values in the torrc file. We fixed the script, which can be updated with the entry 4 in the update and reset sub-menu. The current image is updated. BUG FIXED ✔︎
  • PROBLEM – Even if there is a *.ovpn file in the ~/openvpn directory and openvpn seems to run, TorBox still reports that there is neither a connection to a VPN nor a *.ovpn file available. Various factors are responsible for this:
    .
    • Currently, TorBox supports only tun0 as a valid VPN interface. Some VPN provider uses tun1, tun2, tun3, et.c in their *.ovpn files, which can be easily fixed. We modified the script, which checks the *.ovpn file and changes tun* to tun0. The fact that we only support tun0 is already mentioned in the respective information displays, but the wording has been adjusted slightly. The responsible script can be updated with the entry 4 in the update and reset sub-menu. The current image is updated. PROBLEM SOLVED ✔︎
    • Additionally, it seems that our time-out of 10 seconds for establishing a VPN connection was a little bit optimistic. Therefore we increased the time-out to 15 seconds. The responsible script can be updated with the entry 4 in the update and reset sub-menu. The current image is updated. PROBLEM SOLVED ✔︎
  • OPEN ISSUE – Why is Tor version 0.4.2.7 installed and not the newer stable version 0.4.2.8 / 0.4.3.6? For the Raspberry Pi OS, only Tor version 0.4.2.7 is available. However, after an updated TorBox menu (entry 4 in the update and reset sub-menu), Tor version 0.4.3.6 can be installed with entry 3 in the update and reset sub-menu. As of August 27, the available image file includes Tor version 0.4.3.6. We also installed the tor-geoipdb package. ISSUE CLOSED✔︎

Using 5 GHz USB WiFi adapter

It is known that the power consumption of the Raspberry Pi 3 Model B+ and the Raspberry Pi 4 Model B can be problematic. This is especially the case if you are using a “wireless-internet to wireless-clients” connection, which involves the wireless chip on the board and an additional USB WiFi adapter. As a rule, simpler, low-powered USB WiFi adapters lead to fewer problems, meaning that this kind of USB WiFi adapters usually supports only 2,4 GHz and not 5 GHz networks. Since TorBox version 0.2.5, the Internet can also be accessed via the onboard WiFi chip so that 5 GHz networks can be tapped. However, since the USB WiFi adapter might be missing on reboot, and a user might be locked out, TorBox will reset itself after a reboot so that the onboard WiFi chip will again act as an access point and can be accessed with a SSH client. Tthere are good reasons to use a USB WiFi adapter that can access 5 GHz networks even after a reboot.

In this article, we want to investigate whether using 5 GHz USB WiFi adapters makes sense in terms of power consumption and what problems might be associated with it. We want to focus especially on the nano-sized adapters because they usually have a lower power consumption. Nevertheless, as an alternative, we tested a modern adapter, which is relatively large and has two antennas. The tests are performed exclusively on a Raspberry Pi 4 Model B because firmware updates in late autumn 2019 reduced its overall power consumption. Therefore, we assume that the Raspberry Pi 4 is in a better position than the Raspberry Pi 3 Model B+, which to our knowledge, has not experienced any such improvement. The following adapters were (by chance) available for the test (more adapters may be tested on request – let me know):

The Netgear AC1200

The Netgear AC1200is not supported “out of the box” by Raspberry Pi. It needs to have installed a driver for Realtek RTL8812BU. Fortunately, Fars Robotics provides such a driver for a variety of kernel versions.

To install the right driver, first, the version of the used Linux kernel has to be identified with the command uname -a. With the kernel version known (for example, 5.4.51-v71+ #1327), the correct driver package can be found here: http://downloads.fars-robotics.net/wifi-drivers/8822bu-drivers/. In our example, the driver package name is 8822bu-5.4.51-v71-1327.tar.gz. The next step is to download and install the driver before the first use of the Netgear AC1200:

# The * has to be replaced by the correct kernel version
cd ~
wget http://downloads.fars-robotics.net/wifi-drivers/8822bu-drivers/8822bu-*.tar.gz
tar xzf 8822bu-*.tar.gz
./install.sh 
The "hothead" Netgear AC1200
The “hothead” Netgear AC1200

After the driver’s installation and a reboot, the Netgear AC 12000 adapter is discovered by the Raspberry Pi and ready to use. In the TorBox main menu using entry 5, we get into the network manager (wicd) and see now all available 2,4 GHz and 5 GHz networks. (Remark: since TorBox v.0.4.0, the more stable TorBox Network Manager has replaced wicd). When we connect with one of these networks, the adapter needs an unusually long time to authenticate itself with the chosen wireless network, but it worked reliably every time. In contrast, during the tests, we would have to reset wicd again and again because it crashed during configuration. Besides, the adapter in our tests lost the connection to the Internet after a few hours. In the time available, we could not determine whether this behaviour was caused by too much power consumption, too much heat accumulation at the USB interface or the adapter, or whether the driver software was causing problems (rather unlikely). However, we noticed that the USB interface of the Raspberry Pi and the adapter heat a lot during operation, so we think it is primarily a thermal problem. These observations were made when using 2.4 GHz and 5 GHz networks as well as mains and battery operation. Despite this inconvenience, the adapter worked both at 2.4 GHz and 5 GHz networks. However, you can forget about any speed advantages. In our case, the network performance on the 5 GHz network was not higher than a simple 2,4 GHz USB WiFi adapters.

The TP-Link Archer T2U Nano AC600

The TP-Link Archer T2U Nano AC600 does not work “out of the box” either – it needs a driver for the Realtek RTL8812au. Although Fars Robotics provides such a driver, currently, it is only available for the Linux kernel version 4.19.19 or older. (Remark: in the meantime, Fars Robotics has updated its driver, and you can install it the same way as described above. However, since TorBox v.0.4.0, these network drivers are already installed) In other words: with that adapter, we have to find another way to get it working. Fortunately, the project Aircrack-NG provides us with a solution:

# This should work with the latest kernel used by the Raspberry Pi OS, but probably not with older ones if the kernel headers are missing
cd ~
sudo apt-get -y install git dkms raspberrypi-kernel-headers
git clone https://github.com/aircrack-ng/rtl8812au.git
cd rtl8812au
sudo ./dkms-install.sh
The TP-Link Archer T2U Nano AC600
The TP-Link Archer T2U Nano AC600

After successfully installing the driver and a reboot, the TP-Link Archer T2U Nano AC600 adapter is discovered by the Raspberry Pi and ready to use. Like the Netgear AC1200, the TP-Link Archer T2U Nano AC600 takes an unusually long time to authenticate itself with a chosen wireless network. However, in contrast to the Netgear AC1200, there were no wicd crashes. The TP-Link Archer T2U Nano AC600 showed stable operation during the tests – at 2.4 GHz and 5 GHz; in mains and battery operation. The adapter did not lose the connection to the network even during hours of operation. However, the heat development on the USB interface and the adapter was roughly comparable to the Netgear AC1200. Again, no higher network performance could be found compared to simple 2,4 GHz USB WiFi adapters.

The TP-Link Archer T4U AC1300

The TP-Link Archer T4U AC1300 is — compared with the other two nano-sized adapters — gigantic. Using two antennas and supporting the multi-user MIMO technology, we had no great hope that the adapter would run stable in our tests. Needless to say that the TP-Link Archer T4U AC1300 did not run out of the box. However, it uses the same driver as the Netgear AC1200 (Realtek RTL8812BU), which can be installed in the same way as already described above. After installing the driver, our surprise was big. Even though the wireless network’s authentication process took again an unusually long time and wicd had to be reset frequently, the TP-Link Archer T4U AC1300 showed higher stability than the Netgear AC1200. The adapter showed stable operation during the tests – at 2.4 GHz and 5 GHz; in mains and battery operation, and it did not lose the connection to the network even during hours of operation. Interestingly, connected with a 5GHz network, the TP-Link Archer T4U AC1300 shows a significantly higher network performance. Random influxes cannot be excluded, but when downloading the LibreOffice package, constant data rates could be detected, which were at least twice as high as with the other two adapters or with simple 2,4 GHz USB WiFi adapters. Possibly the two available antennas with the multi-user MIMO technology come into play here. Also interesting is that the adapter warms up itself and the USB interface only slightly. This is probably due to the significantly larger surface of the adapter and the ventilation holes.

A Raspberry Pi 4 Model B with the "giant" TP-Link Archer T4U AC1300.
A Raspberry Pi 4 Model B with the “giant” TP-Link Archer T4U AC1300.
Conclusion

We stick to the general statement that simple, low-powered USB WiFi adapters lead to fewer problems. This is not only true for power supply, if not used the official power supply for the Raspberry Pi, but especially when searching and installing the necessary network drivers. However, the test also showed that the firmware updates in late autumn 2019 obviously solved many of the electrical supply problems that made the use of more complex USB WiFi adapters virtually impossible. In this sense, the good test results of the TP-Link Archer T4U AC1300 surprised us positively. The purchase of this adapter could be worthwhile not only concerning the availability of the 5 GHz networks but especially also regarding higher throughput due to the multi-user MIMO technology. The TP-Link Archer T2U AC600 also ran very reliably and impressed with its stability. Although it opens up the world of 5 GHz networks, higher throughput rates are not to be expected with this adapter. In contrast, the Netgear AC1200 left somewhat mixed feelings. It also allows docking to 5 GHz networks without providing higher throughput rates. However, in daily use, this adapter makes a much less stable impression. Regularly after a few hours, it loses its connection to the network, which in our opinion, is not acceptable. Probably the biggest problem of all these more complex adapters is that they are not supported out of the box by the Raspberry Pi OS.

The Raspberry Pi 4 and the trouble with its USB-C connector

A look at the underside of the Raspberry
Pi 4 reveals the board revision. If there is
a transistor directly next to the “MICRO”
lettering of the MicroSD card slot (below),
then it is the new board revision 1.2
without the USB-C bug. With an old
Raspberry Pi 4 (above), the transistor is
still located at the edge of the board
(Source: Thomas Koch and Mirko Dölle,
“Voll aufgebort: USB-C-Anschluss des
Raspberry Pi 4 ausnutzen”, C’T Heft 10,
2020, p. 136ff).

With the Raspberry Pi 4, the USB Micro-B connector has been replaced by a USB-C connector for the power supply. This was also necessary because, so far, no other Raspberry Pi model has drawn that much power. USB-C supports an electrical supply of at least 20V / 3A / 60W up to a maximum of 20V / 5A / 100W. This would be enough for a Raspberry Pi 4 under full load and additional USB devices, even if the official Raspberry Pi 4 Power Supply Unit (PSU) provides “only” 15.3W. In contrast, the sold USB Micro-B to USB-C adapter is not a long-lasting solution because the maximum power delivery of such an adapter is 12.5W. Especially in the beginning, when the Raspberry Pi 4 was new on the market, there were power supply problems if the official PSU of the Raspberry Pi Foundation was not used. 

Even if the overall power consumption of the Raspberry Pi 4 was significantly improved with the firmware updates in late autumn 2019, this has not been the only problem with the USB-C connector. Due to a faulty circuit, many existing USB-C power supplies and cables cannot power the Raspberry Pi 4. Only “dumb” cables without a SOP controller are working. 

Actually, the bug was fixed with board revision 1.2, which theoretically should be available in stores starting from the end of February. However, since this is not visible on the labeling, buying a Raspberry Pi 4 is like playing Russian Roulette. By looking at the packaging, the revision of the board inside is not recognizable. If the board finally ends up in your hands, you can tell by a transistor right next to the “MICRO” lettering of the MicroSD card slot that this is board revision 1.2 or not (see image on the right side). If the board is already in operation, there are several commands to check the board revision:

# Variant 1
cat /sys/firmware/devicetree/base/model

# Variant 2
cat /proc/cpuinfo | grep Model

EXPERIMENTAL: TorBox on Ubuntu Server 20.04 LTS (32/64 bit) and other hardware platforms

We recommend running TorBox on a Raspberry Pi 3 (Model B / Model B+) or a Raspberry Pi 4 Model B under Raspberry Pi OS “Buster” Lite. However, we created a new installation script that installs TorBox on Ubuntu Server 20.04 LTS (32/64 bit) and, therefore, might run on other hardware platforms (this script is currently in an experimental state).

Please give us feedback if you are using other hardware than the Raspberry Pi and have tried this installation script under Ubuntu.

The Coronavirus Pandemic and the Technological Progress

It is not surprising that technology is playing an essential role in the fight against the coronavirus pandemic. However, this pandemic is the first of its kind to use modern technologies such as artificial intelligence (AI) for almost real-time responses. This can be seen, for example, with Nextstrain, where the geographic spread and mutation of the virus can be tracked by examining its genetic code. Sequencing is an important, fundamental technology here that makes a detailed understanding of the virus and insights into combating the pandemic possible. It has been possible to identify the nucleotide sequence of a DNA or RNA molecule since 1995. However, there has since been breathtaking progress that has revolutionized the biological sciences.

The ways of spreading the coronavirus are convoluted. It has spread across the entire planet from its start in China. The colors represent different geographic regions. (Source: Nextstrain).

The progress of the past 25 years can be seen in the speed with which the coronavirus could be sequenced entirely. While the SARS (SARS-CoV) virus took about three months to sequence, the novel coronavirus was sequenced within a month, with the results published January 10, 2020, by Professor Zhang Yong-Zhen of the Shanghai Public Health Clinical Center. While globalization made it possible for the virus to spread worldwide quickly, global networking is helping to investigate the virus with its unique scope and nature. Specialized laboratories that have acquired the necessary molecules for a few thousand dollars can use the published genome sequence to assemble a copy of the virus, inject it into a cell, and activate it. Of course, there is also a certain risk associated with this ability, as was demonstrated 20 years ago when a deadly virus was produced from an emailed genome sequence. In order to prevent this technology from falling into the wrong hands and being used for the wrong purpose, orders placed in the United States for specific pieces of DNA are recorded in a database and are only delivered to authorized laboratories. Besides, the technological hurdles for the laboratories remain quite high (for now). The big advantage of this technology is that specialized laboratories around the world can research a virus without the need for a live sample from a contaminated area. Ralph S. Baric, a US coronavirus expert, sees this technology as the future of how the medical research community will respond to new viral threats. In 2008, his laboratory at the University of North Carolina had synthesized a coronavirus for study purposes that have been not existing in nature.

We are at the point where the best of the best can start to synthesize this new virus contemporaneously with the outbreak. But that is just a few labs. Fortunately, we are still far from the point when lots of people can synthesize anything.

Nicholas G. Evans, cited in Antonio Regalado, “Biologists Rush to Re-Create the China Coronavirus from Its DNA Code“, MIT Technology Review, 15.02.2020.

Technologies based on AI not only accelerate the sequencing and analysis of genomes but are also used to support diagnostics and research. Although the analysis of a nasopharyngeal swab is the most common method of a COVID-19 diagnosis, if there is a lack of test kits or if the patient population is very high, AI techniques can use CT scans of the lungs on a triage basis to identify those patients that are most likely to be infected. However, it is rather questionable whether this technique alone can also be used to diagnose an infection. Besides, the diagnosis of a nasopharyngeal swab is more reliable and cheaper if there are enough test kits. By contrast, the use of AI makes more sense when searching for and developing effective treatment and vaccination options. For example, Insilico Medicine used AI techniques to identify thousands of molecules for potential drugs in just four days and published the results on its website. Nevertheless, AI cannot solve every problem: before new treatment methods, or vaccination options can be used, they have to pass time-consuming clinical tests, which cannot be accelerated with modern technologies. It is, therefore, still unlikely that vaccination will be available on the market before the third quarter of 2021. An overview of all the currently researched treatment methods and vaccination options can be found here.

At the beginning of the coronavirus pandemic, there was not only a shortage of test kits in some countries, but with the high number of patients in intensive care units, there were also not enough valves and face masks needed to support the breathing of patients. There was also an inadequate supply of personal protective equipment for medical personnel. In part, such supply issues could be alleviated by using 3-D printers. For example, the Italian start-up Isinnova reverse-engineered a valve that is important for patient ventilation with the permission of its manufacturer Intersurgical3-D printed it, and made it available to hospitals in northern Italy. Isinnova has also manufactured a valve that can be used together with the Decathlon Easybreath snorkel mask as an oxygen mask in hospitals. The company Materialise, in turn, is offering a wide range of different products from its 3-D printers: face mask holders, face shield holdersrespiratory masksdoor openers, and shopping cart holders. In a comprehensive article that he is continuously updatingMichael Petch is tracking the wealth of 3-D printed products being created in response to the coronavirus pandemic.

Encrypting ransomware lurks in the background of this 
alleged corona tracking app.

Networking plays a central role in all of these technological approaches. However, this networking can have negative consequences when the widespread fear and high demand for information are exploited. In the early stages of the coronavirus pandemic in Europe in particular, false information that spread via WhatsApp and Telegram encouraged panic buying. Since the retailers were unable to replenish their shelves quickly enough for logistical and personnel reasons, the gaps suggested a non-existent supply problem, which only exacerbated the hoarding.

In the area of cybercrime, attacks using phishing emails are increasingly being used. These emails usually pretend to contain important information or offer behind a link or a document that presents itself as time-sensitive, but then download malicious and spy software or steal data, as was the case with the two alleged emails from the German bank Sparkasse and the WHO. However, even the mere dissemination of false information can cause physical damage, as demonstrated, for example, by the probable 2,850 methanol poisonings and the resulting 480 deaths in Iran. In this case, it was claimed that drinking industrial alcohol would kill the virus. As another example, in the UK, 5G cell towers were set alight because conspiracy theories claimed that the coronavirus pandemic and 5G were relatedRansomware is a particular type of malware that encrypts the contents of data carriers and only decrypts them once a “ransom” has been paid. For example, ransomware for smartphones lurked in an alleged corona tracking app. Computers in hospitals and medical laboratories are also being targeted by ransomware. In mid-March, for example, the Champaign-Urbana Public Health District in Illinois paid a $350,000 ransom to get its decrypted data.

How a contact tracing app works.

The threats to society that arise from the expansion and increasing use of surveillance options are at a more strategic level. Already end of April, 23 countries had introduced digital contact tracing, and 43 apps existed worldwide that enabled contact tracing. However, not all of these apps are effective or secure. The apps, all of which only use GPS, fail to provide enough precision to prevent false reports. Ten countries have gone even further and have been using facial recognition cameras (in Russia, for example); others have been added heat sensors (for example, China and Singapore), surveillance drones (for example, AustraliaChina, and India), and networked video surveillance systems (for example, Singapore). Censorship measures have been tightened in at least twelve countries (for example, in ChinaCambodia, and Singapore), and internet access has been restricted in at least four countries.

The Swiss École polytechnique fédérale de Lausanne is testing its decentralized contact tracing app, with members of the Swiss armed forces helping as test subjects.

If data is to be recorded, collected, and evaluated using a contact tracing app, for example, to combat the coronavirus pandemic, certain basic conditions must be observed from an ethical perspective. Proportionality must be the first priority, i.e., data collection must be proportionate to the seriousness of the threat to public health or the restriction of public life. The consequences that the restrictive measures designed to contain the pandemic will have on other freedoms and the health consequences in the absence of such restrictive measures fundamentally affirm an ethically justifiable use of contact tracing apps. However, such apps, as well as the data collected and evaluated by them, must be restricted in such a way that they are used only for this one goal, i.e., to warn someone that has come into contact with a person diagnosed as infected. The app and data must not be misused for other purposes, lawful or otherwise, such as criminal investigations, anti-terrorism efforts, etc. In addition, there needs to be scientific proof that the solution delivers the intended added value, which is why contact tracing apps based exclusively on GPS are ethically questionable due to their inaccuracy. Besides, the data collected should be anonymized effectively and stored as decentrally as possible. Information on the recording, collection, and evaluation of data must be provided transparently; this also includes keeping the source code for such apps open. The purpose of the transfer of data to third parties must be clear to the data subjects, and they must be able to rescind permission to such data collection in the future. The use of such apps, as well as the provision of the data, must be voluntary and only for a limited time. When an effective vaccine becomes available, the data collection must be stopped, the app and existing data have to be deleted.

TorBox v.0.3.1 released — all about bridges

Our goal with TorBox is not only to simplify the use of Tor as an anonymizing router but also to bring the use of bridges closer to those who want to get around censorship easily — with all their network traffic, not just their browser traffic.

TorBox v.0.3.1 comes one step closer to this goal. Not only has the management of OBFS4 bridges been improved once again, but it’s also now possible to check the status of bridges (online, offline, or doesn’t exist anymore) and based on that to enable, disable and delete them. For operators of a bridge relay, the possibility to backup and restore the relay data has been implemented. Also, other smaller improvements and wishes have been taken into account, which are listed in detail below.

Since we also had to update the configuration files, we recommend using the new image rather than updating an existing system. We have added a short guide at the end of this post for those who absolutely must update from the previous version (not older!).

TorBox Image (about 675 MB): v.0.3.1 (30.05.2020) – SHA-256 values
TorBox Menu only: v.0.3.1 (30.05.2020) – SHA-256 values

We would appreciate feedback so that we can make further improvements. The three most valuable feedbacks will get a ProtonMail $100 Gift Card (sent as a PDF). Additionally, we have still one Raspberry Pi 3 Model B to give away — of course, installed with the latest TorBox version. If you are interested, just send us an email.

• • •

Changelog: v.0.3.0 (12.01.2020) –> v.0.3.1 (30.05.2020)
  • Update: The system is based on Raspberry Pi OS “Buster” Lite with Linux Kernel 4.19.118 and Tor version 0.4.2.7.
  • New: The list of OBFS4 bridges displays now the status of the bridge (online, offline, or doesn’t exist anymore – see image below). The bridge management is rewritten. You can now easily activate, deactivate, and remove bridges in three ways: all, based on a specific status of the bridge or only selected. For example, you could activate all bridges, deactivate only the offline ones, and remove bridge #3 and #5.
  • New: The ability to backup and restore your bridge relay configuration, including your identity keys. This is important because when upgrading your bridge relay or moving it on a different computer, the important part is to keep the same identity keys. Keeping backups of the identity keys so you can restore a relay in the future is the recommended way to ensure the reputation of the relay won’t be wasted. The backup is stored / can be placed in the home directory, in which you can download / upload it with an SFTP client (using the same login / password as the SSH client).
  • New: An arrow in the main menu indicates from where you get the Internet.
  • New: USB Tethering with Android devices should now work (main menu entry 7). As I do not have an Android test device, this point needs to be tested further, and I rely on your feedback. I want to thank everyone who has been in active email correspondence with me on this point over the past weeks.
  • New: Added “Just fixing and cleaning” into TorBox’s Update & Reset sub-menu.
  • Improved: The countermeasure against a disconnect when idle feature (entry 10 in the Countermeasure sub-menu)shows now its status and can be deactivated.
  • Improved: Before Tor is compiled  (option 3 in the Update & Reset sub-menu), the current version is checked, compared with the one in the repository, and the user can decide if he wants to aboard before wasting time if no new version is available. Important: Currently, Tor can be updated with option 1 “Update the base system” in the Update & Reset sub-menu (main menu entry 12), and it is not necessary to compile Tor fresh.
  • Improved: The overall reliability of the update script.
  • Improved: The overall reliability of the installation script. It is adapted to the new Raspberry Pi OS, and we hope that this is the beginning of a platform-independent use of TorBox .
  • Improved: Cleaned up the code and outsourced more essential functions into a library. This helps to maintain the code in future releases properly.
  • Fixed: After shutting down the Bridge Relay, the two ports remained open (at least in some instances).
  • Fixed: If the Bridge Relay is deactivated and Tor is freshly started, the message appears that the ports are opened to the outside, even if this is not the case.
  • Fixed: An error in changing the password of the Tor control port broke the enforcing of a new exit node with a new IP (main menu entry 2).
  • Fixed (post-release): rfkill blocks the Raspberry Pi’s onboard WiFi chip and impossibles to create TorBox’s WiFi (it seems to be newly activated with Raspberry Pi OS) – we set rfkill unblock all in /etc/rc.local and had to rebuild the image again on Sunday, Mai 31, 2020 (we kept the same filenames).
How to update from TorBox v.0.3.0 (12.01.2020)?

Important: You cannot automatically update on TorBox installations, which are older then v.0.3.0 (12.01.2020)! If you need help, then please contact us.

With a TorBox v.0.3.0 (12.01.2020) installation, you can perform the following tasks. This deletes all your custom made configuration, but not alter your bridge relay keys. Nevertheless, we recommend, if possible, to use the new image.

Your feedback is welcome!!

We hope this version pleases you. However, we are dependent on feedback. It’s not just about fixing bugs and improving usability, but also about supporting additional interfaces and hardware in future releases:

  • What do you like?
  • What should be improved (and how)?
  • What would you like to see next? Which features do you request?

Review: Tor router on Raspberry Pi

TorBox running on Hoek’s hardware configuration.

Hoek wrote on his website 0ut3r Space, a very nice guide / review about the TorBox. He used a Raspberry Pi 4 Model B in combination with a 3.5inch RPi Display (TFT) with an XPT2046 touch screen controller. Of course, the touch functionality won’t work in the shell terminal. The TFT and a beautiful matching case can be found on Aliexpress. I ordered it today to write a new guide for the advanced section because the Pimoroni’s Pibow PiTFT+ case for the PiTFT 3.5″ resistive touch 320×480 from Adafruit is is not available for the Raspberry Pi 4. Possibly we will implement the driver installation in a future version of TorBox in the configuration sub-menu.

Thank you, Hoek, for your kind review!

Delay on the TorBox project due to the COVID-19 pandemic

Updated on May 6th, 2020
  • All comments and questions are now answered. Thanks for your patience.
  • The documentation for TorBox v.0.3.0 is now revised, and the rest of the website is adapted to this latest version. Also, additional entries in the FAQ have been added, based on the questions received.
  • Important: You can safely update TorBox v.0.3.0 (initially with Linux v.4.19.75 and Tor v.0.4.2.5 to Linux v.4.19.97 and Tor v.0.4.2.7) using the first entry “Update the base system” in the “Update and Reset sub-menu” (main menu entry 12). An update is recommended because Tor v.0.4.2.5 shouldn’t be used anymore. We are going to build a new image in the next weeks and TorBox v.0.3.1 is already in the making.
Original post:

Initially, it was planned to update the TorBox website according to the latest version of the TorBox by the end of April. Primarily the documentation is still focused on the older version. I also intended to add more fixes and even some newer features to the TorBox itself.

Unfortunately, due to the COVID-19 pandemic, I found myself In my professional job under enormous working pressure. So far, I haven’t even had time to answer all the comments and questions on the TorBox website and on GitHub, or the many email messages. Sorry, folks; I’m sure some users are already upset with me.

Since my holidays were canceled at the end of April, all projects related to TorBox — especially checking and fixing possible bugs, as well as updates to the operating system and core components — have been postponed to the end of July or beginning of August. However, if the work situation continues to calm down over the next few days, I’ll start answering the comments on the website and on GitHub as well as the emails addressed to me in the coming weeks.

I’m sorry for this inconvenience and hope to bring the TorBox project back up to date as soon as possible.