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

• • •

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 9052 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. 

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

4. 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).

5. Restart TorBox

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✔︎

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):

• Netgear AC1200, nano-sized USB 2.0 adapter, which supports 802.11 b/g/n (2,4 GHz) and 802.11 a/n/ac (5 GHz)
• TP-Link Archer T2U Nano AC600, nano-sized USB 2.0 adapter, which supports 802.11 b/g/n (2,4 GHz) and 802.11 a/n/ac (5 GHz)
• TP-Link AC1300, USB 3.0 adapter, which supports 802.11 b/g/n (2,4 GHz) and 802.11 a/n/ac (5 GHz), with two antennas and multi-user MIMO technology

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 

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

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.

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.

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