Wolfgang_Naegeli.ED_TSRS@QM01.CTD.ORNL.GOV (Wolfgang Naegeli) (02/07/90)
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) It happens both in Telnet sessions and while doing client FTP. I have not tried opening another session. I cannot close the session window, but the menus still seem to be active and when I select Quit, I usually get "The application TCP/Connect has unexpectedly quit (1)" or a system crash. 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, but as I say, I may just have been lucky. I have had a couple times since then when it quite after I told it to capture the session, but that may be an unrelated problem. I am running on a Mac II over LocalTalk KFPS-2U with K*Star and KIP (atalkad) on a MicroVAX (though I don't think the latter should make a difference since it is not really involved directly. I am using a static address. I hope this gives someone another clue what might be wrong. Wolfgang N. Naegeli Oak Ridge National Laboratory Internet: wnn@ornl.gov Bitnet: wnn@ornlstc Phone: 615-574-6143 Fax: 615-574-3895
dorner@pequod.cso.uiuc.edu (Steve Dorner) (02/07/90)
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
jln@acns.nwu.edu (John Norstad) (02/08/90)
We also have problems with MacTCP on our PhoneNet/FastPath 2U/K-STAR setup. We've observed frequent NCSA Telnet and Brown TN3270 hangs, and also frequent crashes of our QuickMail/StarNine server. We do not have any problems with the exact same software running on Macs directly connected to Ethernets. Thanks to Steve Dorner for his bug report and hack fix - I'll try it out here. Hope it helps. I used Mac debugging tools to isolate the cause of our QuickMail/StarNine server crashes, and it was indeed a bug in MacTCP involving NBP confirm replies coming back from the FastPath 2U during receipt of incoming mail by the StarNine bridge. I wasn't able to figure out any way to fix the problem myself with a patch (there's some sort of buffer pool that was empty, and MacTCP was writing incoming data all over low core). I informed Apple (in excruciating detail) of the bug, and was assured that a fix would be available "real soon now". That was several months ago, and we're still waiting, of course... We have a new true FastPath 4 to replace our 2U, and there's some conjecture that installing the 4 will help, but I don't hold out much hope. I think the real cause of our problem is bugs in MacTCP. (I tried to install the FastPath 4 yesterday, but being the worthless hunk of metal that it is, I couldn't get it to work - I almost drop-kicked it into Lake Michigan :-) All of this recent TCP/IP networking software for the Mac is truly wonderful. Too bad it's still beta :-) We set a new record yesterday - our QuickMail/StarNine server crashed 21 times. I use MacMH for my mail - quess why :-). I've got some smiley faces above, but this is really a serious problem. We'd very much like to aggressively promote this new technology all over campus here at NU, but we can't until it's much more robust. John Norstad Northwestern University jln@acns.nwu.edu