Messages in this thread | | | Date | Tue, 02 Jun 1998 17:22:53 -0700 | From | Barry Treahy <> | Subject | Problem with TCP |
| |
In a nutshell, I'm running 2.0.33 of Linux (just upgraded from 2.0.30 to see if the problem would go away and it didn't) on a Compaq 486 PC. For the past several months, I've been experiencing problems that I have been blaming on my HTTP server vendor to find out that it appears to be a Linux problem.
I have identified a hand full of files including a copy of VMLINUZ, several .GIF files, etc. that when I try and FTP them from this PC, and in the case of the .GIF files, the HTTP server tries to send them, the first 1k to 2k of the file is damaged... Why do I say that, I run TCPDUMP capturing the packets and compare the contents of the packets to the real file... TCP seems to think that the file is ok, because no retransmissions occur but the ftp client hangs, the web browser hang, etc...
I thought it might have been a kernel problem which is what prompted me to upgrade to 2.0.33. Now I have this problem server using the SW base 3.3, and other PC's running 2.0.33 which work with the the newer 3.4 SW base with the same .GIF files. Is it possible that there's a library that I have that's out of date and buggy that could be effecting both ftp and my HTTP server (which by the way is Roxen). I also know is not Roxen's fault because Apache does the exact same thing and the Apache logs show that the correct number of bytes have been send on the GET.
Another strange aspect of this problem is that even though I cannot successfully download these files from the server, I can upload the same files to it and when I perform a comparisons, they are identical.
I have very little hair left, so if ANY one can offer a suggestion, please do so...
Best regards,
Barry
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |