Find the answer to your Linux question:
Results 1 to 7 of 7
When someone tries to download a file from my server, the download sometimes (about 1 in 30 times) completely stalls somewhere during the first ~25kb. It does not appear to ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Aug 2008
    Posts
    6

    iptables problem(?): stalling downloads


    When someone tries to download a file from my server, the download sometimes (about 1 in 30 times) completely stalls somewhere during the first ~25kb.

    It does not appear to be dependent on server application: it happens both with resin and apache.

    I sniffed a stalling download at the server with wireshark (dump here ). You'll see the client keeps ack'ing 5473, which means it has received all data up to 5473 and is now waiting for a package with sequence number 5473. The server, however, keeps retransmitting an old packet with sequence number 2737.

    This seems to be plain wrong behaviour of the tcp stack, on the other hand I can hardly believe such a problem would be in there. I'm using the Debian Lenny kernels, and the behaviour is the same in 2.6.22 and 2.6.25.

    Any idea what I could do to further track this problem down?

    Update: it seems like this might be iptables-related: after an 'iptables-save > foo ; iptables -X ; iptables -t nat -F ; iptables -t nat -X ; iptables -t mangle -F ; iptables -t mangle -X ; iptables -P INPUT ACCEPT ; iptables -P OUTPUT ACCEPT ; iptables-restore foo' it seems to work for a few minutes, then starts stalling again.

    The problem *seems* to go away when I remove:

    #iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    #iptables -A INPUT -m state --state NEW -i ! ppp0 -j ACCEPT
    #iptables -P INPUT DROP

    but those seem like perfectly valid rules that shouldn't cause this behaviour to me...
    Last edited by raboof; 08-02-2008 at 01:44 PM. Reason: iptables rules possible causing this added

  2. #2
    Linux Guru Lazydog's Avatar
    Join Date
    Jun 2004
    Location
    The Keystone State
    Posts
    2,672
    Are you sure the file you supplied is the correct file?
    I don't see this issue you speak of. In fact it looks like it completed.
    I did see a lot of bad CRC's. Might want to look at this, this could be your problem.

    Regards
    Robert

    Linux
    The adventure of a life time.

    Linux User #296285
    Get Counted

  3. #3
    Just Joined!
    Join Date
    Aug 2008
    Posts
    6
    Quote Originally Posted by Lazydog View Post
    Are you sure the file you supplied is the correct file?
    Jep
    I don't see this issue you speak of. In fact it looks like it completed.
    The dump shows the file being downloaded twice: once successfully, once failing. Sorry, should have mentioned that.
    I did see a lot of bad CRC's. Might want to look at this, this could be your problem.
    Not sure what's causing this, but it seems unlikely that this is the problem, as there are bad CRC's in the successful downloads, too.

  4. #4
    Linux Guru Lazydog's Avatar
    Join Date
    Jun 2004
    Location
    The Keystone State
    Posts
    2,672
    I think you should clean up the BAD CRC's first. This in turn might fix your problem. Just because some finish and other do not does not mean that the CRC's are not the issue. Don't work sdrawkcab ssa.

    Once you have a clean transfer then you can start to look into why session are stalling, if they still are and stop chasing your tail.

    Regards
    Robert

    Linux
    The adventure of a life time.

    Linux User #296285
    Get Counted

  5. #5
    Just Joined!
    Join Date
    Aug 2008
    Posts
    6
    Quote Originally Posted by Lazydog View Post
    I think you should clean up the BAD CRC's first. This in turn might fix your problem. Just because some finish and other do not does not mean that the CRC's are not the issue.
    The wireshark wiki mentions bad checksums in the dump can be a result of TCP checksum offload. Indeed, 'ethtool --show-offload eth0' shows 'rx-checksumming: off, tx-checksumming: on'. I disabled tx checksumming, and indeed, the checksums are now okay but the behaviour still broken.

    New dump here, again first a number of successful attempts and then a failing one.

  6. #6
    Linux Guru Lazydog's Avatar
    Join Date
    Jun 2004
    Location
    The Keystone State
    Posts
    2,672
    Great. Now we need packet capture from both side at the same time. What you have posted only tell one side of the story. To see the complete story you need both sides.

    Regards
    Robert

    Linux
    The adventure of a life time.

    Linux User #296285
    Get Counted

  7. #7
    Just Joined!
    Join Date
    Aug 2008
    Posts
    6
    Quote Originally Posted by Lazydog View Post
    Great. Now we need packet capture from both side at the same time. What you have posted only tell one side of the story. To see the complete story you need both sides.
    I don't see why the client-side of the capture can give any new insight, as it's the server-side that's misbehaving, but here they are. Again, a number of successful downloads, and finally a stalling one:

    Resin
    Resin

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •