I have a legacy server running Fedora 5 with networking problems - any file transfer that takes more than a second or two hangs at some point - it could be 2 seconds, it could be 30. This occurs with secure transfers rsync, sftp and publicly via http.

Curiously the problem seems to have got worse over the last few days (most web downloads were unaffected previously, but now most file downloads are impossible to complete - this is a problem!)

Not really knowing anything about networking, I'm at a loss as to how to go about fixing this - nothing appears in /var/log/messages, /var/log/secure or the web logs.

One thing that I think may be an issue is that the server is behind a really old netscreen-10 (10Mb/s, half duplex) firewall. I tried using ethtool to set the network card to half duplex 10Mb/s too (from it's previous setting of full duplex 100Mb/s) but to no avail.

There are a couple of other (windows) servers in the same network that seem to be ok

I suppose what I'm really asking is can anybody please give me some pointers on what to investigate?

Thanks for any advice!

Get on to the network with wireshark and see what you see. I found an arp issue on wifi with it last time.

Thanks. I did some capturing with tcpdump and imported into wireshark. I reproduced a failed transfer during the capture and at this point I get a load of TCP Dup ACK and Out-of-Order messages. I don't know a great deal about how to interpret this, but a bit of searching suggests this indicates packet loss - could a duplex mismatch be the cause of this? We're planning to change the old firewall soon, so hopefully that might help. Any other thoughts/suggestions very welcome.

Stuck TCP transfer usually indicate an MTU problem. Try decreasing your MTU using
and see if your TCP transfers are working. Then keep increasing the MTU up and up until you get to the maximum value that is still working.

Not the world's expert either, but I have just finished a networking module . . .

Data is split down and put in packets. when the packets are received, an ack is sent. If the ack is not received, they are resent after a time. The packets are given an order (a field in the rtcp header relates to the packet number), so that if they arrive as they might in a different order, they can be reassembled correctly.

a 'dup ack' should be one box complaining that you've already acknowledged that packet, why are you acknowledging it again, and indicates a tcp error.

out-of-order - that stuff happens, and I wouldn't expect the box to notify you.
an out-of-order type error (It _is_ an error, right?) could relate to a different sequence number? Each protocol adds it header & footer so the packet looks like
Ethernet, IP, Tcp, Data, Tcp, IP, Ethernet

It sounds to me like something is congenitally knackered in the comms. Divide & Conquer.
Can you get something else on the network, and set up
1. An ethernet data transfer
2. An ip data transfer using udp
3. A tcp/ip transfer
and repeat with the firewall. Or else post an error or two (not 500 pls)

With Fedora 5, you're so far back that I can't recommend anything except a reinstall. Keep /etc.

We just replaced the firewall and things are looking much better now, so it seems either something was screwed in the firewall or it was a problem with duplex mismatch.

Thanks for your responses - all useful info/suggestions.

Incidentally, I totally agree about a reinstall, but we're actually migrating services to a different infrastructure (one of the reasons why data transfers are quite important).