Related
What the hell? Never even heard of opendns...wtf is it?
How do I fix it?
KidJethro said:
What the hell? Never even heard of opendns...wtf is it?
How do I fix it?
Click to expand...
Click to collapse
Are you using Wifi or 3G/Edge? Looks like the problem is with the admin that setup your Wifi.
Well sounds like you are using their DNS servers and someone blocked gmail.
go to opendns.com while tethering to change your settings if you can. You should see a "dashboard" link at the top right of the page.
OpenDNS is an alternative DNS service (normally DNS is provided by the ISP). Wifi-Tether-For-Root by default has OpenDNS hardcoded in as the default DNS (instead of T-Mo's DNS servers). Since all traffic on T-Mo 3G is routed through their central server, regardless of where you are physically, your ip on the internet will appear as coming from a T-Mo data center in Missouri or Kansas or something. Perhaps someone has maliciously set up an OpenDNS account with this ip and locked out gmail.
Edit: I am having no problems getting to gmail using WT4R. My tmo ip was different from the usual though. Perhaps they are load-balancing their US network. Last time I checked, my tmo ip came out in Kansas. This time however, it came out of Rhode Island. Strange, considering I am physically in California.
Could you lookup your internet-side ip address while tethering and see which tmo datacenter you appear to be coming from when your gmail access is restricted?
This is the first time I've ever used wifi tether. Was kinda wierd to see gmail was blocked. Working on setting up an opendns acct now.
Ok....I'm totally lost now. I've got an opendns acct setup. I'm lookin at the dashboard thing, and have no idea what to change to fix this issue?
You are going to want to go here https://www.opendns.com/dashboard/settings/
It should show your current IP in the drop down.
Turn off the filtering and make sure nothing down below is added.
jashsu said:
OpenDNS is an alternative DNS service (normally DNS is provided by the ISP). Wifi-Tether-For-Root by default has OpenDNS hardcoded in as the default DNS (instead of T-Mo's DNS servers). Since all traffic on T-Mo 3G is routed through their central server, regardless of where you are physically, your ip on the internet will appear as coming from a T-Mo data center in Missouri or Kansas or something. Perhaps someone has maliciously set up an OpenDNS account with this ip and locked out gmail.
Edit: I am having no problems getting to gmail using WT4R. My tmo ip was different from the usual though. Perhaps they are load-balancing their US network. Last time I checked, my tmo ip came out in Kansas. This time however, it came out of Rhode Island. Strange, considering I am physically in California.
Could you lookup your internet-side ip address while tethering and see which tmo datacenter you appear to be coming from when your gmail access is restricted?
Click to expand...
Click to collapse
Easy enough to figure out my ip addy....but no idea how to do the rest.
Weird thing though...I signed up fro an opendns acct, browsed around a bit in the dashboard and now gmail works? ~edit~ nvermind, spoke too soon...gmail is blocked again.
For some reason I have a problem wrapping my brain around this kinda stuff.
your ip could have changed
neoobs said:
You are going to want to go here https://www.opendns.com/dashboard/settings/
It should show your current IP in the drop down.
Turn off the filtering and make sure nothing down below is added.
Click to expand...
Click to collapse
I see my IP under the network tab. Under the settings tab it says "to control your settings, you need to add a network to your account." If I click "add a network" it takes me back to the network tab where my ip is displayed. If I click add network, it says network already exists?
Bleh....
Like i said, T-Mo is likely load balancing across their many gateways. My guess is whoever locked gmail out only did it to one of the gateways. Your best bet is to change the DNS servers away from opendns.
KidJethro said:
I see my IP under the network tab. Under the settings tab it says "to control your settings, you need to add a network to your account." If I click "add a network" it takes me back to the network tab where my ip is displayed. If I click add network, it says network already exists?
Bleh....
Click to expand...
Click to collapse
The reason is because only one openvpn account can control a network. Whoever has messed up that tmo gateway has full control of it until that person or openvpn changes the situation.
jashsu said:
Like i said, T-Mo is likely load balancing across their many gateways. My guess is whoever locked gmail out only did it to one of the gateways. Your best bet is to change the DNS servers away from opendns.
Click to expand...
Click to collapse
Ok, need this in baby talk, barney style. I have no idea how to change dns servers?
KidJethro said:
Easy enough to figure out my ip addy....but no idea how to do the rest.
Click to expand...
Click to collapse
http://www.ip2location.com/
jashsu said:
http://www.ip2location.com/
Click to expand...
Click to collapse
IP Address : 208.54.94.59 Location :
UNITED STATES, WEST VIRGINIA, CHARLESTON Latitude / Longitude : 38.3515 LATITUDE, -81.632 LONGITUDE Connecting through : T-MOBILE USA Time Zone : UTC -05:00
IDD Code : 1 Area Code : 304 Weather Station : USWV0138 - CHARLESTON
KidJethro said:
Ok, need this in baby talk, barney style. I have no idea how to change dns servers?
Click to expand...
Click to collapse
It might be enough to edit /data/data/android.tether/conf/dnsmasq.conf with a text editor and substitute out the DNS values in there with your own DNS. I'll try it out later.
jashsu said:
It might be enough to edit /data/data/android.tether/conf/dnsmasq.conf with a text editor and substitute out the DNS values in there with your own DNS. I'll try it out later.
Click to expand...
Click to collapse
"wifi tether" should update the dnsmasq.conf-file automatically (will take the dns from your 2G/3G-connection) - this was introduced in version 0.95.
Type ... "getprop net.dns1" into terminal ... that should exactly be the nameserver in dnsmasq.conf (after you have started tethering).
Bleh....I need a break from phone tweaking for a bit. Buuurn ouuuut
Works for me
I just got home, tethered just to see if it would affect me too. Not problems at all.
harry_m said:
"wifi tether" should update the dnsmasq.conf-file automatically (will take the dns from your 2G/3G-connection) - this was introduced in version 0.95.
Type ... "getprop net.dns1" into terminal ... that should exactly be the nameserver in dnsmasq.conf (after you have started tethering).
Click to expand...
Click to collapse
harry_m is right. When I tethered to my G1 via WT4R (ver 0.9.6) and visited opendns.com, it showed the "Start using OpenDNS" button, indicating my currently used DNS was not OpenDNS. I verified that WT4R had fetched the G1's internal DNS setting by checking the dnsmasq.conf:
Code:
$ su
# cat /data/data/android.tether/conf/dnsmasq.conf
no-resolv
no-poll
server=10.177.0.34
server=10.176.80.242
I suggest you reinstall WT4R and choose no when it gives you the option to import old settings. This way, it will build your configuration files from scratch (and not use OpenDNS).
Ok T-Mobile as well as other isps have been known to log dns servers to see
what users access and is a big privacy concern, I would like to use OpenDns
but I have not been able to do so, any help would be appreciated, here is
what I have tried:
added this to init.rc:
setprop ro.kernel.android.ndns 2
setprop net.rmnet0.dns1 208.67.222.222
setprop net.rmnet0.dns2 208.67.220.220
setprop net.dns1.108 208.67.222.222 # random dns setting set???
setprop net.dns2.108 208.67.220.220 # wtf
setprop net.dns1 208.67.222.222
setprop net.dns2 208.67.220.220
and also ran in terminal, restarted interface and still wont use opendns,
verified at welcome.opendns.com that opendns isnt setup properly...
T-Mobile/Google have obviously made it hard to change dns settings for a reason and I would like to control this myself, as well as others should for privacy/security purposes, so lets figure this out
defcon
P.S. I know you can change DNS on wifi, through ipsettings with anycut, the mobile network dns settings seem to be set by dhcp and are static and we cant seem to change them within a gui, so we gotta figure out how to hack the dns settings on boot or when the interface connects to T-Mobile or your cell network...
Maybe you might want to reconsider:
http://forum.xda-developers.com/showthread.php?t=508149
If you're too lazy to read the entire thread, basically there is evidence someone has registered some t-mo gateway ips with their opendns account and is poisoning some of the resolves. Atleast one gateway seems to be blocking resolves of gmail.
Anyway, T-Mo can track your traffic without DNS, I assure you. Unless you are running some kind of end-to-end encryption like tor or a vpn tunnel, they can (and probably do) perform deep packet inspection.
the dns settings are automatically reset when your network status changes and this seems to happen extremely often, so there's basically no point in using setprop
yea obviously, so we need to find an alternative solution.
this one works
You're fooling yourself if you think using an alternate DNS server is buying you any increase in privacy. Everything you are viewing over GSM is going through a proxy server. If you really don't want T-Mobile to know where you're going, your choices are basically:
1. Only use Wifi for browsing
2. Set up some kind of encrypted tunnel (via VPN, SSH tunnel, etc.) and point your web browser to it.
3. Only visit HTTPS sites (in which case T-Mobile will know the IP address you're going to but not necessarily the website domain).
jashsu said:
they can (and probably do) perform deep packet inspection.
Click to expand...
Click to collapse
I can confirm they DO use deep packet inspection.
Okay, I'm here in Houston and as of yesterday, I have noticed that it takes FOREVER for certain web pages to load. Specifically, Google.com(along with google search), and Yahoo (m.yahoo.com)
When I switch to 3g and Wifi, they resolve normally. On 4g, it's as if the dns server is having a tough time getting there. The weird thing is when I ping the sites by domain, I'm getting responses on my phone so I'm not even sure if it's DNS. Since if it was DNS I'd get slow responses, or I would only be able to ping it by I.P address.
So, I got an app on the market called SETDNS, and it seems to change my DNS server (I have it set to OpenDNS) and it still doesn't load up these sites fast.
Anyone in Houston having an issues with slow sites?
I've verified that it's not my rom (CUBEDROM) as my Co-worker here is on BAMF and is currently experiencing the same thing. I thought it was just the tower we both happened to be on, but we went somewhere outside of work on the other side of town, and still the same thing
Any ideas?
Samsuck said:
Okay, I'm here in Houston and as of yesterday, I have noticed that it takes FOREVER for certain web pages to load. Specifically, Google.com(along with google search), and Yahoo (m.yahoo.com)
Click to expand...
Click to collapse
FWIW, I'm in Denver and experiencing the same issues on those sites. While on the LTE network, some sites are ridiculously slow to load compared to 3G. I don't believe it's strictly a DNS issue; you'd never get the page to load at all if you couldn't resolve the domain name, you'd just get a 404 or the like.
Same thing with me in Pittsburgh. Even happens when trying to load the XDA app. Just takes forever on 4G but then 3G works fine.
NickWarner said:
FWIW, I'm in Denver and experiencing the same issues on those sites. While on the LTE network, some sites are ridiculously slow to load compared to 3G. I don't believe it's strictly a DNS issue; you'd never get the page to load at all if you couldn't resolve the domain name, you'd just get a 404 or the like.
Click to expand...
Click to collapse
Yeah, you know what you're right. If it was strictly DNS then I would only be able to ping by I.P
So is 4g being routed through a proxy or something?
It's getting annoying because I use google search alot on my phone, and it will only load up properly on 3g.
Hrm, so apparently it's not just a Houston thing.
If anyone could continue to confirm this that would be great.
Purely just a theory, but with the big sites like google.com and yahoo.com, they are testing IPv6 (Global IPv6 test day, started yesterday at like 4pm West time i believe). Possible that your wifi and 3g can handle IPv6, but the 4g switches were struggling? Just a theory.
Same issues here in Detroit, was better 20 mins ago but back to the same problem again.
I agree that World IPv6 Day could be a cause, but that's only if you have trouble routing to the IPv6 address. I'm testing using purely IPv4 addresses for m.google.com (First response I get is 74.14.213.193).
On LTE, I'm averaging 300ms for the first hop (69.83.157.73), and ~75ms for the other hops.
On 3G, I average 130ms for the first hop (69.83.157.73), and ~115ms for the other hops.
If that's on each packet, I'm experiencing about double the load time for any traffic to m.google.com on LTE vs. 3G. Of course, that's not taking into account actual transfer speeds, so some of that might be recouped on larger packets, but still, it's significant.
Same in Columbus, Ohio except that 3g was doing the same thing. I was trying to stream Tunewiki on the way to work around 8am and nothing would load. I tried rebooting but it didn't help. At that point I chalked it up to network problems. I jumped on wifi when I got to work and have been waiting for the threads to pop up here to confirm.
Same thing in socal so its a national thing
good thing we have options to change to 3g
and not 1x
Hrm, that's interesting.
Yooooo, i think you're right
check this article out
http://www.metro.co.uk/tech/865705-google-facebook-and-bing-test-ipv6-as-net-runs-out-of-space
I can't resolve google,yahoo, facebook,and bing is occasional.
They all will failover to IPv4, and I was testing using the IPv4 addresses. I still think there's something wrong here, and the World IPv6 Day stuff is masking it.
I can resolve all of the major sites in DNS and get both an IPv6 and IPv4 address for them. I chose to test with only IPv4 to ensure that my results would be comparable to each other.
Nick, i agree that there is an error here. I'm just outside of my 4g at work, but can you check what your IP is if you are on 4G? I have a sneaky suspicion that there is a correlation here. If we are on v6 and pinging to v4, could possibly see higher load times if there is software glitches on verizons end. Awfully suspicious if they are not related! And i do know the t-bolt is v6 ready, as all LTE on verizon are required to be v6 ready.
Hrm. When on 4g my IP is 166.249.220.38, for 3g my IP is 166.249.197.80
Samsuck said:
Hrm. When on 4g my IP is 166.249.220.38, for 3g my IP is 166.249.197.80
Click to expand...
Click to collapse
Well there goes my theory. Thanks for checking Samsuck.
I too see addresses in the same IPv4 Class A (10.0.0.0) when on either LTE or 3G. I'm seeing non-routables, of course, which then get NAT'd through to a pool of external IPv4 addresses.
Running netcfg on the phone shows that I only get IPv4 addresses. I don't believe that these phones are receiving IPv6 addresses from Verizon, which makes sense if they're non-routable addresses, since they'll have to be NAT'd at some point.
Ok, so netcfg on Android only supports IPv4, which is my bad.
I may have spoke too soon. This guy says his VZ LTE always assigns him a IPv6
www(dot)anandtech(dot)com/show/4289/verizon-4g-lte-two-datacards-wifi-hotspot-massively-reviewed/3
I can't seem to find any sites discussing for definite what IP's VZ deals out on LTE.
Samsuck, was the checker you used IPv6 capable?
cmhfdisker said:
Same in Columbus, Ohio except that 3g was doing the same thing. I was trying to stream Tunewiki on the way to work around 8am and nothing would load. I tried rebooting but it didn't help. At that point I chalked it up to network problems. I jumped on wifi when I got to work and have been waiting for the threads to pop up here to confirm.
Click to expand...
Click to collapse
Same here in Reynoldsburg man. Went down forbme last night around 1am n spotty ever since...
4Geezy ON DopeDiculous's ROOTED TBeezy!
NickWarner said:
I too see addresses in the same IPv4 Class A (10.0.0.0) when on either LTE or 3G. I'm seeing non-routables, of course, which then get NAT'd through to a pool of external IPv4 addresses.
Running netcfg on the phone shows that I only get IPv4 addresses. I don't believe that these phones are receiving IPv6 addresses from Verizon, which makes sense if they're non-routable addresses, since they'll have to be NAT'd at some point.
Ok, so netcfg on Android only supports IPv4, which is my bad.
Click to expand...
Click to collapse
Man it sucks not being on 4g to try myself, but if someone could try usb tethering, and also wifi tethering, then IP checking on a IPv6 capable checker. Might find out if it is the culprit.
When you say checker what do you mean? How did I check my IP?
I just browsed to http://whatismyip.com
I pinged the different sites via the terminal emulator.
nbdysreal said:
Man it sucks not being on 4g to try myself, but if someone could try usb tethering, and also wifi tethering, then IP checking on a IPv6 capable checker. Might find out if it is the culprit.
Click to expand...
Click to collapse
Ok, when I'm on LTE, I do indeed get a public, routable IPv6 address. Using http://whatismyipv6.net on the phone, I can both see the address and traceroute back to it. Awesome.
On 3G, going back to the same site shows me that I only have an IPv4 address. It's a non-routable 10.0.0.0 address that gets NAT'd to a 166.250.0.0 address on the outside.
I am trying and failing to get wifi tethering to work. I am using a Nokia 6.1 running android v9 on AT&T in the US.
I go through settings to the wifi hotspot page, toggle off to on, and nothing happens.
If I leave the wifi hotspot page and return to it, the toggle is off again (I expect it to remain on). I never see the hotspot network name on my other wifi devices (I expect to be able to see and connect to the network).
I have seen some pages about APN settings being the problem, especially missing dun from apntype. I have tried a few different ones, without effect. My current apntype=default,mms,supl,dun.
I have looked at `adb logcat` while enabling the hotspot. There is nothing obvious in the log about the connection failing. I'm not sure what I'd be looking for, though.
Tethering did work on my previous phone (Moto G5) on AT&T on the same plan and in the same place. I don't have access to that phone now, though, to test what else might have changed.
How can I troubleshoot this issue and get wifi tethering working?
androidapollo said:
How can I troubleshoot this issue and get wifi tethering working?
Click to expand...
Click to collapse
You can try adb shell ip a sh command.
From the output you have to see youre WIFI interfase with the assigned IP.
For example on my phone, with hotspot activated the output is:
Code:
....
36: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 3000
link/ether 80:72:c0:f0:82:ac brd ff:ff:ff:ff:ff:ff
inet 192.168.43.74/24 brd 192.168.43.255 scope global wlan0
valid_lft forever preferred_lft forever
inet6 fe80::2282:c0ff:fef0:72ac/64 scope link
valid_lft forever preferred_lft forever
...
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Tether TPROXY uses iptables tproxy rules to capture tethered traffic and route it through a local proxy. This allows you to tether through your phone's internet source, be it a VPN or whatever else. Should also bypass APN classification and TTL/HL DPI checks. It supports TCP and UDP for IPv4 and IPv6. It can not proxy raw packets like ICMP, you can disable "Prevent Leaking" if required for your setup.
Tether TPROXY should support all tethering operations(USB, Wifi Hotspot, Ethernet). It does not enable tethering, that needs to be done manually.
Options:
Prevent Leaking - Allow traffic to exit through tproxy exclusively. Drops traffic on the forward chain of the filter table.
DPI Circumvention - Passes traffic on ports 80 and 443 to tpws to skirt DPI. Gives you proper fast.com scores.
Enable Dnsmasq - Bypass the built-in services and use Dnsmasq to provide DHCP/DHCP6/SLAAC/DNS.
IPv4 Address* - Lets you pick your IPv4 address/prefix. Makes it possible to set static addresses on your devices.
IPv6 Prefix* - ULA makes devices prefer using IPv4, GUA makes devices prefer IPv6.
*Only takes effect when Dnsmasq is enabled
Notes:
-After disabling the service, you will need to restart any active tethers you have running
-You may need to set APN protocol to IPv6 or IPv4/IPv6 to enable IPv6 for your mobile network.
-Dnsmasq can be used to get IPv6 working, but it is not recommended if you want traffic to leak.
-When using Dnsmasq, clients connected before the service is started will need to reconnect to get new addresses/routes.
Requires a kernel built with CONFIG_NETFILTER_XT_TARGET_TPROXY
Dependencies:
hev-socks5-server - https://github.com/heiher/hev-socks5-server
hev-socks5-tproxy - https://github.com/heiher/hev-socks5-tproxy
tpws - https://github.com/bol-van/zapret
Dnsmasq - https://github.com/worstperson/dnsmasq
Source:
GitHub - worstperson/TetherTPROXY
Contribute to worstperson/TetherTPROXY development by creating an account on GitHub.
github.com
Download:
[How it works]
When the service is enabled, it applies iptables rules and starts any servers required. These rules do not depend on the interface so they apply to all tethered traffic with no additions. This alone is enough for IPv4 to work.
The service also listens to "android.net.conn.TETHER_STATE_CHANGED" which fires whenever tethering is enabled or disabled. The service waits 5 seconds and then checks for Android's Dnsmasq listening on port 53 to tell if tethering is active. That IP is checked against established routes to get the active tether interface. With that, we can find it's IPv6 address and add an exception to allow IPv6 to work. If Dnsmasq is enabled, we also set IPs and routes at this point.
To get Dnsmasq to work, we need to make it use alternative ports with the options "--port=5353" and "--dhcp-alternate-port=6767,68". Then 3 iptables are used to make clients use them. One takes DHCP broadcasts and redirects them to port 6767, the second takes DNS requests and redirects them to port 5353, and the final rule blocks Router Advertisement packets from non-root processes.
(reserved)
Is this tested on Android 12.1? I enable the service, and the app shows Kernal TPROXY Support = PASS as well as having DPI Circumvention enabled selected.
I turn on my hotspot after enabling the service and I am still getting throttled to ~.5 mpbs. Are there any additional steps I missed or should try?
I'm using a Pixel 5A 5G on T-mobile with March update.
kkuhle said:
I turn on my hotspot after enabling the service and I am still getting throttled to ~.5 mpbs. Are there any additional steps I missed or should try?
Click to expand...
Click to collapse
Thanks for reporting!
Since you have "Prevent Leaking" enabled in your picture and the client(s) you have tested are able to access the internet after the service is started, I can know for sure that everything has loaded up correctly and tethered traffic is being successfully routed through the hex-socks5 and tpws proxies. I thought maybe tpws was exposing the TTL/HL of your traffic, but that is not the case, both hex-socks5 and tpws recreate packets with the TTL of the host(64).
I'm afraid I don't have a solution for you if the above information is correct/complete, it really should be working.
Just an added note, DPI Circumvention is mostly just for video, to access higher resolutions on services like Youtube or Netflix.
I tested this on Android 11, and it generally worked pretty flawlessly. I tried going back to Android 12 and seemed that it was working (speeds were not being capped). However, it seems to generally sooner than later start causing data connection to stop working altogether so hotspot clients of course aren't able to get an internet connection either.
kkuhle said:
I tested this on Android 11, and it generally worked pretty flawlessly. I tried going back to Android 12 and seemed that it was working (speeds were not being capped). However, it seems to generally sooner than later start causing data connection to stop working altogether so hotspot clients of course aren't able to get an internet connection either.
Click to expand...
Click to collapse
Thank you for the report! My devices are all A11 atm, I'll flash a GSI to one of them to see if I can reproduce. I'll also try to post a new version soon as this initial release is very rough.
fddm said:
Thank you for the report! My devices are all A11 atm, I'll flash a GSI to one of them to see if I can reproduce. I'll also try to post a new version soon as this initial release is very rough.
Click to expand...
Click to collapse
Welcome! I wanted to add that I started trying to use USB tethering hotspot yesterday instead of wifi hotspot. With usb tethering, my connection seemed to be rock solid (still A12) for a few hours as I used it. I had a couple additional devices that I just extended my hotspot on from my laptop settings. I only selected "Enable Service" in Tether TPROXY this time. Here is my usage from yesterday.
Total data over 15G and only 2.5 being recognized as Hotspot. There were some times where I disabled the service as it was causing me issues with the wifi hotspot (before I figured out the USB tethering was working nicely), so it may all be from that. I also didn't enable "Prevent Leaking" so I'll have to mess around with that next time I need it and see how/if usage changes.
I haven't been able to find anything else for Android 12 that has done what it claims when I was searching a couple weeks ago. Thanks a ton for this!
I spoke too soon. I can't get this to work anymore. It generally seems to cause my mobile network to stop working. I am over my mobile hotspot cap, so maybe that has someting to do with it.
I know it’s a dumb question. But I rooted my phone with only READ access to system files since I still can’t figure out how to do that. I wonder if it’s possible for me to use this app with just root?
shield616_666 said:
I know it’s a dumb question. But I rooted my phone with only READ access to system files since I still can’t figure out how to do that. I wonder if it’s possible for me to use this app with just root?
Click to expand...
Click to collapse
Only root is required, you do not need system r/w. This app is in an still in an early alpha state though.
fddm said:
View attachment 5572677
Tether TPROXY uses iptables tproxy rules to capture tethered traffic and route it through a local proxy. This allows you to tether through your phone's internet source, be it a VPN or whatever else. Should also bypass APN classification and TTL/HL DPI checks. It supports TCP and UDP for IPv4 and IPv6. It can not proxy raw packets like ICMP, you can disable "Prevent Leaking" if required for your setup.
Tether TPROXY should support all tethering operations(USB, Wifi Hotspot, Ethernet). It does not enable tethering, that needs to be done manually.
Options:
Prevent Leaking - Allow traffic to exit through tproxy exclusively. Drops traffic on the forward chain of the filter table.
DPI Circumvention - Passes traffic on ports 80 and 443 to tpws to skirt DPI. Gives you proper fast.com scores.
Enable Dnsmasq - Bypass the built-in services and use Dnsmasq to provide DHCP/DHCP6/SLAAC/DNS.
IPv4 Address* - Lets you pick your IPv4 address/prefix. Makes it possible to set static addresses on your devices.
IPv6 Prefix* - ULA makes devices prefer using IPv4, GUA makes devices prefer IPv6.
*Only takes effect when Dnsmasq is enabled
Notes:
-After disabling the service, you will need to restart any active tethers you have running
-You may need to set APN protocol to IPv6 or IPv4/IPv6 to enable IPv6 for your mobile network.
-Dnsmasq can be used to get IPv6 working, but it is not recommended if you want traffic to leak.
-When using Dnsmasq, clients connected before the service is started will need to reconnect to get new addresses/routes.
Requires a kernel built with CONFIG_NETFILTER_XT_TARGET_TPROXY
Dependencies:
hev-socks5-server - https://github.com/heiher/hev-socks5-server
hev-socks5-tproxy - https://github.com/heiher/hev-socks5-tproxy
tpws - https://github.com/bol-van/zapret
Dnsmasq - https://github.com/worstperson/dnsmasq
Source:
GitHub - worstperson/TetherTPROXY
Contribute to worstperson/TetherTPROXY development by creating an account on GitHub.
github.com
Download:
Click to expand...
Click to collapse
Thank you for this. Works like a charm to bypass a T-Mobile hotspot throttle. Awesome job, thank you
Something weird happens with this app, don't know if it supposed to happen like that but when this app is enable on my pixel 7 pro I'm able to share my hotspot with no problem but my current device gets no data at all, I don't know how to explain it, i might do a vid to show this to you
J0nhy said:
Something weird happens with this app, don't know if it supposed to happen like that but when this app is enable on my pixel 7 pro I'm able to share my hotspot with no problem but my current device gets no data at all, I don't know how to explain it, i might do a vid to show this to you
Click to expand...
Click to collapse
That is very weird and unintended. I suppose your running Android 13, so I'll need to get a test device set up so I can reproduce. Thanks for reporting!
Bro is this project dead? Btw it works fine on TMobile, but can't get it to work on Verizon
J0nhy said:
Bro is this project dead? Btw it works fine on TMobile, but can't get it to work on Verizon
Click to expand...
Click to collapse
Mind sharing more information? Are these the same device, stock or custom firmware? If it's carrier software/modifications flagging traffic, I can add some code automatically add 'dun' to your APN type and it should work around it.
fddm said:
Mind sharing more information? Are these the same device, stock or custom firmware? If it's carrier software/modifications flagging traffic, I can add some code automatically add 'dun' to your APN type and it should work around it.
Click to expand...
Click to collapse
Yep same device both on esim 5g, custom firmware "paranoid android" on pixel 7 pro, but i have tested on stock firmware and it's the same, I'm able to hotspot using "hotspot vpn" but traffic needs to go thru a VPN
J0nhy said:
Yep same device both on esim 5g, custom firmware "paranoid android" on pixel 7 pro, but i have tested on stock firmware and it's the same, I'm able to hotspot using "hotspot vpn" but traffic needs to go thru a VPN
Click to expand...
Click to collapse
Is this a dual esim setup? Mind sharing the output of this command from adb or a terminal app so I can be sure the patch updates the correct APN?
Code:
su
content query --uri content://telephony/carriers/preferapn
The fix will look something like this, but I don't have a device with multiple SIMs, so it only touches the first APN returned currently.
Java:
static void setDunApn() {
Log.w("TetherTPROXY", "Checking APN type for dun");
// get current id and apn type
Shell.Result command = Shell.cmd("content query --uri content://telephony/carriers/preferapn --projection _id:type | awk -F '[=,]' '{print $2,$4}'").exec();
if ( command.isSuccess() ) {
String[] parts = command.getOut().get(0).split(" ");
if ( parts.length == 2 && !parts[1].contains("dun")) {
Log.w("TetherTPROXY", "Setting APN type for dun");
// update type field with dun
Shell.cmd("content update --uri content://telephony/carriers --where \"_id=" + parts[0] + "\" --bind type:s:" + parts[1] + ",dun --bind edited:i:0").exec().getOut();
// restart data
Shell.cmd("svc data disable").exec().getOut();
Shell.cmd("svc data enable").exec().getOut();
}
}
}
Thanks for developing this app. I will have to try it even though I already have a couple of free working tethering solutions. It never hurts to have another tool for the toolshed given how things change with carriers. I take it that your app basically "proxifies/socksifies" traffic on the phone's tether interfaces to a local SOCKS5 proxy service/app on the phone.
By the way too many acronyms above. "DPI" is "deep packet inspection" for anyone else who wondered. I understand why you abbreviated it in the UI due to the length, but not in the description.
For IPv6 "GUA" is global unicast addresses (Internet routable) and "ULA" is unique local addresses (private IP addresses). I am not sure why you would want to choose a ULA in this situation since the goal is Internet access. Are the IP addresses on that configuration screen in the screenshot above the local addresses for the SOCKS5 proxy? If so, would using a ULA address for its IPv6 address mean that the clients would also need ULA addresses to access it? If so, how would the clients get those addresses? Self-generate them or does that setting set dnsmasq to issue ULA IPv6's to the tethered clients? Since (if?) you are using a SOCKS5 proxy to send the Internet traffic I am not sure why you say above that using "ULA" for IPv6 will prefer IPv4 when the IPv4 address is also a private one. Why favor private IPv4 over private IPv6?
fddm said:
Is this a dual esim setup? Mind sharing the output of this command from adb or a terminal app so I can be sure the patch updates the correct APN?
Code:
su
content query --uri content://telephony/carriers/preferapn
The fix will look something like this, but I don't have a device with multiple SIMs, so it only touches the first APN returned currently.
Java:
static void setDunApn() {
Log.w("TetherTPROXY", "Checking APN type for dun");
// get current id and apn type
Shell.Result command = Shell.cmd("content query --uri content://telephony/carriers/preferapn --projection _id:type | awk -F '[=,]' '{print $2,$4}'").exec();
if ( command.isSuccess() ) {
String[] parts = command.getOut().get(0).split(" ");
if ( parts.length == 2 && !parts[1].contains("dun")) {
Log.w("TetherTPROXY", "Setting APN type for dun");
// update type field with dun
Shell.cmd("content update --uri content://telephony/carriers --where \"_id=" + parts[0] + "\" --bind type:s:" + parts[1] + ",dun --bind edited:i:0").exec().getOut();
// restart data
Shell.cmd("svc data disable").exec().getOut();
Shell.cmd("svc data enable").exec().getOut();
}
}
}
Click to expand...
Click to collapse
The outcome for that command is:
i content://telephony/carriers/preferapn <
Row: 0 _id=1229, name=Verizon, numeric=311480, mcc=311, mnc=480, carrier_id=-1, apn=VZWINTERNET, user=, server=, password=, proxy=, port=, mmsproxy=, mmsport=, mmsc=, authtype=-1, type=default,dun,supl, current=1, protocol=IPV4V6, roaming_protocol=IP, carrier_enabled=1, bearer=0, bearer_bitmask=0, network_type_bitmask=0, lingering_network_type_bitmask=0, mvno_type=, mvno_match_data=, sub_id=-1, profile_id=0, modem_cognitive=1, max_conns=0, wait_time=0, max_conns_time=0, mtu=0, mtu_v4=0, mtu_v6=0, edited=0, user_visible=1, user_editable=1, owned_by=1, apn_set_id=0, skip_464xlat=-1, always_on=0