GilbertD@IUBio.Bio.Indiana.Edu (Don Gilbert) (02/06/90)
I am having problems with NCSA Telnet, the BYU modification, the MacTCP
version, release 2.3.1, over AppleTalk. The problem is that a telnet
session will freeze, usually during screen output of more that a few
lines. It will usually not unfreeze, but I can open another session to
the same computer account and the new session is okay, until I repeat the
output request that froze the last session (whatever it is, it is usually
repeatable).
This only occurs with Telnet/MacTCP via Appletalk. Telnet/MacTCP via
Ethernet works fine. Telnet/NOmactcp via Appletalk or ethernet work
fine. I configure the MacTCP appletalk for dynamic IP address allocation,
and that seems to work properly, as it does for NOmactcp. All of the
parameters in the Telnet config.tel file which might be the cause of this
problem seem to be ignored by the MacTCP version. The appletalk line I
am testing is "powered" by a MaxTalk beta test card for Access/1 from
Ungermann-Bass. This card acts like a Kinetics FastPath, and in the past
has shown some beta testing bugs, but they may be worked out now. The
symptoms I find (everything BUT TelNet/MacTCP/Appletalk works fine)
suggest it may be something in the software combination.
Can anyone else say if the NCSA(BYU) TelNet/MacTCP/Appletalk
combination has shown such problems?
Thanks, Don
Don Gilbert biocomputing office / archive for
gilbertd@iubio.bio.indiana.edu / molecular & general biology
biology dept., indiana univ., / ftp iubio.bio.indiana.edu
bloomington, in 47405, usa / (129.79.1.101) user anonymousdemarsee@ICARUS.CNS.SYR.EDU (Darryl E. Marsee) (02/06/90)
>Can anyone else say if the NCSA(BYU) TelNet/MacTCP/Appletalk >combination has shown such problems? We had a similar problem with freezing sessions on one of our AppleTalk nets using this combination (or using Brown TN3270 or Stanford MacIP in place of BYU Telnet). We use K-Star in combination with atalkad from KIP to administer IP addresses on our K-boxes, and our problem was caused by having static addresses defined for this AppleTalk net. Once we deleted the static addresses and had atalkad only allow dynamic addresses, everything worked fine. The culprit seems to be MacTCP, since using the non-MacTCP versions of BYU Telnet/Brown TN3270/Stanford MacIP did not show this problem when we allowed static addresses, but I have not investigated this further to determine if it is indeed MacTCP's fault.
rapatel@khnphwzhn.njin.net ( Rakesh Patel) (02/07/90)
I use NCSA 2.3 Telnet with MacTCP, and when going through a KFPS4 running K* 8.0, the same problem occurs with static addresses. I always used a static address (with the rest being dynamic) when I had a KFPS-2 running KIP. I didn't have this problem with MacTCP talking to KIP. It seems more likely to be a K* 8.0 problem than one with MacTCP. Does anyone see their telnet sessions hang when using MacTCP with static IP addresses when going through anything other than K*? Rakesh Patel.
brad@cayman.com (02/07/90)
>> Subject: Re: Telnet/MacTCP/Appletalk problem >> Message-Id: <Feb.6.16.54.00.1990.24767@khnphwzhn.njin.net> >> References: <9002061545.AA01125@icarus.cns.syr.EDU> >> Sender: info-appletalk-request@andrew.cmu.edu >> To: info-appletalk@andrew.cmu.edu >> >> I use NCSA 2.3 Telnet with MacTCP, and when going through a KFPS4 >> running K* 8.0, the same problem occurs with static addresses. I always >> used a static address (with the rest being dynamic) when I had a >> KFPS-2 running KIP. I didn't have this problem with MacTCP talking to >> KIP. It seems more likely to be a K* 8.0 problem than one with MacTCP. >> Does anyone see their telnet sessions hang when using MacTCP with >> static IP addresses when going through anything other than K*? I will offer a guess as to why this is happening (as the same problem occurs with a GatorBox). -- my humble opinion as to the cause -- Dynamically assigned IP addresses establish the appletalk address of the Macintosh host (the mac running MacTCP) at the time the address is assigned. This assignment is done via a sequence of ATP transactions. The address of the mac host is taken from the source of the ATP assign transaction. (so, as long as the host can find the gateway, it can be located anywhere on the appletalk internet) Once assigned, the validity of the address is "maintained" via NBP Confirm requests, which are sent directly to the appletalk address of the mac host. Statically assigned IP addresses establish the appletalk address of the Macintosh host by using "NBP ARP". This is a broadcast protocol. If the mac host is not in the same localtalk zone as the gateway, the address can not be verified and will time out. (this takes about 2.5 - 3 minutes as per the holy grail of the Croft KIP gateway code ;-) The point is that statically assigned addresses are not "maintained" at constant intervals like dynamically assigned addresses. -- editorial -- There are some easy ways to fix this - perhaps the behavioralism of the ip arp cache can be changed to notice appletalk based resolved addresses and before they time out, "verify them" with an arp resolve to "refresh" the entry. There is some work going on in the Macintosh IETF sub-sub-workgroup (it has some name like that - as a member, I am obligate to forget and incorrectly propagate the name ;-) to standardize the "Macintosh IP encapsulated in DDP" work that exists (KIP, KStar, GatorBox, Dartmouth gateway, Ungerman Bass, etc) Both Cayman and Kinetics have put out "white papers" on the "here and now" and the "why is should be" respectively. These will be available via anonymous ftp (if I ever get my butt in gear) -brad
rapatel@pilot.njin.net ( Rakesh Patel) (02/07/90)
The particular problem I had was with a localtalk connected Mac. Actually, the problem turned out to be MacTCP as pointed out by Steve Dorner from UIUC. In case people missed it yet again (I read the article the first time he posted, but I hadn't realized he was pointing out the same problem I had been having (as was everyone else)), here is his message: 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 T o o M u c h I n c l u d e d t e x t f e r n e t n e w s t o p o s t w i t h o u t a l l t h i s n o n s e n s e Rakesh Patel.