MeFi, meet T-Mobile. T-Mobile, MeFi. February 17, 2009 4:10 PM Subscribe
Apparently MetaFilter and my cellular internet connection aren't playing nice with each other. Is it me or is it MeFi?
Whenever I try to bring up MetaFilter, including any of the subsites, via my T-Mobile EDGE connection and a tethered laptop, I get an "HTTP ERROR: $CODE$" message. It doesn't happen on any other sites (including the status blog), and I can ping the site's IP address.
The problem seems to occur at the point where Firefox says "waiting for www.metafilter.com" at the bottom of the window.
It started happening intermittently last week or the week before, and I was just ignoring it and hoping it would resolve itself, but now it seems to be doing it quite reliably.
Has anyone else experienced this? I can get around it by running an SSH tunnel to another machine and port forwarding through that, but it's quite slow. If it's T-Mobile's fault I'm more than happy to call them and give them hell, but it seems odd it'd be just MetaFilter that's affected.
This is all on Windows XP and Firefox 3.0.6, with a Nokia E61i running the JoikuSpot gateway package.
Whenever I try to bring up MetaFilter, including any of the subsites, via my T-Mobile EDGE connection and a tethered laptop, I get an "HTTP ERROR: $CODE$" message. It doesn't happen on any other sites (including the status blog), and I can ping the site's IP address.
The problem seems to occur at the point where Firefox says "waiting for www.metafilter.com" at the bottom of the window.
It started happening intermittently last week or the week before, and I was just ignoring it and hoping it would resolve itself, but now it seems to be doing it quite reliably.
Has anyone else experienced this? I can get around it by running an SSH tunnel to another machine and port forwarding through that, but it's quite slow. If it's T-Mobile's fault I'm more than happy to call them and give them hell, but it seems odd it'd be just MetaFilter that's affected.
This is all on Windows XP and Firefox 3.0.6, with a Nokia E61i running the JoikuSpot gateway package.
Not just you. On-T-mobile as well. help!
posted by Space Kitty at 4:38 PM on February 17, 2009
posted by Space Kitty at 4:38 PM on February 17, 2009
I'm not experiencing this on T-Mobile right now, but I used to see it on my Helio Ocean.
posted by katillathehun at 4:44 PM on February 17, 2009
posted by katillathehun at 4:44 PM on February 17, 2009
We've had reports of this same problem over on Fuelly, and it's still a mystery to us. I did some Googling around for "HTTP ERROR $CODE$" I found a few possible solutions. But I don't have a T-Mobile device to check.
I'm not aware of anything we're doing on this end that would cause the problem. But if there's something we can do, we'll do it.
posted by pb (staff) at 4:44 PM on February 17, 2009
I'm not aware of anything we're doing on this end that would cause the problem. But if there's something we can do, we'll do it.
posted by pb (staff) at 4:44 PM on February 17, 2009
There have been intermitten periods recently where the (the database?) server would time out and the HTTP server would return an error message saying that the request couldn't be fulfilled within the specified time. I've seen that a lot of times.
I wonder if that's what's happening to you, and the strange error that MeFi has returned in those cases is being displayed funny by T-Mobile.
posted by Chocolate Pickle at 4:56 PM on February 17, 2009
I wonder if that's what's happening to you, and the strange error that MeFi has returned in those cases is being displayed funny by T-Mobile.
posted by Chocolate Pickle at 4:56 PM on February 17, 2009
I don't think so, since we've had reports of this over at Fuelly for some time now.
posted by pb (staff) at 4:58 PM on February 17, 2009
posted by pb (staff) at 4:58 PM on February 17, 2009
It's just you. Really. It's always just you in every circumstance, every time, without fail.
posted by dawson at 5:52 PM on February 17, 2009 [1 favorite]
posted by dawson at 5:52 PM on February 17, 2009 [1 favorite]
I checked and I'm already using the "internet2.voicestream.com" APN and not the "wap" one. (I'm paying for the real internet service too, which allows tethering, not squeaking by on the $6/mo WAP plan either.)
The only theory I've come up with, and I'm just sort of tossing this out here to let other people poke at, is that it's something to do with MTU fragmentation. I did some ping tests and the maximum that gets through outbound (from me to Metafilter.com) is an MTU of 1500 (payload of 1472b).*
That by itself is not bad, at least I don't think so; I'm pretty sure 1500 is a common MTU. But when I try taking off the "do not fragment" option and use a payload bigger than 1472b (implying that the packets are going to get fragmented), I just get "request timed out." This seems to suggest that somewhere along the line, someone is deep-sixing fragmented packets and being sneaky about it. Right?
So here's my theory: if Metafilter's server(s) are set to use an MTU >1500, then its packets back to me are probably getting fragmented, and thus discarded by the crummy router. That would explain why everything seems to go okay until my computer starts waiting for a response from Metafilter, and then times out.
So...what's Metafilter's outbound MTU? If it's already 1500 or smaller, so much for my theory.
* I tested this by doing "ping -f -l n metafilter.com" where n varied until I got "needs to be fragmented" messages. If this is not a good test method let me know what's preferable.
posted by Kadin2048 at 6:06 PM on February 17, 2009
The only theory I've come up with, and I'm just sort of tossing this out here to let other people poke at, is that it's something to do with MTU fragmentation. I did some ping tests and the maximum that gets through outbound (from me to Metafilter.com) is an MTU of 1500 (payload of 1472b).*
That by itself is not bad, at least I don't think so; I'm pretty sure 1500 is a common MTU. But when I try taking off the "do not fragment" option and use a payload bigger than 1472b (implying that the packets are going to get fragmented), I just get "request timed out." This seems to suggest that somewhere along the line, someone is deep-sixing fragmented packets and being sneaky about it. Right?
So here's my theory: if Metafilter's server(s) are set to use an MTU >1500, then its packets back to me are probably getting fragmented, and thus discarded by the crummy router. That would explain why everything seems to go okay until my computer starts waiting for a response from Metafilter, and then times out.
So...what's Metafilter's outbound MTU? If it's already 1500 or smaller, so much for my theory.
* I tested this by doing "ping -f -l n metafilter.com" where n varied until I got "needs to be fragmented" messages. If this is not a good test method let me know what's preferable.
posted by Kadin2048 at 6:06 PM on February 17, 2009
MetaFilter: if there's something we can do, we'll do it.
posted by Rock Steady at 6:27 PM on February 17, 2009
posted by Rock Steady at 6:27 PM on February 17, 2009
I just tried from my phone which I know has worked in the past. I'm getting the same thing. I noticed this weekend that T-mobile was having problems. I started looking around because ESPN was coming up with the same sorts of errors and I was trying to settle an argument about an NBA player's stats.
FWIW - ESPN is working today, I just checked, and I know it was working earlier today when I was in an incredibly boring meeting.
posted by togdon at 6:54 PM on February 17, 2009
FWIW - ESPN is working today, I just checked, and I know it was working earlier today when I was in an incredibly boring meeting.
posted by togdon at 6:54 PM on February 17, 2009
...if there's something we can do, we'll do it.
Tell my wife I said "hello".
posted by turgid dahlia at 7:24 PM on February 17, 2009 [1 favorite]
Tell my wife I said "hello".
posted by turgid dahlia at 7:24 PM on February 17, 2009 [1 favorite]
There have been previous metatalk threads about MTU problems with metafilter
posted by empath at 7:30 PM on February 17, 2009
posted by empath at 7:30 PM on February 17, 2009
Kadin2048: "Apparently MetaFilter and my cellular internet connection aren't playing nice with each other. Is it me or is it MeFi?"
Maybe it's your detergent. Have you tried all-tempa Cheer?
posted by not_on_display at 7:33 PM on February 17, 2009
Maybe it's your detergent. Have you tried all-tempa Cheer?
posted by not_on_display at 7:33 PM on February 17, 2009
The weirdest part is that the error message comes from the tmobile network, so I would suspect it could be a network transport kind of error. Nothing on the mefi box spits out cryptic HTTP $CODE errors, so it's probably us, but sounds like it's Tmobile stepping in somewhere along the way to interrupt the transmission for one reason or another.
On the weird MTU front, we have a new cisco router in front of the servers, but I don't get any real interface to it, I merely request that certain ports are open to the world, and the rest is all blocked. If MTU is adjustable, I guess I could ask them to up it or something (or lower it? I forget what would fix it).
posted by mathowie (staff) at 8:21 PM on February 17, 2009
On the weird MTU front, we have a new cisco router in front of the servers, but I don't get any real interface to it, I merely request that certain ports are open to the world, and the rest is all blocked. If MTU is adjustable, I guess I could ask them to up it or something (or lower it? I forget what would fix it).
posted by mathowie (staff) at 8:21 PM on February 17, 2009
Can you change MTU in Shunra? Surely there's a good WAN emulator that can replicate this.
posted by geoff. at 8:45 PM on February 17, 2009
posted by geoff. at 8:45 PM on February 17, 2009
Having the same problem on my (non-EDGE) tmobile connection. Interestingly, I can load this page (I'm posting via my tethered phone), but not the front page. After messing with ping parameters for a while I don't think it's a MTU problem. My best guess is that tmobile has some sort of transparent proxy or something going on which can't handle the front page.
Here's what comes out of "curl -i http://www.metafilter.com/":
posted by hattifattener at 8:55 PM on February 17, 2009
Here's what comes out of "curl -i http://www.metafilter.com/":
HTTP/1.1 500 Internal Server Error Content-Length: 1141 Connection: close <html> <head> <title>Error 500 Internal Server Error</title> </head> <body> <h2>HTTP ERROR: $CODE$</h2><pre>$MESSAGE$</pre> <p>RequestURI=/</p>followed by about 50 blank lines and </body> </html>.
posted by hattifattener at 8:55 PM on February 17, 2009
Also the HTTP response headers of this page are subtly different between tmobile and my dsl connection. Unless mefi's server decides whther to put a space between the content type's semicolon and the following parameter depending on the client's address, and also changes the order of header lines based on the client address, then I think there's a transparent proxy in there. (I'm using the internet2.voicestream.com APN, not the wap one.)
posted by hattifattener at 9:03 PM on February 17, 2009
posted by hattifattener at 9:03 PM on February 17, 2009
huh. yeah, we serve up the same page for every client. Sounds like something about the page is choking T-Mobile's proxy.
That error message and HTML is all from T-Mobile. We don't serve anything like that. Our code is all ColdFusion so the $VARIABLE$ stuff is from a completely different system.
posted by pb (staff) at 9:13 PM on February 17, 2009
That error message and HTML is all from T-Mobile. We don't serve anything like that. Our code is all ColdFusion so the $VARIABLE$ stuff is from a completely different system.
posted by pb (staff) at 9:13 PM on February 17, 2009
One work-around we came up with at Fuelly that seemed to work: open the page with Google's Mobile Proxy: MeFi via Google Mobile. Normally I stay away from the Google Mobile Proxy like the plague because it mangles our HTML, but it might a temporary way to get around this problem.
posted by pb (staff) at 9:31 PM on February 17, 2009 [1 favorite]
posted by pb (staff) at 9:31 PM on February 17, 2009 [1 favorite]
Very interesting. I wonder what T-Mobile's up to with the transparent proxy...caching, maybe?
I can't seem to bring anything up by linking directly to thread pages instead of the front page, but I do get a different error message (504 Gateway Timeout) so I think that suggests my idea of it being MTU-related was wrong.
I submitted a question to T-Mobile's customer support and will let everyone know if I hear anything back in writing. (I'm not holding my breath; they have the best support of any cell phone company I've worked with, but they're still a cell phone company.)
posted by Kadin2048 at 9:44 PM on February 17, 2009
I can't seem to bring anything up by linking directly to thread pages instead of the front page, but I do get a different error message (504 Gateway Timeout) so I think that suggests my idea of it being MTU-related was wrong.
I submitted a question to T-Mobile's customer support and will let everyone know if I hear anything back in writing. (I'm not holding my breath; they have the best support of any cell phone company I've worked with, but they're still a cell phone company.)
posted by Kadin2048 at 9:44 PM on February 17, 2009
Are you using Opera Mini? Because that's definately proxy'ing.
posted by blue_beetle at 10:31 PM on February 17, 2009
posted by blue_beetle at 10:31 PM on February 17, 2009
(blue_beetle: I'm just switching my laptop back and forth between wifi-to-my-dsl and bluetooth-to-my-phone, and using the same browser / curl invocation both times.)
posted by hattifattener at 10:53 PM on February 17, 2009
posted by hattifattener at 10:53 PM on February 17, 2009
Have you tried rebooting? I assume this will be helpful, as it is what my IT staff tells me whenever I report a problem, such as electrical fires.
posted by Skot at 12:25 AM on February 18, 2009 [3 favorites]
posted by Skot at 12:25 AM on February 18, 2009 [3 favorites]
If it's the MTU, someone might try pinging the different steps on the route with the different packet sizes to see where results change.
posted by Pronoiac at 2:08 AM on February 18, 2009
posted by Pronoiac at 2:08 AM on February 18, 2009
Very interesting. I wonder what T-Mobile's up to with the transparent proxy...caching, maybe?
You can get proxy servers which will mess with requested pages to reduce bandwidth requirements. For example, removing white space and comments from HTML pages, re-compressing JPEGs at lower quality settings, applying gzip compression, and so on.
But if there's something we can do, we'll do it.
How difficult would it be to get SSL access set up? Secure connections don't get messed with by most proxy servers, as it isn't possible to decode the encrypted connection.
posted by Mike1024 at 5:51 AM on February 18, 2009
You can get proxy servers which will mess with requested pages to reduce bandwidth requirements. For example, removing white space and comments from HTML pages, re-compressing JPEGs at lower quality settings, applying gzip compression, and so on.
But if there's something we can do, we'll do it.
How difficult would it be to get SSL access set up? Secure connections don't get messed with by most proxy servers, as it isn't possible to decode the encrypted connection.
posted by Mike1024 at 5:51 AM on February 18, 2009
Setting up SSL for every site would be a pain, and it doesn't make sense for us to take on the extra processing of potentially serving every page via SSL to route around a T-Mobile bug. login.metafilter.com is a secure connection, so you can test with that at least.
posted by pb (staff) at 7:00 AM on February 18, 2009
posted by pb (staff) at 7:00 AM on February 18, 2009
Using Opera Mini on my T-Mobile BlackBerry has been hit and miss the last couple of weeks for accessing the site. Mainly around the server change-out (obviously) but sporadically after that as well.
The last few days have been fine though. While troubleshooting, I toggled between using the EDGE connection and WiFi, but I couldn't get a consistent enough failure to provide anything more than anecdotal data.
I wonder if I'm running through a different T-Mobile proxy than Kadin2048.
posted by quin at 8:12 AM on February 18, 2009
The last few days have been fine though. While troubleshooting, I toggled between using the EDGE connection and WiFi, but I couldn't get a consistent enough failure to provide anything more than anecdotal data.
I wonder if I'm running through a different T-Mobile proxy than Kadin2048.
posted by quin at 8:12 AM on February 18, 2009
It's just you. Really. It's always just you in every circumstance, every time, without fail.
Every day, in every way, I am the one with the problem.
[repeat]
Every day, in every way, I am the one with the problem.
[repeat]
Every day, in every way, I am the one with the problem.
[repeat...]
posted by slogger at 8:20 AM on February 18, 2009
Every day, in every way, I am the one with the problem.
[repeat]
Every day, in every way, I am the one with the problem.
[repeat]
Every day, in every way, I am the one with the problem.
[repeat...]
posted by slogger at 8:20 AM on February 18, 2009
T-Mobile's transparent proxy has had this issue on MeFi, Fuelly, and a few other sites for me. It's definitely an issue with that system. I got around it on my phone by using Opera Mini, as all of their access goes through the Opera server which doesn't seem to get proxy-blocked.
posted by mikeh at 11:59 AM on February 18, 2009
posted by mikeh at 11:59 AM on February 18, 2009
Have you tried rebooting? I assume this will be helpful, as it is what my IT staff tells me whenever I report a problem, such as electrical fires.
I think we must outsource to the same place.
Anyway, I can hit the login page over HTTPS, but can't get to anything else, so I think it's definitely a proxy in there somewhere, meddling with things.
I sent an email to T-Mobile and got a (not particularly) helpful canned reply asking me to try turning my phone on and off, pull the SIM out and replace it, etc. It basically said to get anywhere else beyond this, I have to call customer service, so I'll try to do that next week or over the weekend. I pay enough for their mobile Internet service that I'm not entirely pleased that they've got a badly-behaving transparent proxy breaking things left and right. I'm sure they have legitimate reasons for running it (edge caching is, in general, a good thing when it's done properly) but it's worse than useless when it does crap like this.
In the meantime I'll keep using SSH and FoxyProxy. (For the unfamiliar: if you have a server or other machine somewhere, you can open a connection to it with the "SOCKS port forwarding" or -D option, and then tell your browser to use your own computer as a proxy; this pushes all web traffic through the tunnel. It adds over 1s to the roundtrip ping, in my case, however.)
It would be nice if we could get everything over HTTPS, but I understand that's kind of a draft-horse-size pony, and is probably just not practical.
posted by Kadin2048 at 6:49 PM on February 19, 2009
I think we must outsource to the same place.
Anyway, I can hit the login page over HTTPS, but can't get to anything else, so I think it's definitely a proxy in there somewhere, meddling with things.
I sent an email to T-Mobile and got a (not particularly) helpful canned reply asking me to try turning my phone on and off, pull the SIM out and replace it, etc. It basically said to get anywhere else beyond this, I have to call customer service, so I'll try to do that next week or over the weekend. I pay enough for their mobile Internet service that I'm not entirely pleased that they've got a badly-behaving transparent proxy breaking things left and right. I'm sure they have legitimate reasons for running it (edge caching is, in general, a good thing when it's done properly) but it's worse than useless when it does crap like this.
In the meantime I'll keep using SSH and FoxyProxy. (For the unfamiliar: if you have a server or other machine somewhere, you can open a connection to it with the "SOCKS port forwarding" or -D option, and then tell your browser to use your own computer as a proxy; this pushes all web traffic through the tunnel. It adds over 1s to the roundtrip ping, in my case, however.)
It would be nice if we could get everything over HTTPS, but I understand that's kind of a draft-horse-size pony, and is probably just not practical.
posted by Kadin2048 at 6:49 PM on February 19, 2009
I followed up with T-mobile today, and inevitably they said it was a website problem. Anyone else have any luck?
posted by Space Kitty at 9:37 PM on February 24, 2009
posted by Space Kitty at 9:37 PM on February 24, 2009
I checked, & Kadin2048's "ping -f -l n metafilter.com" equivalent on Ubuntu is probably "ping -s n metafilter.com".
The probable last step before metafilter.com - ee.fe.5746.static.theplanet.com (70.87.254.238) - is the last step seen by traceroute & tracepath ... hang on.
Pinging that IP address with packet length 1465 gets " Frag needed and DF set (mtu = 1492)," but that's from my local router. Packet length 1464 gets no response. Oh. Routers in the theplanet.com network usually ignore direct pings.
www.metafilter.com responds to ping (packet length 1464), & mtr (using ICMP ECHO packets, packet length up to 1492, but that's likely 28 bytes of header that isn't being counted).
So, uh, check the MTU on the server & make sure it's 1464 or 1492 or something? Disable path MTU discovery?
Eh, I'm done thinking about this for now.
posted by Pronoiac at 11:59 PM on February 24, 2009
The probable last step before metafilter.com - ee.fe.5746.static.theplanet.com (70.87.254.238) - is the last step seen by traceroute & tracepath ... hang on.
Pinging that IP address with packet length 1465 gets " Frag needed and DF set (mtu = 1492)," but that's from my local router. Packet length 1464 gets no response. Oh. Routers in the theplanet.com network usually ignore direct pings.
www.metafilter.com responds to ping (packet length 1464), & mtr (using ICMP ECHO packets, packet length up to 1492, but that's likely 28 bytes of header that isn't being counted).
So, uh, check the MTU on the server & make sure it's 1464 or 1492 or something? Disable path MTU discovery?
Eh, I'm done thinking about this for now.
posted by Pronoiac at 11:59 PM on February 24, 2009
The same thing is happening to me! Metatalk works but nothing else on metafilter. This is through my tmobile connection tethered with joikuspot to my laptop.
posted by Salamandrous at 8:42 AM on March 1, 2009
posted by Salamandrous at 8:42 AM on March 1, 2009
You are not logged in, either login or create an account to post comments
posted by Doofus Magoo at 4:35 PM on February 17, 2009 [3 favorites]