Xref: utzoo comp.os.vms:9207 comp.sys.hp:1130 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!hafro!krafla!marius From: marius@rhi.hi.is (Marius Olafsson) Newsgroups: comp.os.vms,comp.sys.hp Subject: Re: CMU IP/TCP V6.3 problem: uVAX <-> HP <-> HLH Orion Message-ID: <453@krafla.rhi.hi.is> Date: 6 Oct 88 22:13:02 GMT References: <2969@mva.cs.liv.ac.uk> Organization: University of Iceland Lines: 34 From article <2969@mva.cs.liv.ac.uk>, by keith@mva.cs.liv.ac.uk: > We have quite a major problem in getting HP 9000/300 equipment to talk > TCP/IP with a microVAX II running VMS V4.7 and CMU IP/TCP V6.3 over > ethernet. > > Basically, FTP and TELNET connections don't seem to last very long - the > microVAX aborts with TCP Receive errors. .. The CMU-TEK implementation periodically sends so-called "inactivity probes" over its connections to ascertain that the connection is still alive. It is our experience that HP-UX always aborts the connection upon receiving these probes. To quote from the CMU-TEK code: ............ Currently, we will send an unacceptable segment with SYN and ACK on with a bogus sequence number. According to the TCP spec, such a segment should either generate an ACK with the correct sequence numbers or should generate an RST if the connection does not exist. The problem is that HP-UX always generates RST. It would be nice if someone from HP could comment wether this is a case of different interpretation of the TCP spec or a bug in HP-UX. Anyway, there does not seem to be a way to turn this off in CMU-TEK, and the only way we had to make the HP-UX/CMU-TEK combination behave was to patch CMU-TEK to eliminate these "inactivity probes". Mail for details if anyone is insterested. Our config (11/780 VMS 4.7+CMU-TEK-6.3 HP-9000/840 HP-UX 1.2) -- Marius Olafsson Internet: marius@rhi.hi.is University of Iceland Non-MX: marius%rhi.hi.is@uunet.uu.net UUCP: {mcvax,enea,uunet}!hafro!rhi!marius