{"id":2643,"date":"2022-01-30T14:31:42","date_gmt":"2022-01-30T13:31:42","guid":{"rendered":"https:\/\/www.torbox.ch\/?p=2643"},"modified":"2022-07-08T04:36:06","modified_gmt":"2022-07-08T03:36:06","slug":"should-we-change-the-way-how-torbox-is-dealing-with-captive-portals","status":"publish","type":"post","link":"https:\/\/www.torbox.ch\/?p=2643","title":{"rendered":"Should we change the way how TorBox is dealing with captive portals?"},"content":{"rendered":"\n

Please participate on our Github discussion board<\/a>. I need as much input as necessary to decide if we should permanently change how TorBox is dealing with captive portals<\/a>.<\/p>\n\n\n\n

Current situation<\/h3>\n\n\n\n

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<\/code> 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<\/a> of the TorBox in a whitelist so that we can connect the TorBox with the Internet. I call that method “TUNNELING”.<\/p>\n\n\n\n

Problem<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

Solution<\/h3>\n\n\n\n

With the new_captive_portal_pass_through<\/code> 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<\/code> branch offers both methods.<\/p>\n\n\n

\n
\"new_captive_portal_pass_through\"<\/a><\/figure>\n<\/div>\n\n\n

To install the new_captive_portal_pass_through<\/code> branch is easy by using the expert mode of entry 5 of the Update & Maintenance sub-menu<\/a>. Additionally, you have to copy the updated rc.local<\/code> file to \/etc<\/code>: sudo cp etc\/rc.local \/etc<\/code><\/p>\n\n\n\n

Questions<\/h3>\n\n\n\n

The next step in the new_captive_portal_pass_through<\/code> 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:<\/p>\n\n\n\n