Everhart, Glenn From: Veli Körkkö [korkko@decus.fi] Sent: Thursday, June 25, 1998 10:26 AM To: Info-VAX@Mvb.Saic.Com Subject: Re: replacing multinet with ucx - URGENT... Jeff Schreiber wrote: > > In article <35912A4E.D8FE7BD7@decus.fi>, "Veli Körkkö" writes: > > TCPware also implements VMSplusmode but they are not exactly compatible > > with DEC. So, under certain conditions one gets problems. (UCX FTP > > client with TCPware FTP server, after one get next command hangs when in > > VMSplusmode). > > This problem was originally reported to us (PSC) back in the fall of '96, > to which I was the engineer that looked into it. It is not TCPware's > problem, it's a problem in the UCX FTP client (I'll explain). I reported > it to DEC, and I guess they never addressed it. > > The problem initially came up with TCPware 5.1-4 and UCX 3.3. The UCX > client would get a file, and then try to exit or quit and the client > froze. If you take a look at what is going on with the data (port 20) > connection, you will see that the UCX client never closes the data > connection. > > Looking at an example of the trace > 31:47.10 XMIT 40 bytes TCP26: 10.10.10.42,20 -> 10.10.10.41,1083 > FIN-WT-1 SEQ=643535937 D=0 ACK=200320001 W=32768 CTL=FIN!PSH!ACK > 31:47.10 RCVD 40 bytes TCP26: 10.10.10.41,1083 -> 10.10.10.42,20 > FIN-WT-1 SEQ=200320001 D=0 ACK=643535938 W=30716 CTL=ACK > 33:47.03 RXMT 41 bytes TCP26: 10.10.10.42,20 -> 10.10.10.41,1083 > FIN-WT-2 SEQ=643535937 D=1 ACK=200320001 W=32768 CTL=ACK > DATA=00 *.* > 33:47.03 RCVD 40 bytes TCP26: 10.10.10.41,1083 -> 10.10.10.42,20 > FIN-WT-2 SEQ=200320001 D=0 ACK=643535938 W=32768 CTL=ACK > > etc... > > As you can see. UCX never sends a FIN. > > (This is from the analysis that I made) > > If you fiddle around with the UCX client, you'll see that it > really isn't closing correctly at all..... Send the QUIT command > accross, and see what UCX does after and what TCPware does after. > > TCPware> FTP> quote quit > TCPware> 221 Service closing connection. > > UCX> FTP> quote quit > UCX> 221 Service closing connection. > > All looks well and good right? Well, lets look at what they really > _think_. > > TCPware> FTP> pwd > TCPware> %TCPWARE_FTP-W-NONODE, supply remote node information > UCX> FTP> pwd > UCX> 421 Service not available, Remote server has closed the connection > Hmm... curious... lets try that again: > UCX> FTP> pwd > UCX> %FTP-E-CONCNC, Control connection is not set up to remote host > > UCX never realized the connection was closed until it tried > something. On that first pwd after the close, take a look at what > UCX sent to TCPware: > > 58:15.44 RCVD 45 bytes TCP124: 10.0.0.41,1079 -> 10.0.0.13,21 > FIN-WT-2 SEQ=523136046 D=5 ACK=33294122 W=4096 CTL=PSH!ACK > DATA=50 57 44 0D 0A *PWD..* > 58:15.44 RCVD 40 bytes TCP124: 10.0.0.41,1079 -> 10.0.0.13,21 > FIN-WT-2 SEQ=523136051 D=0 ACK=33294122 W=4096 CTL=FIN!ACK > 58:15.44 XMIT 40 bytes TCP124: 10.0.0.13,21 -> 10.0.0.41,1079 > TIMED-WT SEQ=33294122 D=0 ACK=523136052 W=24576 CTL=ACK > > The UCX system neglected to actually close their side. To see this > even better.... lets try one last thing: > > FTP> quote quit > 221 Service closing connection. > FTP> open tcpware > %FTP-E-DISCON, Disconnect first; connection to tcpware.process.com > already exists > > Now if you disable VMS plus on the UCX system: > > FTP> DISABLE VMS_PLUS > > And then connect to a TCPware server, you will see that the UCX client > replies to the FIN!PSH!ACK with a FIN!ACK. > > - Jeff > > -- > Jeff Schreiber, Process Software Corp. > schreiber@mx.process.com http://www.process.com > TCPware & MultiNet: Stronger than Ever Jeff, I really cannot disagree with but neither can I disagree with me... I reported this somewhere around Jan 98 to PSC, got basically above mentioned explanation, went and reported to DEC. After long time and lots of time taking pushing, they finally claimed that a) VMSplusmode is DEC proprietary invention b) however they choose to implement it, it is their choice and they can have it their way. Other parties "cloning" VMsplusmode MUST implement their side to be compatible with DEC way. They (DEC) advised me to contact PSC again in order to get PSC product "fixed". Needless to say, DEC will not fix this and why would PSC fix something that is broken on the other end. Not exactly the best reply from DEC I would have expected. Now I have had one problem with UCX SMTP open for mere four months. Still no answer and if they finally will answer, I would not be surprised if it were "Internet is broken. Please contact Internet and fix it to be compatible with UCX SMTP." _veli