> _However_... :) Sun is apparently reporting a major bug in Microsoft's
> implementation of the TCP/IP stacks, causing serious slowdowns. This is a
> newly reported bug; Sun says it'll release a fix soon.
I have witnessed this problem firsthand, shortly after the upgrade
of an SS10 from SunOS4.1.3 to Solaris 2.5.1 with a full patch cluster
Does anyone have a date on when these patches will become available?
I have found an item on the problem at:
AND, for the record,
MS won't take the blame for the bug, and won't provide patches
probably because lusers are too stupid or apathetic to install patches
on their toy computers, and MS knows that UNIX administrators
are a conscientious bunch and will patch to prevent complaints
from the clueless lusers who continue to use broken toys.
It saves MS the hassle, forces Sun to make a patch, and makes `em
look bad in the bargain :(
(and this is pure speculation only - I *love* * theories ;) ),
that MS broke the TCP/IP implementation they use
on purpose, to make www access to Sun servers look bad in
comparison to their own demented idea of a server.
Here is an excerpt of a posting from a discussion list I am on,
that delas with MS Netmeeting problems.
I assume the problems outlined in the post are the same as what we are
seeing with the Sun problem outlined here, and also in the post,
is a possible reason for it.
> Date: Tue, 08 Jul 1997 10:05:51 +0800
> Subject: [Oz-ISP] Problems with Microsoft Netmeeting.
> I wonder if anybody else has seen this problem....
> Last week sometime, we started getting messages from our clients saying
> that Netmeeting is no longer working for them.
> After a few hours of getting Netmeeting to work fine on our ethernet,
> and then dialing in, and it not working, and lots of sessions with
> Tcpdump, the following facts emerge:
> Fact number 1. We have a global MTU of 576 on all our PPP connections.
> Helps the slower machines (read Mac's and Win3.1) keep up with the data.
> Fact number 2. Microsoft, in their wisdom, send out the Netmeeting data
> in 1460 byte packets, and have the "Don't Fragment" flag set. So, our >
> term servers send the ICMP message back, and drop the packet. If this
> has just started in the last week or so, i don't know.
> I do know, that I haven't changed my system since then. And suddenly it
> just broke. I am still trying to figure out just _why_ Microsoft decided
> that voice data needs to be sent in 1460 byte packets, when Real Audio
> comes down fine in 290 odd byte packets.
> Now, according to my copy of Steven's, the biggest packet that should
> ever have the DF flag set, is 296 bytes. This is because the biggest
> packet a router _must_ be able to handle is 296 bytes. Anything else
> should be able to be fragmented.
> Is Microsoft rewriting the TCP/IP spec, and sort of forgetting to tell
> the rest of the world?
> Oh well, time to hack my kernel to 'clear' the DF flag on packets > 576
> on the way though. <smirk>. I can't see the reason to maintain a DF flag
> on voice traffic. Isn't the whole concept of TCP/IP sending packets of
> data that can (or can't) arrive in order (or not) that may (or may not)
> vary in size?
defghijklmnopqrstuvwxyz: What? No ABC?
Rachel Polanskis Kingswood, Greater Western Sydney, Australia
Witty comment revoked due to funding cuts