Visible TTL mangling - a poor noob down on his luck

[chumbie]

Hello everyone! First time poster, so I hope this is the right place to post this.

I have read quite a bit of information from these forums about TTL mangling (including the very helpful guide by @didneywhorl: https://wirelessjoint.com/viewtopic.php?f=21&t=2752), and I feel like I'm very close to succeeding in my quest for unthrottled hotspot LTE with Visible wireless on multiple router-connected devices. Anything to avoid using Comcast or AT&T (the only ISP options in my area).

My setup:

• Modem: MR1100 Netgear M1 Nighthawk with Visible SIM

• Router: GL-AR750S-EXT Gli.Net Slate Travel Router, flashed with OpenWRT 21.02

• MR1100 is connected via Ethernet to AR750S WAN port

What I know:

Using a small registry edit, I changed my Win 10 Laptop to use a TTL of 65, and can pull >20mbps DL speed unthrottled. This strongly implies that an iptables modification on the AR750S to set outgoing TTL traffic to 65 would be effective in allowing unthrottled traffic to all devices connected to the router.

My problem:
I have been trying different iptables commands in the custom Firewall settings to add the TTL change, to no avail. I have included the list of attempted codes at the end of the post as an attachment, it's quite a few.

The available interfaces on my device are br-lan, eth0, eth0.1, eth0.2, lo, and wlan0 per ifconfig. My sequence for trying a code is:

• Navigate to Network->Firewall->Custom Rules

• Enter the iptables command without leading hash symbol

• Save

• Reboot the router, to reset the firewall

Any suggestions would be greatly appreciated. I wouldn't be so frantic except that I know through my laptop that successful TTL masking will definitely work if I can just figure out how to do the same thing with my router!

[gscheb]

Hello,
If you are putting these in with a # in front of it that makes it ignore it.
Must be listed with out # in front of it.
Like these shown below.
Go ahead and try that and see if that is it.
Not sure since you are using a Wan interface instead of modem or tether.

#start TTL rules
iptables -t mangle -I POSTROUTING -o wlan0 -j TTL --ttl-set 65
ip6tables -t mangle -I POSTROUTING -o wlan0 -j HL --hl-set 65
# End-IP4-TTL-Fix

[chumbie]

Thanks for the response. As for the hashes, when I applied each rule they did not have a hash in front of them, that's just so I can keep them all in the config file for reference.

I just tried the rules you posted, the Wi-Fi speedtest still came back throttled unfortunately, though I do appreciate the input.

[gscheb]

With mine need higher TTL. Use 88 and also to use vpn for it to work consistently.
Don't know what the right thing is for it being connected with Ethernet.

Believe the part in Red is the one that would be different.
To either maybe usb0 or wwan0.


#start TTL rules
iptables -t mangle -I POSTROUTING -o wlan0 -j TTL --ttl-set 88
ip6tables -t mangle -I POSTROUTING -o wlan0 -j HL --hl-set 88
# End-IP4-TTL-Fix

[chumbie]

Oh wow, that's interesting, I wouldn't have thought to try higher TTL values. I wonder why your setup requires 88?

I have tried the following lines so far:

Code: Select all

iptables -t mangle -I POSTROUTING -o br-lan -j TTL --ttl-set 65
iptables -t mangle -I POSTROUTING -o br-lan -j TTL --ttl-set 64
iptables -t mangle -I POSTROUTING -o wwan0 -j TTL --ttl-set 65
iptables -t mangle -I POSTROUTING -o wwan0 -j TTL --ttl-set 64
iptables -t mangle -I POSTROUTING -o usb0 -j TTL --ttl-set 65
iptables -t mangle -I POSTROUTING -o usb0 -j TTL --ttl-set 64

I figured since it decrements with each router pass-through that 65 would have been correct for my setup (Phone wifi->Router->modem->Visible/Verizon), but I might try some different values. I also just found out you can restart the Firewall with Status->Firewall->Restart Firewall, which is much faster than restarting the router.

I tried using traceroute to determine how many hops exist in the network, just in case:

Code: Select all

Tracing route to 100.75.164.1 over a maximum of 30 hops

  1     1 ms     1 ms     1 ms  OpenWrtSlate.lan [192.168.1.8]
  2     3 ms     1 ms     1 ms  100.75.164.1

Trace complete.

If I'm reading this right, it means that their is only the one hop to get to the modem (100.15.164.1), which is through the router, as I suspected, which means that a postrouting TTL of 65 coming from the router would be sufficient, no? And all of this is underpinned by the fact that my laptop is registry edited to TTL 65 and has unrestricted DL speeds.

I have heard of people VPN tunneling through their phone's directly to hide the type of traffic, but I was hoping to see if the router TTL fix would work by itself similar to the registry fix.

[gscheb]

Well allot of people are finding that. Requires higher TTL and VPN. Then others don't have to do that. Little over a month ago something changed with Visible. It is kind of odd. Sometimes mine will work with out vpn and higher TTL and other times it won't. But for what ever reason my computers always work with out it.
https://wirelessjoint.com/viewtopic.php?f=32&t=2974&hilit

[mtl26637]

Surprisingly, this doesn't get mentioned much but the TTL modifications need to have the correct interface or its really not doing much of anything. In your case the device talking to the internet is the MR1100. The MR1100 is connected to the routers WAN port (eth0.2). Since you are using it in this scenario you would need to replace usb0 or wwan0 with eth0.2 since that is the interface you are using as your output. Also, you might +1 to whatever TTL usually works for people since you are 1 additional hop away from the 'internet' when it gets modified. I think the "-o" lines are the only ones needed. Give that a try and see how things go.

[chumbie]

Great suggestions, thank you both. Here are the lines I tried without success (add->Save->Restart Firewall):

Code: Select all

iptables -t mangle -I POSTROUTING -o eth0.2 -j TTL --ttl-set 64
iptables -t mangle -I POSTROUTING -o eth0.2 -j TTL --ttl-set 65
iptables -t mangle -I POSTROUTING -o eth0.2 -j TTL --ttl-set 66
iptables -t mangle -I POSTROUTING -o eth0.2 -j TTL --ttl-set 67
iptables -t mangle -I POSTROUTING -o eth0.2 -j TTL --ttl-set 68
iptables -t mangle -I POSTROUTING -o eth0.2 -j TTL --ttl-set 69
iptables -t mangle -I POSTROUTING -o eth0.2 -j TTL --ttl-set 70

I wish there was some way I could tell if the TTL change was definitely working, even if it's not changing the throttling speeds. Just restarted my laptop and now the TTL registry fix isn't working anymore either

If they're checking/changing the acceptable TTL values, maybe it would be worth it to try a vpn, I've never used one before but the documentation for the AR750S indicates it's possible to set it up on the router directly.

If I use a vpn, does that mean I don't have to disguise the outgoing TTL?

[tetranz]

If I use a vpn, does that mean I don't have to disguise the outgoing TTL?

No. It just makes it much more difficult for the carrier to figure out anything from your data.

I'm sure they can tell that you are using a VPN which itself might be a useful piece of information for them.

[chumbie]

Hey everyone,

It's working now!

Turns out I hadn't downloaded the opkg that allows TTL mangling, so none of the custom firewall rules were taking effect at all . This rule ended up being effective:

Code: Select all

# update packages
opkg update

# download mod package
opkg install iptables-mod-ipopt

# Start-IP4-TTL-Fix 
iptables -t mangle -I POSTROUTING -o eth0.2 -j TTL --ttl-set 66
# End-IP4-TTL-Fix

(I included the update and package install steps in case someone else copies it for a fresh router)

Once I did that and set up Mullvad Wireguard VPN on the router, everything started working perfectly, no throttling. Special thanks again to everyone who contributed (mtl26637, tetranz, and especially gscheb), you guys are the real MVPs.

I also wanted to post my full solution in case someone has similar problems. Not super sure on the correct forum etiquette, should I post this directly to the Tutorials board?



Unlimited, unthrottled Visible 4G LTE Wi-Fi data on multiple devices for 30$/mo

Overview

Average DL 50-100mbps in an urbanized city, with some deprioritization during the day. Some troubleshooting tips at the end as well!

Brief Summary of Steps:

• Sign up for Visible

• Order LTE modem and OpenWRT-compatible router

• Activate SIM

• Change IMEI of modem to Visible phone IMEI via DC-Unlocker 2

• Flash OpenWRT to router

• Setup LTE connection from modem to router

• Change TTL via custom firewall scripts to 66

• Setup router VPN (Mullvad).

(for some of these steps, a Windows laptop and a secondary or open wifi connection will be necessary for "bootstrapping" purposes)

Hardware Purchase and Setup

1. Purchase MR1100 Netgear M1 Nighthawk Mobile Hotspot (hereafter "Nighthawk" or "the modem") approx. $350, and GL.iNet GL-AR750S-Ext (Slate) Travel Router (hereafter "AR750S" or "the router") approx. $70. This may be possible with other devices, but these were the ones I used based on the tutorials I watched. Just make sure the router is OpenWRT compatible, which you can check here on OpenWRT's website.

This setup may also work by simply USB tethering the Visible-compatible phone directly to the AR750S, which would save you some money, but I haven't tested this, so if you wanted to use this tutorial and substitute the mobile modem with the tethered phone handset, I would encourage it.

You may also want to purchase a NanoSIM to MicroSIM adapter, such as this one, approx. $5, if you want the nano SIM to fit snugly in the Micro SIM slot of the modem.

1.1 While you wait for your gear to come in the mail, you can set up DC-Unlocker in Step 9 and get 29€ worth of credits while you're there, as well as download the appropriate OpenWRT installation file for your router (I used this one for the AR750S).

2. Sign up for Visible Wireless unlimited 5G data and 5MB/s hotspot plan. I didn't have any phones that were compatible with their service, so I also bought a cheap compatible ZTE phone for activation/testing/emergency hotspot purposes. You can join a public plan group by going to r/VisiblePartyPay on Reddit and joining one of the groups posted to get the group rate. I just joined the huge one stickied on the front page, I don't see any benefit to joining a smaller group.

3. Once the SIM arrives, put it in the compatible phone and activate the SIM through the Visible app. This step is important, as the service will not work until the SIM is activated. (You may be able to activate the service with the SIM directly in the LTE modem, but I haven't tested this). Make sure after your phone is activated that you are joined to the group you found on r/VisiblePartyPay, so that you pay the group rate ($25/mo as of 21 SEP 2021).

4. Verify that the service is functioning on the phone. This is also a good time to benchmark the DL/UL speed for your area on speedtest.net.

5. Place the SIM into the modem. Since the Visible SIM is a nanoSIM and the SIM slot of the Nighthawk is Micro, you will have to line up the SIM with the contacts in the middle-left of the slot, or you can use a MicroSIM adapter (recommended).

6. Connect the modem to a computer via USB and sign on to the Administrator panel at 192.168.1.1 , default login is admin//admin. (I saw in the forums that the default password can also sometimes be password). Set up your password and dashboard.

6.1 You may also want to verify that the 5MB/s hotspot works through the modem at this stage by connecting to the modem's Wi-Fi. In Advanced Settings-> Cellular, add the APN for Visible, which is:

APN Name: Visible
APN: vsblinternet
PDP: IPv4
PDP Roaming: IPv4

Login to the modem's default Wi-Fi gateway and verify that you can connect to the LTE.

Changing the Modem's IMEI

7. Go to Advanced Settings->Cellular->Uncheck DATA and ROAMING DATA-> APPLY. This turns off the mobile data to prevent it from connecting while we modify the modem's IMEI in Step #

8. Go to Mobile Router Setup->IP PASSTHROUGH->ON->SAVE. Note that this means you will only be able to access the modem's administration panel via USB until you disable IP PASSTHROUGH, since the wifi will be disabled.

9. Create an account with DC-Unlocker and download the client from the website. You will need to charge the account with ~29€ (euros) in order to fund the IMEI modification (current as of 21 SEP 2021).

10. Connect the modem to the Windows laptop and start the DC-Unlocker 2 client. Click the server tab on the right (blue earth icon) and Check login to the account your created with the appropriate number of credits.

11. On the left panel of the DC-Unlocker 2 Client you should see a Select manufacturer dropdown. Use this to select Sierra Wireless/NETGEAR. Leave Select model on Auto-detect and click the magnifying glass button to search for your connected modem. Note the IMEI of the connected modem should match the corresponding IMEI printed on the bottom of the modem itself.

12. Pull the IMEI number from the phone you used to setup the service by going into the Settings->About phone (for Android). You could potentially use another phone IMEI if it is compatible with Visible/Verizon service, but I haven't tested this, I used the phone direct from Visible to ensure compatibility.

13. On DC-Unlocker 2, select the Advanced tab, press Repair IMEI, and enter your phone's IMEI. You can check that your change was successful by repeating Step 11.

Setting Up Router Firmware

14. Setup the modem's APN, if you haven't already (Step 6.1).

15. Flash the router with OpenWRT (instructions are on the OpenWRT website). For the AR750S, I had to put the router first into the debricking interface. I used this tutorial and this release of OpenWRT for my setup.

From the OpenWRT AR750S page:

Note: As of OpenWrt 19.07.4, gl-ar750s-squashfs-sysupgrade.bin still gives an unsupported format error on the web UI and sysupgrade command, but works fine through the router's debricking interface: power down, ensure only 1 network cable is plugged in, hold the reset button, power on, wait until the led blinks 5 times and stays on, then release reset button. Change your IP to 192.168.1.2 and connect to http://192.168.1.1, where you can upload and flash the sysupgrade.bin image.

16. Once OpenWRT is loaded in the router firmware, connect the modem to the WAN port of the router via Ethernet.

17. Configure your wireless access point (AP) as necessary. Once I had the modem APN settings finalized the router AP just worked, but you may have to cruise the OpenWRT forums for some troubleshooting to get it working and verify that your current (5MB/s throttled) AP functions normally.

Throttle Bypass Settings

18. In OpenWRT, log-in and navigate to Network->Firewall->Custom Rules and place the following code:

Code: Select all

# update packages
opkg update

# download mod package for TTL mangling
opkg install iptables-mod-ipopt

# Start-IP4-TTL-Fix 
iptables -t mangle -I POSTROUTING -o eth0.2 -j TTL --ttl-set 66
# End-IP4-TTL-Fix

For the specific ttl value, you will likely have to try several values to find one that works (64 and 65 seem the most common, though others have reported using 117 or 88 as well for Verizon/Visible).

19. Verify your rules took effect by going to Status->Firewall->Restart Firewall, your TTL changes should be visible at the bottom of the page under Table:Mangle, Chain POSTROUTING, TTL set to 66.

20. Set up a VPN on the router for all traffic. I used Mullvad Wireguard VPN, following this video as a guide: https://www.youtube.com/watch?v=04q41GEPvKA.

21. After setting up the VPN I now experience full DL speeds on all devices that connect to the router AP. Woohoo!

Troubleshooting

• The modem display flashes "Your data connection is disconnected". This usually when I am doing some tests to the firewall or other settings. In these cases, I turn off the router, connect the SIM into the carrier phone used for the IMEI repair, and run a speedtest.net through the phone via the Android app a few times before connecting it back into the modem. If this doesn't solve the problem you can also connect the phone directly to the router temporarily as a tethered hotspot connection and try to reconnect in a few hours, though you may want to configure this usb tethered hotspot connection through OpenWRT before this problem occurs, to ensure a smooth transition in an emergency.

• The ping is very high (150-200 ms). Yes, it is . You are routing traffic through two different devices, as well as through a VPN, so the ping with this setup is going to be quite high. This setup is notable for how inexpensive it is on a monthly basis, not on it's efficiency, so if you require a shorter ping for gaming or other applications requiring fast response times, unfortunately this may not be the setup for you.

• The data is still throttled. I can't guarantee that this method will be effective, I can only say that this is what worked for me. Your best bet is to try different TTL values in your custom firewall rules and verify that your VPN is functioning correctly. You can also post your setup/problems as a separate thread and request some assistance, but include the model numbers of the hardware you're using in your post, as well as the custom firewall rules your are using as well.

I welcome any comments, tips, or critiques!

[luke37]

@chumbie - Thank you very much for this detailed write-up! I have a similar setup and it was extremely helpful while working through my own interface/ttl issues. Great post!

[chumbie]

Absolutely, glad it helped!

[chumbie]

I also posted a more current write-up here, using USB tethering rather than the Nighthawk: link

[rhaudiogeek]

Thanks a lot for your detailed writeup. It worked with the following setup:

GL.iNet GL-SF1200 Router
Netgear MR1100 ATT Branded Router

[chumbie]

Awesome, glad it worked for you!

[rhaudiogeek]

Enabling VPN throttles the speed down, anything I should be doing different ?
Using OpenVPN setup on the router.

[chumbie]

That's normal, just using a VPN by itself will slow down your connection, since your connection is now limited by the VPN protocol, unfortunately. You can try a Wireguard VPN service (e.g. Mullvad) to see if you get more DL speed, that protocol allows greater bandwidth than OpenVPN.

[letsief]

I have a MT1300 running firmware gl.inet software v3.211. I can’t get the custom firewall settings to consistently overwrite the TTL. I’ve tried several variations of the custom rules- with and without the WAN interface specified. Regardless of what I do, the initial TCP SYN and ACK IP packets get overwritten, but subsequent IP packets in a TCP session do not have their TTL values overwritten.

Code: Select all

iptables -t mangle -I POSTROUTING 1 -j TTL --ttl-set 65

and

Code: Select all

iptables -t mangle -I POSTROUTING -o apcli0 -j TTL --ttl-set 65

For testing purposes, the MT1300 is connected via wifi to my home router. To check the TTL, I’m capturing the packets coming in to my home router.

I'm pretty sure about what is getting overwritten. If I change the TTL values configured above, then I'll see the new TTL values in the SYN and ACK packets. But, after the third packet in a TCP session (so, once the TCP connection is established), the IP packets have a TTL of 127- so, one less than the initial TTL of the device I was using (a Windows computer). So, there seems to be something about having an establish TCP connection that stops the mangling rule from being applied.

Any ideas?

[chumbie]

Wow, that is bizarre, I can't think of a reason it would override the TTL of the first two packets but none after that. Normally if it wasn't overriding then at all I would say there is something wrong with the iptables rule, but that doesn't seem to be the problem.

With myAR750S-Ext I started by flashing OpenWRT, so my only guess in your case is that there may be some sort of custom modification to the gli.net firmware that is causing that behavior. Tbh I'm not even certain that's the issue here, although you could test it by installing OpenWRT to see if that fixes the problem, but I see that there isn't a firmware release for your model, unfortunately. That's a pickle.

I'm sorry I can't be of more help, if I come across something that sounds more substantial I'll definitely post it here. With any luck one of the more senior networking veterans will drop in and offer some insight.

[letsief]

Wow, that is bizarre, I can't think of a reason it would override the TTL of the first two packets but none after that. Normally if it wasn't overriding then at all I would say there is something wrong with the iptables rule, but that doesn't seem to be the problem.

With myAR750S-Ext I started by flashing OpenWRT, so my only guess in your case is that there may be some sort of custom modification to the gli.net firmware that is causing that behavior. Tbh I'm not even certain that's the issue here, although you could test it by installing OpenWRT to see if that fixes the problem, but I see that there isn't a firmware release for your model, unfortunately. That's a pickle.

I'm sorry I can't be of more help, if I come across something that sounds more substantial I'll definitely post it here. With any luck one of the more senior networking veterans will drop in and offer some insight.

It got weirder when it dug into it more. Basically, it was mostly short packets that were modified, which effectively mean SYN/ACK/FIN TCP packets. Some of these were short enough to need padding to get to the minimum ethernet frame size, and oddly, the padding was often mangled.

I initially suspected that established connections were bypassing iptables' mangle rules, either due to a bug in the rules or a bug in iptables. But, what I observed was stranger than that, because some packets in established connections were picked up by the *prerouting* rule. But only some.

I think I actually got it working with a PREROUTING rule on the br-lan interface. I kept the postrouting rule, since it seems to to get most of the packets that originate from the gl.inet router itself. I have no idea why the regular rule doesn't work.

It makes me wonder, though- is there a good way to test this when the router is connected to my phone? I can't capture packets. I'm not sure if there's some way to get a server you're interacting with to tell you the TTL of received packets. (I guess I could connect by to my home network and capture it, but I wonder if there's an easier way.)