Connection (data) problem woes - Streak 5 Q&A, Help & Troubleshooting

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.

Related

GPRS Problems

Hello everybody
I'm using a T-Mobile MDA with a Radio ROM Version of 3.23.00.
I've got the problem of too much GPRS connections.
I wrote a little software (C#) which opens a connection into the internet and contacts a server. The data transferred contains informations about the current IP the radio received from my provider. I can see that the IP changes every 10 to 30 minutes (in steps of 10 minutes).
My question: does anyone know of any bug within the radio unit or its ROM which can be responsible for that amount of connections (about 25 to 30 connections per day)?
Thank you very much in advance.
Monty
EDIT (19.02.2007): Is there a possibility that the device itself turns off the phone module after an unused period? Does anyone of you know something about the reliability of the coorperation between the MDA I and GPS receivers?

Serious PEAP Wireless Problem (SK17i)

I've been having serious problem with Wifi on my SK17i when connected to the PEAP 802.11x wireless network at work.
At first I thought it was the wireless connection attempting to maintain too high a link speed but more testing suggests it's more fundamental than that.
What I've discovered is that I can set up an ICMP ping to the default gateway that will work fine as long as that is the only traffic but soon after I start transferring data outside the network the pings to the default gateway start failing (with the message ping: sendmsg: No buffer space available) and no network traffic goes anywhere over the wifi connection until I turn it off and on again, but if I do that then as soon as I start sending real data again the connection will collapse once more.
$ ping -c 50 10.4.0.1
ping -c 50 10.4.0.1
PING 10.4.0.1 (10.4.0.1) 56(84) bytes of data.
64 bytes from 10.4.0.1: icmp_seq=1 ttl=63 time=45.9 ms
...
64 bytes from 10.4.0.1: icmp_seq=28 ttl=63 time=31.7 ms
ping: sendmsg: No buffer space available
I've tested this with stock 4.0.2.A.0.58 (both rooted and unrooted) and CM7 FXP046.
Has anyone else seen anything similar or have any ideas what can be done about it (I've raised it as a bug with SE [though who knows if they'll even read it] and also on the Free Xperia issue tracker)
I use PEAP too, and I have not experienced problems with 4.0.2.A.0.58
That's very interesting...
Can you post your wpa_supplicant.conf (with ssid, id and password removed of course) to check which settings your connection is using ?

[Q] Question - Is an Android phone supposed to respond to a PING?

My Galaxy S2 with ICS is connected to my WiFi AP and has been allocated IP address 192.168.0.28.
The Galaxy has internet access so connectivity is not an issue.
However, if I try and ping the phone, I get "Destination Host Unreachable"
Does an Android phone respond to ping requests from other devices like a PC?
Can someone advise or try it?
Go to google play market and download net ping and try.
Sent from my GT-I9100 using Tapatalk 2
# IP Address Response Time TTL
= ========== ============= ===
1 No reply from host
2 192.168.1.101 726 ms 64
3 192.168.1.101 2 ms 64
4 192.168.1.101 2 ms 64
5 192.168.1.101 2 ms 64
6 192.168.1.101 2 ms 64
MistahBungle said:
# IP Address Response Time TTL
= ========== ============= ===
1 No reply from host
2 192.168.1.101 726 ms 64
3 192.168.1.101 2 ms 64
4 192.168.1.101 2 ms 64
5 192.168.1.101 2 ms 64
6 192.168.1.101 2 ms 64
Click to expand...
Click to collapse
Is this what you got when you pinged your phone from your PC?
Yes. 10 ch
pellajl said:
Is this what you got when you pinged your phone from your PC?
Click to expand...
Click to collapse

[Q] Can't connect to any Google services without first going through T-Mobile

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 * * *

Issues with TDLS (Tunneled Direct Link Setup) prevent use of vlc remote control

Hi,
I am just a Android user, but I believe my observations and questions are interesting and relevant to people in this forum.
I use a Samsung Galaxy A3 (2017) and wanted to use one of the many VLC remote control apps towards my Ubuntu computer that has a Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter (Lite-on). Unfortunately none of them worked. All had network issues. I tried different ports and also used several browsers to access the http server of vlc directly, but even the browser had issues: it basically kept synchronised for 4 or 5 seconds, then lost synch and recovered only after roughly 15 seconds just to loose synch again after 4 or 5 seconds.
I checked the TCP connection. It did not break down. However, every 4th or 5th GET request got delayed by around 14 seconds.
I digged into it and found out that the A3 sends a TDLS Setup Request to the QCA9565, gets a TDSL Setup Response and then sends a TDLS Setup Confirm which is replied by the QCA9565 with a TDLS Teardown. After that, the connection between the two hosts is dead for about 14 seconds.
Other hosts in the network did not have such issues, but as far as I can see, they are also not using TDSL. So I suspect that some issues with TDLS between my Samsung A3 and my Ubuntu machine regularly interrupt the local WiFi connection between the two.
So now my question: Is it somehow possible to disable TDLS on my Android phone? Or are there any vlc remote apps around that somehow suppress TDLS for such local WiFi communcation?
Thanks
Michael

Categories

Resources