I have two RHEL5 boxes that I use for routers. My configuration is internet-router1-dmz-router2-lan. Recently, I have users that have been complaining about file uploads failing when the files are 'too large'. (By too large, I mean that at one site any file over 250K is failing consistently.) When these users test from outside my network, the upload process works fine. Inside the network, fails all the time.
To try to eliminate some of the complexity, I decided to test from a machine within the dmz (hence, internet-router1-dmz). I was able to successfully upload the files every time I tried.
The uploader they are using is within a browser, but it is flash related.
Both of the routers are nearly identical in build.
When tracking the network traffic, it appears that the transfer starts and then communication just hangs.

My question is this:

Are there built-in mechanisms in RHEL5 or any of its netfilter stuff that would automatically (from a vanilla install) throttle connections for these larger datastreams that I'd need to open up?

Might be worth looking at the offload settings for the nics... 'ethtool -[k|K] <dev>'

Not too familiar with these settings:

#> ethtool -k eth0
Offload parameters for eth0:
Cannot get device udp large send offload settings: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: on
generic-receive-offload: on


#> ethtool -k eth1
Offload parameters for eth1:
Cannot get device udp large send offload settings: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: on
generic-receive-offload: on

My comment was based on a bug that I came across previously and the symptoms looked similar. Please try disabling TSO on the target side and see if it makes any difference

No good. But since I'm getting successful uploads outside my network, wouldn't the target box be configured correctly already? I don't think I've ever had to dig this deeply for a network issue before.

Good point .. do you have a sniffer on the target like wireshark or tcpdump?

Yeah. I have two trace files, one for a successful file transfer and one for an unsuccessful file transfer. I'm not seeing the difference in the two. I've attached them.

Attached Files

	good.txt (110.0 KB, 9 views)
	bad.txt (99.6 KB, 7 views)

.. the traces seem to be from the same machine, not sure how this is differentiating between inside and outside the network .. ?

They are both going through router1, but the one that fails is also going through router2.

So where exactly is the server ?

Sorry. That would be a useful piece of information. The server we are trying to upload to is out on the internet. So both transfers are going through router 1 to the internet while the failed transfer its going through router 2 then router 1 to the internet to the target box.

Especially when I was thinking the server was in the DMZ or the LAN

Can you check the web server logs?

The only file that is modified during the (attempted) uploads is access.log.

This is what it looks like when successful:

64.126.162.234 - - [08/Dec/2011:12:00:29 -0500] "GET /liquid-hash/wp-admin/media-new.php HTTP/1.1" 200 22050
64.126.162.234 - - [08/Dec/2011:12:00:30 -0500] "GET /liquid-hash/wp-includes/images/admin-bar-sprite.png?d=20111130 HTTP/1.1" 304 -
64.126.162.234 - - [08/Dec/2011:12:00:40 -0500] "POST /liquid-hash/wp-admin/async-upload.php HTTP/1.1" 200 3
64.126.162.234 - - [08/Dec/2011:12:00:43 -0500] "POST /liquid-hash/wp-admin/async-upload.php HTTP/1.1" 200 4016
64.126.162.234 - - [08/Dec/2011:12:00:43 -0500] "GET /liquid-hash/files/Chrysanthemum2-150x150.jpg HTTP/1.1" 200 11506
64.126.162.234 - - [08/Dec/2011:12:00:46 -0500] "POST /liquid-hash/wp-admin/media-upload.php?inline=&upload-page-form= HTTP/1.1" 302 -
64.126.162.234 - - [08/Dec/2011:12:00:47 -0500] "GET /liquid-hash/wp-admin/upload.php HTTP/1.1" 200 65548

This is what it looks like when unsuccessful:

64.126.162.234 - - [08/Dec/2011:12:04:28 -0500] "POST /liquid-hash/wp-admin/async-upload.php HTTP/1.1" 200 308
192.168.227.57 - - [08/Dec/2011:12:04:44 -0500] "GET / HTTP/1.1" 302 -
192.168.227.57 - - [08/Dec/2011:12:04:44 -0500] "GET / HTTP/1.1" 200 23110

I'm sorry, but I'm not familiar with any routing possibilities in linux, but the LOG file I look at is
somehow makes me doubt that this
GET / HTTP/1.1" 302 -

makes a redirect to some outer space ?

Again, I apologize for any mislead if this is not the case.

Good luck.

So if the trace files look the same but you can see variations in the web server logs, it's starting to look more like an app issue than a network issue.