T-Mobile, please fix your gateways(en.blog.viclone.com)
en.blog.viclone.com
T-Mobile, please fix your gateways
http://en.blog.viclone.com/t-mobile-usa-fix-gateways/
7 comments
A lot of mobile providers have shitty transparent proxies on port 80 and ignore problems unless it affects a large customer base in a visible way. They often barf on any fuzzing of a protocol, such as using LF instead of CRLF in HTTP requests (which causes more than one provider to actually skip its authentication checks and allow any request)
Even when working as designed, they are often doing things like lossy recompression of your images. That's probably a helpful bandwidth saver for some people, but I'd prefer you just serve me the site I requested, thanks.
Unfortunately, English is not his first language.
I often see this touted as an excuse as to communication barriers. While it certainly addresses the seemingly incoherent sentences, it does not address a lack of necessary information. Regardless of your human language capability, you should have the ability to provide enough evidence of the problem you're stating, error outputs from logs, etc.
ESL point taken.
However, I think "getting 504 on different T-mobile devices when using 3/4G but not when on WiFi or using other carriers" is enough to describe the problem. If it the proxy that's returning a 504 there is not much that can be done besides checking apache logs and placing a call to OVH to make sure that all is kosher.
The first thing CSR should have tried was to try to open the domain in question on his T-Mobile device, no? Especially considering that this is not the first time that a domain is returning a 504 from T-Mobile network. No exactly an esoteric issue that requires domain side server logs to resolve. If CSR could open it then it was probably an issue with the client's APN config or something.
However, I think "getting 504 on different T-mobile devices when using 3/4G but not when on WiFi or using other carriers" is enough to describe the problem. If it the proxy that's returning a 504 there is not much that can be done besides checking apache logs and placing a call to OVH to make sure that all is kosher.
The first thing CSR should have tried was to try to open the domain in question on his T-Mobile device, no? Especially considering that this is not the first time that a domain is returning a 504 from T-Mobile network. No exactly an esoteric issue that requires domain side server logs to resolve. If CSR could open it then it was probably an issue with the client's APN config or something.
[deleted]
I recently gave Tmobile a try and they've made me regret it immensely. Every single customer-facing part of their web services (activation, account management, etc) is riddled with pants-on-fire bugs, and their phone support is terrible.
When I tried to activate my new account online, I got to a form for payment that was demanding I fill out fields that didn't exist on the page. This is insane from a major carrier. I then had to call in to activate, and after having me on hold for half an hour, they made me verify with one of those things where they want to know a nearby intersection from where you lived six years ago - which of course I couldn't answer. I hung up on that guy, called again, and they let me verify my card through my bank. And now that I had an account, I tried checking out their account management site, and it was so broken as to be nigh unusable. And then I found out like the OP that a noticeable amount of sites are broken or just plain unreachable on their network.
I now understand why they can offer such a great-sounding plan for $30/month.
When I tried to activate my new account online, I got to a form for payment that was demanding I fill out fields that didn't exist on the page. This is insane from a major carrier. I then had to call in to activate, and after having me on hold for half an hour, they made me verify with one of those things where they want to know a nearby intersection from where you lived six years ago - which of course I couldn't answer. I hung up on that guy, called again, and they let me verify my card through my bank. And now that I had an account, I tried checking out their account management site, and it was so broken as to be nigh unusable. And then I found out like the OP that a noticeable amount of sites are broken or just plain unreachable on their network.
I now understand why they can offer such a great-sounding plan for $30/month.
I've actually had really good experiences with T-Mo support. They have different tiers of "support" but if you get past what is essentially the "weed-out" tier, they are by far the nicest and most helpful telco support staff I've worked with.
I came from AT&T and can't compare T-Mo to much else. Do any of the telcos have what you would consider to be fantastic support?
I came from AT&T and can't compare T-Mo to much else. Do any of the telcos have what you would consider to be fantastic support?
Entirely possible I've just been unlucky. I should have maybe tried escalating. Virgin Mobile's service was good to me and their website at least worked even if it was simple, and Verizion was pleasant if overly expensive.
But when Tmobile forces me to call, which I was trying to avoid, because their web engineering is so completely terrible, and then I have to wait on hold for half an hour, and then the cust service guy acts like I'm a criminal when I'm going through all this pain to give them money - a saner person would've given up.
But when Tmobile forces me to call, which I was trying to avoid, because their web engineering is so completely terrible, and then I have to wait on hold for half an hour, and then the cust service guy acts like I'm a criminal when I'm going through all this pain to give them money - a saner person would've given up.
One thing I fail to understand is how they failed to inform me, with this magical new ETF refund feature that they have, that I couldn't preorder the new Sony Xperia straight from the website and get my ETF refund. Now I have to go trade both my old AT&T device and my new T-Mobile one back at the store and get a new new Xperia Z1S, even though their own website for device trade-in says nothing about this.
Ohoho, just wait until you need to go somewhere semi-rural, like a distant college town. The reception is SO BAD! You'll get 0 bars indoors, and maybe 1-2 bars of HSPA+ outside if you're lucky. Here in Charlottesville, VA, things are really, really bad.
That's actually the one part that's been great - well, aside from the price. I live in a pretty rural area. On Verizon you can't connect to 3G from my house, and can't even use voice unless you stand in front of a south-facing window. Tmobile gives a full 5 bars with very decent 3G speed. And it's not just around my house, the broad area is incredibly well covered.
I realize that's probably just local circumstances and I know Tmobile's network is a fair bit smaller, but I can't personally complain about that aspect.
I realize that's probably just local circumstances and I know Tmobile's network is a fair bit smaller, but I can't personally complain about that aspect.
I had a similar issue with T-Mobile and bogon filtering of 5.0.0.0/8:
http://www.wordsforreading.com/blog/2012/07/19/let-bogons-be...
http://www.wordsforreading.com/blog/2012/07/19/let-bogons-be...
That's crazy. Why isn't this a 5 minute fix that should be deployed "yesterday" already?!
Because they probably have tons of endpoints on the 5.0.0.0/8 range. BT does the same in the UK for their router management interfaces, just no a slightly different range.
That makes sense in a way. Wow, sucks to be them to have built their whole infrastructure on stolen IP addresses.
I wonder how their businesses would cope if for example facebook relocated to the 5.x.x.x range legitimately.
I wonder how their businesses would cope if for example facebook relocated to the 5.x.x.x range legitimately.
They might be using those IPs internally.
So... did that ever get fixed?
Seems like t-mobile has problems with routing to that data center / network segment ?!
Doing a little research on some internal tooling, I found an IP close to www.viclone.com (5.135.96.195), namely gemclotures.com (5.135.96.102) that is also unreachable over t-mobile's 4g connection (tried it myself).
They're both hosted by OVH.
Doing a little research on some internal tooling, I found an IP close to www.viclone.com (5.135.96.195), namely gemclotures.com (5.135.96.102) that is also unreachable over t-mobile's 4g connection (tried it myself).
They're both hosted by OVH.
Thanks. I am sure there quite a few IPs in that range probably belongs to OVH. I think the problem is on T-Mobile's end as some of the other people complaining about 504s were not hosted on OVH.
For the life of me, I cannot get an automatic monthly payment set up with T-Mobile. But at $30/month I'll continue to live with it!
I have the $30/5GB plan, and couldn't get auto payment to work via the web site after several tries. Finally I resorted to calling 611. Whatever the customer service agent did to my account finally made it stick.
Most large companies simply have no way to escalate a real bug report.
Most large companies simply have no way to escalate a real bug report.
Are they still offering this plan?
Yes: http://prepaid-phones.t-mobile.com/prepaid-plans
Only 100 mins talk time though, so its not for everyone.
Only 100 mins talk time though, so its not for everyone.
I got it working, but it's a huge PITA. Since their broken site keeps redirecting you to login, you need to stop the page before it finishes loading that JS. And do this for each of the ~4 screens in the flow.
I'd recommend just calling them ;)
I'd recommend just calling them ;)
Opening the site in Firefox avoided the redirect to login issue for me.
Really? of all my bills, T-mobile is the only one I could get set up automatically. It's beautiful. They never call me, I never call them, my phone just has internet.
Just confirming that it does actually work for someone
I hope everybody understand our deception. We were in front an investor showing our amazing solution and we found that anything from our servers was reachable. We couldn't make the demo, also We couldn't show the product in the pitch. We thought ours servers crash or something... Very bad experience. From that moment past almost 3 weeks and still it's not working.
We contacted OVH, we have the private cloud there, they checked everything with our team. They couldn't find anything. Then I asked to other T-Mobile users and saw that the problem only occurs under T-Mobile networks... We were very very clear in the post, but the few responses of solutions were like "did you read my problem?"
We contacted OVH, we have the private cloud there, they checked everything with our team. They couldn't find anything. Then I asked to other T-Mobile users and saw that the problem only occurs under T-Mobile networks... We were very very clear in the post, but the few responses of solutions were like "did you read my problem?"
I just went to viclone.com on my Nexus 5 via Tmobile LTE and it connected fine.... https://www.dropbox.com/s/c5s5pw4ydohhr4g/Screenshot_2014-01...
It might be because Nexus 5 is configured to connect through their IPv6 routing. (Not that viclone.com seems to have AAAA record, but it's looking like all traffic are routed through T-mobile's 6to4 so it might make a difference, too.)
It's a NAT64. 6to4 is for tunneling IPv6 packets over an IPv4 network.
Thanks for the correction. Those do get mixed up in my mind...
That seems to be the answer: if you set the APN on the Nexus 5 to IPv4, the site will fail to open, whereas on IPv6 it works.
Are people really expecting customer-support-representatives that normally deal with "my facebook doesn't post on my android-iphone" problems to decipher "It's such is routing of web cache that your DNS has.", "I've tried to use the phone as hotspot and connect via pc and iPad and didn't works."
(1) I think the problem was not unambiguously described.
I think that the user "rbianco" tried to convey that ICMP/ping and TCP connections to ports other than 80 worked quite well, only on port 80 was a connection redirected to a misbehaving/broken (not-so-)transparent proxy.
(2) The methods used to determine these facts, and to reproduce the observed problems were not described (or rather: information spread over several messages).
Some other user gave hints how to reproduce the behaviour with different invokations of curl, this, and maybe even a prepared test-file on the webserver for the support-staff to play with, would have been most useful.