PCbanter - View Single Post

**Paul[_32_]** · January 1st 18, 07:26 PM posted to microsoft.public.windowsxp.general

wrote:
I am having a problem uploading to 2 web sites I maintain at Web.Com
Small files, 30kb or less go ok but I get an error Web,.com calls a
time out when the file gets much larger than that .Web says it is not
their problem. It fails on multiple PCs here using multiple FTP
clients using Century Link DSL but dial up works OK. It also works if
I take my lap top anywhere else, even the DSL customer right next
door. I have plugged the DSL modem right into the Dmark with no joy.
All other internet operations are OK including Emailing a large file
or posting it on usenet.
Speed tests range from 10m down/ 700k up to about a 3d of that using
different test sites. DSLreports seems to be the slowest.
Any ideas?
I am thinking it has to be something with the actual wire going to the
big silver box up the street that passes as a "central office" or the
IP address I am using. Nothing else is common.
Is there an easy to force an IP address change?
Is it possible that I am just getting so many line errors that the FTP
server gives up? Maybe the "fast" test sites only count bits, not good
packets. Are errors logged anywhere?

Can you ping the FTP server ?

In a regular Command Prompt

ping ftp.someserver.com

and see whether ICMP is enabled on the server.

Some server operators want the additional security of
preventing ordinary users like you, from using ping
(ping has a variable length payload, and large large
packets have been used in the past, to tip over servers).

Now, ICMP supports ping, but it also supports other
more important things. If you do a poor job on a server
of disabling all of ICMP, something funny happens.

When you set up your router, it has an MTU, a maximum transfer unit
or the like.

If you offer a packet bigger than the MTU, then the "thing"
upstream says "your packet is too big, make it smaller".
And then the source must fragment the packet, so it
fits through the "tightest part" of the pipe.

When the server entirely disables ICMP, that mechanism is
also defeated. And the neat thing is, the TCP protocol
is "totally OK with this". If a too fat packet goes up
the pipe, *both* ends of the link are happy, and they
sit there waiting for the other end to respond. They
would sit there forever, unless an application level timer
detects "something is goofy here" and drops the connection.

I had this problem one day with my ISP and their email.
I could send a 1KB email message. If I made the email
too long, such that it took approximately two packets
to send, the transmission would jam up. My email program
wasn't expecting this kind of protocol failure. And the
connection would sit there "up and frozen", until I exited
the email program.

When I phoned the ISP, they said "why don't you change the
MTU on your router". As if users sit around all day, fixing
****ups caused by the ISP. I had managed to figure out the
symptoms were a "black hole" routing problem, but the
staff at the ISP support desk, refused to admit what
they'd done. Basically "it was all my problem that my
MTU setting was too big", not "we're sorry we made a mess of
ICMP on our email server, how about a $25 discount
on your next bill". Anyway, once I had that kind
of "belated admission of guilt" on their part,
I then had a couple options for correcting the
MTU on my end. And I no longer use those clowns,
so it doesn't matter any more :-)

*******

Your symptoms don't entire match. You got too much
data through before it broke. My point in giving
that rundown, is to point out that "not ever problem
is a broken wire on your street". Some problems are
actually caused by bad configurations, inadvertent
MTU choices (using a VPN changes the MTU), and so on.
Even if your neighbor has working DSL, that doesn't
mean that the entire LAN (configs and all) in your house,
matches the neighbor. There can be any number of
subtle differences, including whether maybe you
used a "TCP tuner" on the PC that is failing.

I don't have the skills to suggest what to try next,
and this anecdote is a reminder to keep an open mind.
Don't go running down the street plugging your
modem/router into the spigot on all the
neighbors. The problem lies elsewhere.

If you can do any kind of lengthy download, or even
an upload to virustotal.com, that should be sufficient
proof "it's not a wire problem". Virustotal.com accepts
uploads for virus scanning, when ever you send them a
file they've never seen before. You can use your
imagination to make something they don't have.

dd if=/dev/random of=mytestfile.exe bs=1048576 count=10

That would make a nice 10MB file for upload testing. Change
the length if you need to do a second test case, and so on.

Paul