Using Public Captive Portal Wi-Fi with Ubuntu

Introduction: Captive Portal is Commonly Used in Trains and Hotels

The captive portal is a common solution for passengers and visitors in a train or hotel to provide Wi-Fi service. It's convenient (but probably not very secure) for both sides of users and administrators. You may have connecting issues when using Ubuntu with complex network setting like using Docker, LXD, and more virtualization technology in your system. This post briefs some tips I used, and how I guide myself for difference scenarios.

Feel free to skil the session of tutorial if you are familiar with networking debugging.

Tutorial

Core Idea

The core idea is "always knowing where packs are and where they go". I always ask myself how I know that, what tool I can use, when I should use the tools, and more questions like these to make sure I am not doing something simply copy-paste. The following are some examples.

Is Network Fully Disconnected?

Is the network fully disconnected? That said, no pack goes out and come in at all. If so, the following items may be worthy of checking:

Some Tips if the Network Simply Drops Some Packs

If the client side seems to keep waiting for the response from the server side, it is very likely the packs can go out. Then some components may be worthy of attention to see what blocks packs:

Examples

Thus, I assume the network is established in both sides of hardware and software points of view. Something must drop my packets at some stages. In the end I found it's the LXD configuration of my local machine. See below for more details if you are interested.

HOW-To Guides

Test if the Network is Connected

Use ping or fping to a known server. 8.8.8.8 provided by Google is an IP easy to keep in mind.

Test Where the Network Packet Stops By

Use mtr to see every node that transit your network packets. If your network is fully connected with the external world and network, you should see the DNS server of Google e.g. dns.google shows up in your mtr report.

Use mtr --report to get a summary with limited numbers of packet.

You may probably want to use route or route -n to compare the output of mtr to understand if the routing information is consistent.

Check Possible Stages Drop Packets

The checking list for you to check which stage may drop your packets:

Is ufw Installed?

dpkg -l ufw

Basic iptabls Usage

In earlier version of iptables, it uses iptables systemd service to control it. We won't dive into the details.

Test Http Default Port and (the Nearest) DNS Server

`curl -v example.com

Explanation: A Real World Example

Following the example in the tutorial session. My laptop Wi-Fi connection works well when I am home, but I could not use the Wi-Fi in the hotel I stay. It implies the hardware of my laptop should function properly. For example, my Wi-Fi chip is properly enabled by my Ubuntu kernel.

My Android smartphone could also connect to the captive portal page and get authorized by the page to access external internet. It implies the hotel infrastructure is very likely good as well.

Additionally, the captive portal page does not show up at all on my browser of my laptop. It's simply an empty page and seems to wait for the response from the server side. In the meantime, curl -v example.com returns data properly. Thus, we have the following analysis:

We can conclude the other packets used by the browser are lost or dropped by some issues. Who did that? By following the checklist of Check Possible Stages Drop Packets, I found it's LXD bridges and subnets make the packets confused. Thus, delete the corresponding interfaces resolve the issue.

My solution works for me with Ubuntu Mate 18.04 with DB ICE and Hotel Marriott in Frankfurt.

The Commands

The commands I used in the above examples are:

# show all interfaces
ip a
# stop the interface before removing it. The system will complain if the interface is still running
sudo ip link set dev <interface name> down
# delete the bridge interface
sudo brctl delbr br-5f80d25d633e

Reference