I have a couple services running on my home computer that I like to access while on the road. Plex and VNC to be exact. Ports are forwarded correctly in my router. MyPlex shows my server is online and I can connect with VNC from another computer with no problem. I can sometimes connect with my streak, but mostly I cannot. I have had luck with changing some APN settings (I'm on AT&T), but I can't pinpoint which setting helps, as it's not always the same tweak that works. Any ideas? Could this be a dying sim card? I am running DSC 0.61b, but reverted back to 354 to see if it was a gingerbread problem. When I reverted back, I flashed a stock rom first, so that rules out low level firmwares. I never use to have a problem accessing this.
Is that other pc inside or outside the network?
Have you fully ruled out port forwarding issues and everything?
The other PC is outside the network. I'm fairly convinced that port forwarding issues are ruled out since it works on the other PC and occasionally works with the phone. I've also used some websites to check on the status of the ports and they always test out fine. I'm at a lost and a dying sim card is all I can think of, mainly because I don't know the symptoms of a dying sim card and this one is a couple years old. For whatever reason, when I bought my Streak, the guy at Best Buy used my existing sim card. I thought they always gave a new one...could be wrong.
I usually start with:
Terminal emulator.
Ping host
Ping known host (8.8.8.8)
Telnet host port
Traceroute host
--
But it works on 354 firmware... ltrifonov is currenly working on rebasing ROM to 2.3.7, there's a chance that newer Gingerbread version will help.
Anyway, i'm quite good at analyzing code of any source, but reading Android code, for example, WiFiService.java, make me twitching
Well, I did some more testing on the way home. My commute is almost 50 miles, so I had a chance to go through several cell towers (at least that's part of my theory). It seems it was only while I was at work that I couldn't connect. Once I got closer to home, I seemed to be able to connect, even after reverting to default APN settings. So my theory is that my problem is with AT&T's service and that maybe when connected to a particular cell tower, the ports are being blocked whether on purpose or not. Me playing with APN settings and reboots had the side effect of connecting to a different tower. Does this sound feasible? How can I get the ID of the tower I'm connected to? If I'm right, and I can narrow it down, I'll contact AT&T with my findings.
edit: I found a ton of apps to id cell towers in the market. I have no idea why I didn't look there first.
_n0p_ said:
I usually start with:
Terminal emulator.
Ping host
Ping known host (8.8.8.8)
Telnet host port
Traceroute host
--
But it works on 354 firmware... ltrifonov is currenly working on rebasing ROM to 2.3.7, there's a chance that newer Gingerbread version will help.
Anyway, i'm quite good at analyzing code of any source, but reading Android code, for example, WiFiService.java, make me twitching
Click to expand...
Click to collapse
Thanks for the reply _n0p_. It doesn't work on 354 either. So I don't think gingerbread is to blame...this time.
This is the traceroute from a laptop on the Verizon network. As you can see, it goes through no problem:
Tracing route to cpe-72-185-17-101.tampabay.res.rr.com [72.185.17.101]
over a maximum of 30 hops:
1 81 ms 76 ms 58 ms 64.sub-66-174-168.myvzw.com [66.174.168.64]
2 85 ms 102 ms 89 ms 191.sub-66-174-175.myvzw.com [66.174.175.191]
3 103 ms 92 ms 103 ms 201.sub-69-83-57.myvzw.com [69.83.57.201]
4 81 ms 84 ms 122 ms 18.sub-69-83-56.myvzw.com [69.83.56.18]
5 130 ms 102 ms 107 ms 70.sub-69-83-33.myvzw.com [69.83.33.70]
6 102 ms 84 ms 105 ms 67.sub-69-83-33.myvzw.com [69.83.33.67]
7 107 ms 110 ms 131 ms 207.138.128.13
8 90 ms 92 ms 91 ms po5-20G.ar1.ATL2.gblx.net [67.16.143.125]
9 92 ms 92 ms 112 ms TWC-COMM-LLCAtlanta.TenGigabitEthernet9-2.ar1.AT
L2.gblx.net [64.212.108.70]
10 87 ms 84 ms 87 ms ae-2-0.cr1.atl20.tbone.rr.com [66.109.6.176]
11 125 ms 125 ms 123 ms 66.109.10.15
12 115 ms 152 ms 125 ms 72-31-220-2.net.bhntampa.com [72.31.220.2]
13 154 ms 132 ms 111 ms 72-31-208-100.net.bhntampa.com [72.31.208.100]
14 134 ms 110 ms 114 ms te0-8-0-0.tpafl27-car2.bhntampa.com [71.44.3.11]
15 110 ms 110 ms 112 ms 72-31-208-251.net.bhntampa.com [72.31.208.251]
16 106 ms 127 ms 125 ms gig1-0-0.tampfl47-10k1.tampabay.rr.com [65.32.25
.77]
17 149 ms 153 ms 161 ms cpe-72-185-17-101.tampabay.res.rr.com [72.185.17
.101]
Trace complete.
This is the traceroute from my phone on the AT&T network. It does not go through.
sh-4.1# traceroute 72.185.17.101
traceroute 72.185.17.101
traceroute to 72.185.17.101 (72.185.17.101), 30 hops max, 38 byte packets
1 * * *
2 172.26.248.2 (172.26.248.2) 170.502 ms 171.845 ms 209.655 ms
3 172.18.166.82 (172.18.166.82) 210.266 ms 201.232 ms 249.572 ms
4 172.18.194.78 (172.18.194.78) 210.236 ms 201.232 ms 209.442 ms
5 172.18.194.2 (172.18.194.2) 209.900 ms 172.150 ms 209.686 ms
6 172.18.194.225 (172.18.194.225) 219.848 ms 181.763 ms 209.686 ms
7 209.183.38.226 (209.183.38.226) 210.601 ms 175.873 ms 209.625 ms
8 172.18.213.1 (172.18.213.1) 249.755 ms 184.662 ms 229.705 ms
9 12.88.97.9 (12.88.97.9) 219.818 ms 206.024 ms 209.869 ms
10 12.123.22.6 (12.123.22.6) 309.631 ms 12.123.22.130 (12.123.22.130) 236.48
1 ms 241.699 ms
11 12.122.80.185 (12.122.80.185) 209.717 ms 12.122.80.221 (12.122.80.221) 17
2.211 ms 12.122.80.185 (12.122.80.185) 180.878 ms
12 192.205.36.86 (192.205.36.86) 186.920 ms 182.312 ms 251.251 ms
13 216.156.108.58 (216.156.108.58) 218.232 ms 216.156.108.66 (216.156.108.66)
167.969 ms 216.156.108.86 (216.156.108.86) 184.967 ms
14 66.109.6.176 (66.109.6.176) 169.006 ms 107.14.19.12 (107.14.19.12) 189.48
3 ms 66.109.6.176 (66.109.6.176) 184.052 ms
15 66.109.6.105 (66.109.6.105) 179.016 ms 66.109.10.15 (66.109.10.15) 198.18
1 ms 66.109.6.105 (66.109.6.105) 179.993 ms
16 72.31.220.2 (72.31.220.2) 251.892 ms 274.719 ms 299.775 ms
17 72.31.208.106 (72.31.208.106) 329.803 ms 72.31.208.100 (72.31.208.100) 25
9.338 ms 268.921 ms
18 71.44.2.38 (71.44.2.38) 299.714 ms 72.31.208.136 (72.31.208.136) 245.514
ms 256.683 ms
19 72.31.208.251 (72.31.208.251) 289.703 ms 72.31.208.253 (72.31.208.253) 29
2.572 ms 72.31.208.251 (72.31.208.251) 247.406 ms
20 65.32.25.77 (65.32.25.77) 232.300 ms 193.787 ms 65.32.25.81 (65.32.25.81)
241.089 ms
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
sh-4.1#
My question is, where does the problem lie? The first hop times out; Would that be my phone itself? Line 21, which is where the timeouts start at the end, should be my home router, judging by what I see on the other traceroute. Is my router blocking the traffic from my phone specifically? Any idea why? I am at a loss here. There seems to be no rhyme or reason to this as far as I can tell and at this point I don't know who to complain to, AT&T, RoadRunner, or me...
Edit: So, I got my IP address for my phone from whatismyip.com and I can't ping that from the phone either. Problem??? or not...
Edit 2: Connected via a local wifi hotspot and traceroute connects on through.
Second trace stops at
-------
OrgName: Road Runner HoldCo LLC
OrgId: RRSW
Address: 13820 Sunrise Valley Drive
City: Herndon
StateProv: VA
PostalCode: 20171
Country: US
RegDate:
Updated: 2011-07-06
Comment: Allocations for this OrgID serve Road Runner residential custome rs out of the Austin, TX and Tampa Bay, FL RDCs.
Ref: http://whois.arin.net/rest/org/RRSW
------
First route goes through Road Runner without problems, so i may suggest NEXT op is the problem and it's AT&T, i suppose.
------
There's a probable interoperability problem either on last point, OR AT&T doesn't support ICMP packets on their routers.
Will think more about it
So I talked to AT&T this morning and basically all they told me was the APN settings and that I'd i could get to a website then their service was working fine. I'm betting they are blocking it somehow.
Sent from my Dell Streak using xda premium
I know this thread hasn't gotten much attention, but I'm posting my results here in case anyone runs into the same problem. If I use baseband 305 or 351, everything is fine. I'm going to try others and see if they work.
I have weird behavior! I have 4 SGS2s with OFFICIAL 4.0.3 release. 3 of them are OK, the fourth I had to force a static 192.168.0.x/24 address and DOESN'T CONNECT! And I have 5 other wireless devices (laptops and net tops) connected and working!!!
Net tools app shows me unbelievable results like wrong routes and 0.0.0.0 gateway!
Oh, my God, what a BUG!
yea
terrible
But1 out of 4 shows the bug? Are all SGS2 4.0.3!
Sounds more like your router isn't able to give it the IP Address its wanting.
4 SGSII? for four wives?
Sent from my GT-I9100 using Tapatalk 2
al_madd said:
4 SGSII? for four wives?
Click to expand...
Click to collapse
I wish.
It's just an office.
Bouncer5 said:
Sounds more like your router isn't able to give it the IP Address its wanting.
Click to expand...
Click to collapse
Is the DC server that has the DHCP to release addresses. The IP address IS released, but the SGS2 doesn't get the default gateway. Funny is: a browser on a PC can access the phone's Kies Air.
And: the server DHCP can't give the IP address JUST to THAT phone?
Hello,
I'm new to the forum, and I've tried to get this working on my own, but I'm stumped and am hoping someone out there can help me out.
I just bought a shiny new Nexus 7 tablet and would like to tether it to my Galaxy S III phone. I'm currently on a pay as you go plan on my phone where I have an "internet browsing" plan (via SpeakOut). This appears to limit my data services so I can't tether my tablet to the phone and get internet service on the tablet. Tethering works fine if the phone is connected to WiFi, an option I don't have when I'm on the train, doing my commute to work.
So, I've been trying to get OpenVPN set up at home to route all my mobile traffic through that and get tethering working for the tablet. But, I'm stuck with getting the tablet to route traffic over the VPN tunnel. The phone itself has no problems connecting and using the VPN link, but the tethered tablet (via WiFi or Bluetooth) gets no service. The best I can do is ping the phone and traceroutes go to the phone, but never get past it.
I've tried to read the man pages for OpenVPN, but each example uses its own IP blocks and it makes piecing it all together really confusing. In any case, I'm hoping someone here can help me out with this setup.
Here's my setup:
Code:
HOME LAN NET: 192.168.1.0/24
HOME GATEWAY: 192.168.1.1
OPENVPN NET: 10.8.0.0/24
OPENVPN SERVER
LAN IP: 192.168.1.116
VPN (internal) IP: 10.8.0.1
VPN (external) IP: 10.8.0.2
PHONE
VPN IP: 10.8.0.6
WIFI TETHER NET: 192.168.43.0/24
WIFI TETHER IP: 192.168.43.1
TABLET
WIFI TETHER IP: 192.168.43.150
Here is my OpenVPN server.conf file:
Code:
port 1194
proto tcp
dev tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir /etc/openvpn/ccd
route 192.168.43.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 4
and the client config file for the phone:
Code:
iroute 192.168.43.0 255.255.255.0
Please note, the OpenVPN server is a Mac running OS X 10.7.5 so I use the following script to set up the environment:
Code:
#!/bin/sh
sysctl -w net.inet.ip.fw.enable=1
sysctl -w net.inet.ip.forwarding=1
killall -9 natd
natd -interface en1 -u
ipfw -f flush
ipfw add divert natd ip from any to any via en1
here's my routing table on the server (netstat -rn):
Code:
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.1.1 UGSc 10 31915 en1
10.8/24 10.8.0.2 UGSc 0 0 tun0
10.8.0.2 10.8.0.1 UH 2 0 tun0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 0 765 lo0
169.254 link#5 UCS 0 0 en1
192.168.1 link#5 UCS 3 0 en1
192.168.1.1 98:fc:11:82:7d:4b UHLWIi 11 8799 en1 1171
192.168.1.116 127.0.0.1 UHS 2 153 lo0
192.168.1.120 0:1f:e2:88:af:a9 UHLWIi 0 1678 en1 1165
192.168.1.255 ff:ff:ff:ff:ff:ff UHLWbI 1 98 en1
192.168.43 10.8.0.2 UGSc 0 0 tun0
and the output of ipfw list:
Code:
00100 divert 8668 ip from any to any via en1
65535 allow ip from any to any
Any help with getting this running would be appreciated. Note, NEITHER the phone or tablet is rooted and I'd prefer to keep it that way, if possible. Secondly, I'd prefer to get the tethering set up via Bluetooth, so any guidance on that would be helpful, too. I have no idea how to inspect Bluetooth connectivity, though. Or, if you know a better way to get this tethering to work that doesn't involve OpenVPN I'd love to hear it.
Thanks!
Squeaky
Solution see cross-link
See http://forum.xda-developers.com/showpost.php?p=33749904&postcount=10
Recommended app, i use it to tether all the time
https://play.google.com/store/apps/details?id=com.opengarden.android.MeshClient&hl=en
i subscribed 2 GB plan from my prepaid isp..now 2 GB is too low data for me..
.
when i started first time droidvpn in p2p server..then my using byte not counting to my prepaid isp account so that isp doesn't know my uses of byte (mb or gb)
.
but now i tried many vpn like kepard,droidvpn etc but now its not working and isp counting my uses byte..
.
how i stop isp to counting my uses internet bytes..
.
sorry 4 poor english..hope u understand..:victory:
In a browser google resolves to an address in the 208.54.0.0/16 IP address block (example 208.54.38.51). This range is not owned by Google as far I know and actually resolves to tmodns.net, which is owned by T-Mobile.
Looking through Afwall+ firewall logs shows that before connecting to any Google services, for example downloading an app through the play store, the phone connects with an IP in the same 208.54.0.0/16 range. Using IPTABLES to block this range prevents me from being able to do things like access Google in the browser and download apps through the play store.
If I start transparent proxying through Tor I can connect to Google correctly as well as download apps with no problems.
Can anyone confirm that this happens on their T-Mobile phone? Is there anyway I can prevent this without having to go through Tor? Perhaps by using IPTABLES to redirect any connections to the 208.54.0.0/16 block to an IP owned by Google.
I also have my DNS set to use Google's DNS servers so that shouldn't be the issue. It seems like it's happening inside of T-Mobile's internal 10.*.*.* network before the phone connects to the outside Internet.
Code:
[email protected]:/ $ nslookup google.com
Server: 8.8.4.4
Address 1: 8.8.4.4 google-public-dns-b.google.com
Name: google.com
Address 1: 2404:6800:4005:c00::64
Address 2: 208.54.38.49 m312636d0.tmodns.net
Address 3: 208.54.38.48 m302636d0.tmodns.net
Address 4: 208.54.38.53 m352636d0.tmodns.net
Address 5: 208.54.38.57 m392636d0.tmodns.net
Address 6: 208.54.38.51 m332636d0.tmodns.net
Address 7: 208.54.38.54 m362636d0.tmodns.net
Address 8: 208.54.38.50 m322636d0.tmodns.net
Address 9: 208.54.38.59 m3b2636d0.tmodns.net
Address 10: 208.54.38.55 m372636d0.tmodns.net
Address 11: 208.54.38.52 m342636d0.tmodns.net
Address 12: 208.54.38.56 m382636d0.tmodns.net
Address 13: 208.54.38.58 m3a2636d0.tmodns.net
[email protected]:/ $ nslookup google.com 66.244.95.20
Server: 66.244.95.20
Address 1: 66.244.95.20 brian-vm.suso.org
Name: google.com
Address 1: 2404:6800:400a:803::1008
Address 2: 208.54.38.49 m312636d0.tmodns.net
Address 3: 208.54.38.48 m302636d0.tmodns.net
Address 4: 208.54.38.53 m352636d0.tmodns.net
Address 5: 208.54.38.57 m392636d0.tmodns.net
Address 6: 208.54.38.51 m332636d0.tmodns.net
Address 7: 208.54.38.54 m362636d0.tmodns.net
Address 8: 208.54.38.50 m322636d0.tmodns.net
Address 9: 208.54.38.59 m3b2636d0.tmodns.net
Address 10: 208.54.38.55 m372636d0.tmodns.net
Address 11: 208.54.38.52 m342636d0.tmodns.net
Address 12: 208.54.38.56 m382636d0.tmodns.net
Address 13: 208.54.38.58 m3a2636d0.tmodns.net
Because I'm blocking the 208.54.0.0/16 IP range in the iptables I can't connect to Google unless I use a direct IP like 74.125.228.3 for example.
Earlier today it started working correctly but soon went back to the way described in my first post.
I did a nslookup using two different DDNS servers.
When I run a traceroute, with or without the firewall enabled, it hops through T-Mobile's network then dies before even reach the T-Mobile tmodns.net Google server.
I'm just curious this of ordinary behavior for T-Mobile. I would rather directly connect to Google owned IP addresses.
Code:
[email protected]:/ $ su
traceroute -v google.com
traceroute to google.com (208.54.38.52), 30 hops max, 38 byte packets
1 10.170.227.192 (10.170.227.192) 36 bytes to (null) 236.960 ms 286.452 ms 269.902 ms
2 10.170.227.137 (10.170.227.137) 76 bytes to (null) 279.829 ms 319.824 ms 329.807 ms
3 10.162.37.124 (10.162.37.124) 36 bytes to (null) 269.846 ms 249.833 ms 259.821 ms
4 10.162.37.113 (10.162.37.113) 76 bytes to (null) 259.902 ms 279.785 ms 259.878 ms
5 10.170.205.11 (10.170.205.11) 76 bytes to (null) 659.813 ms 269.880 ms 259.800 ms
6 10.177.17.125 (10.177.17.125) 76 bytes to (null) 629.853 ms 269.756 ms 369.844 ms
7 10.177.26.106 (10.177.26.106) 36 bytes to (null) 329.907 ms 539.814 ms 683.135 ms
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *