SPGMNF@UCBCMSA.BITNET (Mike Friedman) (02/01/90)
Jay, I guess you're right. I tried my large 'loopback' file transfer again, this time watching NETSTAT INTERVAL. It appears no packets are being transferred on the data connection. Originally, I thought I could tell that packets were moving by looking at the 8232 statistics screen. I believed this represented my file transfer because no one else was on the system Sunday night. But now I realize that VMNET links had come up, so the 8232 packet traffic may well be attributable to that. So, if NETSTAT is to be believed, there is no data transfer going on. Why is this? As I said in an earlier note, if I connect to LOOPBACK, instead of cmsa.Berkeley.EDU, I have no trouble. Also, since putting the 8232 into production Sunday, I'm not aware of any file transfer problems between us and a different host. I hope this defines the problem a little better. Even more, I hope someone can suggest a solution. Thanks.
NJG@CORNELLA.BITNET (Nick Gimbrone) (02/04/90)
On Wed, 31 Jan 90 08:54:49 PST Mike Friedman said: >So, if NETSTAT is to be believed, there is no data transfer going on. >Why is this? As I said in an earlier note, if I connect to LOOPBACK, >instead of cmsa.Berkeley.EDU, I have no trouble. Also, since putting >the 8232 into production Sunday, I'm not aware of any file transfer >problems between us and a different host. LOOPBACK is a software transfer (the IP packets never leave the TCPIP server, who pretends to send them on the network and then pretends to recieve them from the network by simply moving the packet from the IP output queue to the IP input queue... basicly speaking...). Use of either the host name or IP address will cause the same code paths as use of another host name or IP address (i.e. IP packets actually hit the network attachment box). With both 7170s and 8232s (I don't know about other boxes) these packets will actually be sent on the real network and then recieved by the sender... So, could it be that you have a hardware problem with your 8232's network card? Some cards can't recieve data from themselves reliably... yet they can talk to others just fine... seems to match your symptoms. (Hum, must be a software type... blaming the hardware again! :-)
SPGMNF@UCBCMSA.BITNET (Mike Friedman) (02/05/90)
I have encountered the same symptom described earlier (cmsa <--> cmsa FTP crash). Only this time, it was when trying to download an RFC file from nic.ddn.mil. The data connection crashed with no packets transferred. However, in this case I only needed to try it once more for it to work. I'm sure the 8232 is somehow implicated, for the reason Nick mentions. As it happens, I had to move back to our DACU this weekend because the 8232 was just a loaner from another project. We're supposed to be receiving our new 8232 by the end of February, so I'll try all this again at that time.