Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!bloom-beacon!snorkelwacker!usc!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!pequod.cso.uiuc.edu!dorner
From: dorner@pequod.cso.uiuc.edu (Steve Dorner)
Newsgroups: comp.protocols.appletalk
Subject: Re: RE> Telnet/MacTCP/Appletal
Message-ID: <1990Feb6.215548.13252@ux1.cso.uiuc.edu>
Date: 6 Feb 90 21:55:48 GMT
References: <9002061745.AA14595@oaunx1.CTD.ORNL.GOV>
Sender: news@ux1.cso.uiuc.edu (News)
Reply-To: dorner@pequod.cso.uiuc.edu (Steve Dorner)
Organization: University of Illinois at Urbana-Champaign
Lines: 92

In article <9002061745.AA14595@oaunx1.CTD.ORNL.GOV> Wolfgang_Naegeli.ED_TSRS@QM01.CTD.ORNL.GOV (Wolfgang Naegeli) writes:
>
>         Reply to:   RE> Telnet/MacTCP/Appletal
>>Can anyone else say if the NCSA(BYU) TelNet/MacTCP/Appletalk  
>>combination has shown such problems?
>
>I have a similar problem with freezing sessions in InterCon's
>TCP/Connect (which is based on NCSA Telnet)
>This happened using the MacTCP version.  I just switched to using the
>non-MacTCP version a few days ago, and haven't seen the problem recur,

I'm going to repost an article I posted a some time ago, because I think
some people missed it.  I've sent it to several people, and every one has
said it cured their problem, including one who uses EtherTalk (there must
be something wrong with Ethernet MTU's as well...).  It may or may not
be applicable to Kinetics boxes as well as Gatorboxes; I can't say.

When I posted it the first time, someone from Apple said, "Yeah, we know.
Fixed in the next version."  Since the next version isn't here, there may
still be a use for this hack.

> Date: Thu, 7 Dec 89 16:43:13 CST
> 
> We've found a problem with MacTCP.  Specifically, it advertises a bad
> TCP Maximum Segment Size (MSS) to some hosts that are not on the same
> class B subnet as our Gatorbox.
> 
> THE FACTS
> 
> Our setup is as follows:
> 
> gatorbox is on a class B subnet, 128.174.33.  Macintoshes are
> connected to the gatorbox by PhoneNet.  Pequod (a NeXT machine, but
> that doesn't matter) is also on 128.174.33.  Uxc (a 4.3bsd-tahoe VAX,
> but that doesn't matter, either) is on 128.174.5, a subnet a gateway
> or two away.
> 
> And this is what we found (by snatching packets off the ethernet):
> 
> To pequod, MacTCP advertised an MSS of 546.  Add 40 bytes for TCP/IP
> headers, and you wind up with a 586 byte IP datagram, which is the
> maximum possible ip datagram that can be forwarded on the PhoneNet. 
> And, in fact, pequod sent maximal packets of 586 bytes on its
> connections with MacTCP. So far, so good.
> 
> To uxc, however, MacTCP advertised an MSS of 576.  Add 40 bytes for
> TCP/IP headers, and you get a 616 byte IP datagram, which is TOO big.
>  Since gatorboxes don't fragment oversize IP datagrams, a packet that
> size will never be received by MacTCP, and the connection will
> eventually die. And this is exactly what we saw.  Connections worked
> fine until there was a lot of data to be sent to the Mac, at which
> point uxc sent a 616 byte datagram, and the connection died.
> 
> While we did not do packet analysis on all the connections, we saw
> hung connections to every single host we tried (11 different hosts,
> from many different vendors) that was on a subnet of 128.174, but NOT
> on 128.174.33. The only host on 128.174.33 worked fine, as did both
> the hosts we tried that were on totally different networks (i.e., not
> 128.174).
> 
> THE SPECULATION
> 
> MacTCP advertises too large an MSS to hosts which are on the same
> class B network, but not on the same class B subnet.  It advertises
> proper values to hosts either on the same class B subnet, or on
> entirely different networks.
> 
> THE HACK
> 
> Fortunately, a little disassembly and trial and error led to a patch
> that makes the problem go away.  Find the hex byte string
> "337c02040014" (at an offset of around 0x6500, give or take 0x200) in
> the MacTCP document, and change it to "337c01010014".
> 
> This has caused MacTCP to function adequately for our setup for all
> the hosts I tried.  I'm not POSITIVE what this patch does (I suspect
> it just nukes the MSS advertisement altogether, but I haven't
> verified that).  It resolves our problem, and I'll look no further.
> 
> THE REAL SOLUTION
> 
> 1. Apple needs to fix MacTCP to advertise the MSS correctly to
> different subnets.  This is the OPTIMAL fix, since IP fragmentation
> is unpleasant at best.
> 
> 2. Cayman needs to fix the GatorSoftware to fragment large IP
> datagrams.  (Michael Haag [from Cayman Technical Support] assures me
> Cayman has done so in the next release, due out 1Q90.)

--
Steve Dorner, U of Illinois Computing Services Office
Internet: s-dorner@uiuc.edu  UUCP: {convex,uunet}!uiucuxc!dorner