James Newtons Massmind wrote:
> Hang in there... I'm still trying to figure out what to do.
> 
> Again, it is not, can not be, exclusively something that piclist.com is
> doing wrong. At worst, piclist.com is not willing to negotiate to a smaller
> packet size than 1500. But that is a perfectly valid size for a packet and
> should not be dropped by any node between here and there (as far as I can
> see, I have been known to be wrong before) and so must be the "fault" of the
> ISP or some node between me and you.

But the MTU limits the packet size. 1500 is just about the maximum
packet size possible (it's the physical limit for ethernet). Any node
between with a lower MTU will drop your packets, since they use DF,
and that is the proper behavior (there are links with MTUs of 600 or
less, and it is perfectly acceptable, although not optimal). Your
packets use DF because your server is attempting to do PMTU discovery,
so that hopefully dropped packets will be reported back and your
server will adjust the packet size. But if it doesn't work right,
you'll just kill all your packets.

> 
> It can NOT be piclist.com's "fault" because lots of other people can see the
> site just fine, reliably, quickly, and without fail. And EVERYONE can see
> the site via anonymizer or any of the other web proxy services.

Anyone with a 1500 MTU through all the path will always see your site.
But if your server is configured wrong, or your router, or something
at your end is breaking PMTU discovery, packets can get dropped
forever at places where the MTU is lower. I think it is not strange
for most people to have a 1500 path MTU, since it is the most optimal,
but some people might have smaller limits. And those might be broken.
Via anonymizer the connection is pretty much rewritten, since
everything goes out and back into the TCP stack at application level,
so if the anonymizer is configured properly and does PMTU properly,
and has a 1500 MTU path to your server, it will work for everyone.

> I have a linksys router on the front end of the server and it does not have
> much in the way of settings for MTU related issues. The only one is
> "automatic / manual MTU size" and if manual, then what size MTU. Currently,
> it is on automatic and it has been like that for years. So if there is a
> problem, it must be a bug in the linksys or some bug between the linksys and
> the NT 4 / IIS 4 server. So far, I can't find any mention of such a bug
> related to the linksys model I have on the internet or at the linksys site.
> However they do have a firmware update which I will apply as soon as I can
> make sure I have another unit ready to drop in if this one doesn't survive
> the firmware load.

If the problem is on your side, it is definitely a bug or big
misconfiguration. A question: is your server under a publicly routable
IP address directly, or does the router use a forwarding feature to
forward port 80 to the server? That might have something to do with it.

A quick test should be to turn off PMTU discovery and let NT4 unset
the DF bit. This is sub-optimal since it will cause packet
fragmentation for paths with a smaller MTU, but it will not cause any
additional load for your connection (since the packets get fragmented
at the router with a smaller MTU), and it might be an acceptable
long-term solution if nothing else fixes the problem. The site might
be 20% slower for those under lower-MTU connections, but I guess
that's better than not being able to access it at all.
-- 
Hector Martin (hector@marcansoft.com)
Public Key: http://www.marcansoft.com/hector.asc

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist