Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save xirixiz/13c81490e611947ad11471995cc8c842 to your computer and use it in GitHub Desktop.
Save xirixiz/13c81490e611947ad11471995cc8c842 to your computer and use it in GitHub Desktop.
OpenWRT TTL manipulation on a travel router explained

OpenWRT TTL manipulation on a travel router explained


Setting the TTL to 65 can help solve OpenWRT hotel captive portal issues on a travel router because of the way captive portals often track and manage connected devices.

Here’s an explanation of the key reasons:

Device Differentiation:
Captive portals typically recognize and manage devices based on their MAC addresses and IP addresses. When you connect a device (like a laptop or phone) directly to the hotel's network, the captive portal captures the MAC address of that device and redirects it to a login page.

However, when you use a travel router (like one running OpenWRT) to connect multiple devices to the hotel's network, all the traffic from those devices appears to come from the travel router's MAC address. The captive portal might only authenticate the travel router itself, causing issues when individual devices behind the router try to access the internet.


TTL Manipulation
The TTL value is decremented by 1 each time a packet passes through a router. Devices connected directly to a network typically have packets with an initial TTL of 64. When a packet from such a device passes through the travel router, the TTL is reduced to 63 by the time it reaches the hotel network.

Some captive portals use the TTL value as part of their method for identifying traffic that should be redirected to the login page. A TTL of 63 can signal to the captive portal that the traffic is coming through a secondary router, which might prompt the portal to redirect this traffic differently or block it altogether.


Setting TTL to 65
By setting the TTL to 65 on the travel router, packets reaching the hotel's network will have a TTL of 64. This makes the packets appear as though they are coming directly from a device connected to the hotel's network, rather than through a secondary router. As a result, the captive portal treats the packets as if they are from a directly connected device, allowing them to pass through normally after the initial login.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment