I don’t have the slate gla-750 router. I have the gla-750 does it have that option within the administrator settings.
It is the same. Just try
I use a ZTE Blade A3 Prime on Visible, tethered to my GL-AR750S Slate purely for data in my RV.
My averages for the past month are: 4.6 down, 3.8 up
After adding the line in I am now seeing: 15 down, 18.5 up.
Thanks swordfish-ii!! I really appreciate your willingness to share this info.
2 Likes
Hi, I am looking to see what you recommend… I just signed up for *v1sible and am looking at phones and routers for my rv. Thanks 
I use a Pixel 2. You’ll probably need to activate the Visible sim on another phone though. The Pixel 2 will only do data, no calls or SMS. The reason to choose the Pixel 2 is price (used via Swappa) and it has a good modem (Snapdragon X16).
Pro Tip: Enable developer options on the phone and set the default USB mode to tethering. This will save having to set it every time you reboot the phone or router.
Hi,
How do I connect the Slate to my phones hot spot?
Thanks in advance
Signed Rael the Newb
Just like you would connect to any other connection through the router.
Turn your phone’s hotspot on, then log into your Slate router. Connect the Slate router to your phone’s hotspot through the Slate’s UI, that’s it.
2 Likes
Thank so very much. It really was that simple and everything so far has worked like a charm… However as I have been poking around becoming familiar with the works, maybe it’s a toggle I hit inadvertently or something else but somethings happened a few days in and I keep getting bounced from the connection. The only way I found to countermeasure is to log in as admin, go to “Internet” and connect manually again. have you heard anything of this? If it weren’t for these forums, I’d be wallowing for months prolly. Thanks again!
RaelImperialAerosolKidd
You say I must be crazy, 'cos I don’t care who I hit, who I hit
But I know it’s me that’s hitting out and I’m not full of shit
I don’t care who I hurt, I don’t care who I do wrong
This is your mess I’m stuck in, I really don’t belong
When I take out my bottle, filled up high with gasoline
You can tell by the night fires where Rael has been, has been
I don’t remember which thread I found this on, but his worked for me to stop the connection from bouncing you:
# PPTP Passthroughiptables -t raw -D OUTPUT -p tcp -m tcp --dport 1723 -j CT --helper pptp
iptables -t raw -A OUTPUT -p tcp -m tcp --dport 1723 -j CT --helper pptp
iptables -t mangle -I POSTROUTING 1 -j TTL --ttl-set 65#ipv6ttlfix
ip6tables -t mangle -I POSTROUTING -o wwan0 -j HL --hl-set 65
ip6tables -t mangle -I PREROUTING -i wwan0 -j HL --hl-set 65
#startTTL
iptables -t mangle -I POSTROUTING -o wwan0 -j TTL --ttl-set 65
iptables -t mangle -I PREROUTING -i wwan0 -j TTL --ttl-set 65
#endTTL
please make a step by step video and link it and tag me I have no clue what yall are talking about just that I can get rid of my 5mbps cap on visible
how and where do I find this code to insert the line from swordfish?
This is old. Now you can just set TTL in Manual settings of the modem.
Change outgoing TTL is good to conceal for mobile plan that prevent you from using your phone(mobile router) as hotspot(NAT) traffic sharing especially in 5G mobile plan in my country . 
Thanks for sharing.
I have a MT1300 running firmware v3.211, and 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.
iptables -t mangle -I POSTROUTING 1 -j TTL --ttl-set 65
and
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.
Any ideas?
You can put this in the customer firewall rules? Do this in luci.
You mean custom firewall rules, right? That’s what I did. And it almost works- but not quite. I see the initial TCP SYN and ACK packets have the TTL field overwritten in the IP header, but once the TCP connection is established the subsequent packets do not have the TTL field overwritten.
I’m not sure if there’s a bug in iptables, if there’s some other rule that is interfering with the mangling rule, or if I’m screwing up the rule somehow.
Following up on this, I tried adding three TTL-modifying rules to the PREROUTING, POSTROUTING, and FORWARD chains:
iptables -t mangle -I PREROUTING 1 -j TTL --ttl-set 70
iptables -t mangle -I POSTROUTING 1 -j TTL --ttl-set 65
iptables -t mangle -I FORWARD 1 -j TTL --ttl-set 75
Given processing order, I would expect to see everything coming out with a TTL of 65. That’s not what I see. But I did see an odd pattern.
Of the packets that were set to a TTL of 65, they were almost always short TCP packets- typically ACKS- in 64 byte ethernet frames (which looks like 60 bytes to wireshark with the FCS stripped out). Further, because they were short, the ethernet frames needed to be padded out to that minimum length. That padding should be just zeros, but the last four bytes in the captured packet in wireshark aren’t zero. My guess is that I’m seeing the FCS, which doesn’t entirely make sense since there needs to be another 4 bytes at the end of that frame.
Not all of the packets with a TTL set to 65 are like this. Only the packets in padded frames have this problem. There are some other TTL-65 packets, but the remaining ones fall into very limited cases:
- 70 byte (66 bytes in wireshark without FCS) TCP packets
- Longer TCP retransmissions
- The first UDP packet in a QUIC connection
- NTP/DNS/ICMP packets, which all originate from the MT1300
The NTP/DNS/ICMP packets originating from the router always have a TTL set to 65.
QUIC packets from devices behind the router have varied TTLs of 65, 69 and 127 (the postrouting rule, the prerouting rule, and one less than the source device). The Initial QUIC packet is always set to 65. After that point, there’s no clear pattern, except that payload packets with the same source port will have the same TTL set.
There’s no clear pattern with short packets (though, they tend to be set to 65).
There are some limited patterns with TCP packets. The initial SYN and SYN-ACK packets are always set to 65. And the TCP-FIN packet at the end of a TCP connection is always set to 65. ACK packets are often 65, but not always. Payload packets are either 69 or 127-- they’re never 65.
“This is old. Now you can just set TTL in Manual settings of the modem.”
Where do I find this? Thank you.
FWIW, if you’re doing this as I am (to get around ISP HotSpot/Tethering limitations) I’ve been doing the “TTL-65” trick for months using just a simple ttl-setting iptables rule and have passed Terabytes of data and it’s all at full speed; IOW, if that’s the reason you’re doing it, at least my ISP doesn’t care past the connection-establishment phase.
Hey just wondering, how do you hotspot/tether in your personal setup? I set up the easytether thing on the router and easytether app on my phone and hook on voa usb, but it alsp appears to just work with the phones built in usb tethering, and also the phones built in wifi hotspot. Which of those do you use? Wondering if all that easytether stuff was really necessary