Please participate on our Github discussion board. I need as much input as necessary to decide if we should permanently change how TorBox is dealing with captive portals.
Current situation
When the user changes the connection settings in the main menu, he is confronted with a dialogue asking if it is a direct connection or a captive portal. So far, the master branch and the v.0.5.0 release open a tunnel between a client and the captive portal to make it possible to deal with the login page of the captive portal. The idea behind it is that the captive portal put the MAC address of the TorBox in a whitelist so that we can connect the TorBox with the Internet. I call that method “TUNNELING”.
Problem
For whatever reason, it seems that the “TUNNELING” method will not always work, and it appears that the number of captive portals blocking this approach is increasing. However, due to a small sample, I’m not entirely sure if this observation can be generalized or I was only the “lucky one” with this problem.
Solution
With the new_captive_portal_pass_through branch, I introduced an alternative way to deal with captive portals, called “SPOOFING”. The idea is that a client directly connects a captive portal and opens it. When TorBox connects the captive portal, it asks for a MAC address. The user can enter the MAC address of the client, which is already whitelisted from the captive portal and connect to the Internet. So far, I only tested a handful of captive portals, and it worked not only well but better than the “TUNNELING” method. Currently, the new_captive_portal_pass_through branch offers both methods.
To install the new_captive_portal_pass_through branch is easy by using the expert mode of entry 5 of the Update & Maintenance sub-menu. Additionally, you have to copy the updated rc.local file to /etc: sudo cp etc/rc.local /etc
Questions
The next step in the new_captive_portal_pass_through branch is to allow users to list, change and reset the MAC addresses on every available interface. This questions the current approach to deal with captive portals:
Should we still offer both methods or depreciate the “TUNNELING” method? Did you test the new “SPOOFING” method and fail to access a captive portal with this new method?–> we will keep offering both methods because SPOOFING, too, is not always working.- Should we even differentiate between a direct connection and a connection through captive portals anymore? What could a better approach look like?
- In which sub-menu should I place the entry to list, change and reset the MAC addresses? Configuration or Countermeasure sub-menu or somewhere else
Please join our discussion on our Github discussion board.