Very interesting now. I booted up another VAX, also running 7.3, and I was able to FTP to that one no problem at all. I can telnet to the "bad" VAX no problem. Pinging is fine. I can use DECnet fine between both VAXen. I can ping between both VAXen. When you say run a packet capture on the VMS end do you mean run a sniffer program actually on the VAX? If so I don't know of any software for that, do you have a recommendation? I can run a sniffer on the PC, which is connected to the same switch (not a hub), as this is all on single segment. If I try to run UCX FTP on the good VAX to connect to the bad VAX this is what I get: FTP> conn 192.168.0.106 %TCPIP-E-FTP_NETERR, I/O error on network device -SYSTEM-F-REJECT, connect to network object rejected FTP> If I try the same thing from the bad VAX to the good one it works, but it takes a while to come up with the login prompt. The same long delay happens the prompt right away). There is definitely a problem with the "bad" VAX. It occurred to me there may be some errors of some kind, so I got some info as follows: TCPIP> sh int se0 /fu Interface: SE0 IP_Addr: 192.168.0.106 NETWRK: 255.255.255.0 BRDCST: 192.168.0.255 Cluster C_Addr: C_NETWRK: C_BRDCST: Ethernet_Addr: AA-00-04-00-07-04 MTU: 1500 Flags: UP BRDCST RUN MCAST SMPX RECEIVE SEND Packets 2226 115 Errors 0 0 Collisions: 0 TCPIP> sh prot ip: 0 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with header length < data size 0 with data length < header length 0 fragments received 0 fragments dropped (duplicate or out of space) 0 fragments dropped after timeout 0 packets forwarded 0 packets not forwardable 0 packets denied access 0 redirects sent 0 packets with unknown or unsupported protocol 0 packets consumed here 0 total packets generated here 0 lost packets due to resource problems 0 total packets reassembled ok 0 output packets fragmented ok 0 output fragments created 0 packets with special flags set icmp: 0 calls to icmp_error 0 errors not generated because old ip message was too short 0 errors not generated because old message was icmp Output histogram: echo reply: 12 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Input histogram: echo reply: 4 destination unreachable: 35 echo: 12 12 message responses generated tcp: 45 packets sent 18 data packets (373 bytes) 0 data packets (0 bytes) retransmitted 18 ack-only packets (8 delayed) 0 URG only packets 0 window probe packets 0 window update packets 9 control packets 44 packets received 22 acks (for 381 bytes) 4 duplicate acks 0 acks for unsent data 18 packets (271 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 packets with some duplicate data (0 bytes duped) 3 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet was too short 4 connection requests 3 connection accepts 6 connections established (including accepts) 7 connections closed (including 2 drops) 1 embryonic connection dropped 25 segments updated rtt (of 26 attempts) 2 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 2 keepalive timeouts 0 keepalive probes sent 1 connection dropped by keepalive udp: 35 packets sent 1405 packets received 0 incomplete headers 0 bad data length fields 0 bad checksums 0 full sockets 1405 for no port (1405 broadcasts, 0 multicasts) 0 input packets missed pcb cache TCPIP> Frankly I am mystified.... Regards Rob