Red Hat Bugzilla – Bug 25493
masqueraded outbound traffic slows to < 500bps
Last modified: 2007-04-18 12:31:02 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.16-22 i586)
Pentium 100, eth0 eepro port x0300 irq 10 connected to Lancity cable modem
eth1 tulip (Linksys LNE100) base 0xe400 irq 11 connected to 10BT hub.
Stock 7.0 system with 2.2.22-16 kernel
Masqueraded outgoing traffic (i.e. sending mail, ftp send, etc.) starts at
40K+ and quickly slows to ~500bps. Traffic sent directly from masqueraded
host gets 40K+ bps.
Redhat 6.2 stock system running 2.2.14-5 kernel as masquerading firewall
gets outgoing throughput (from an internal network client) of 40K+
Steps to Reproduce:
1. load stock redhat 7.0 (without X server, libraries, or clients)
2. use ipchains rule: ipchains -A forward -s 192.168.2.0/24 -j MASQ
3. try to send an ftp or mail from a PC connected to local hub.
Actual Results: Using NCFTP to send a file to a host on the internet,
bitrate immediately slows from 40K to 500 bps.
Expected Results: The obvious speed of 40K
I am willing to give access to my system to help debug.
Work around is to fall back to a redhat 6.2 system.
Created attachment 8645 [details]
rc/init.d file for starting the masquerade proxies and loading the rules.
Problem appears to be in the eepro driver. When I built a 2.2.14-5 kernel eepro
driver with the 2.2.17-14 kernel the problem when away. I will continue
Found the problem and a fix. I have a theory as to what is happening, but it is
The fix is in the eepro driver (see attached file and look for ifdef
EEPRO_SLOW_NET). I don't think the problem I am seeing is specific to
The problem is in the eepro_transmit_interrupt routine. After the driver sends a
packet to the eepro, the eepro_transmit_interrupt routine checks to see if the
transmit is complete. If the transmit does not complete in a specified amount of
time, the routine assumes the card is stuck and does a reset.
The problem is when the eepro is connected to a slow device such as a Lan City
cable modem. Somehow the modem must be preventing the transmit from completing
until it is ready for the next packet. Because the transmit takes a long time to
complete, the eepro_transmit_interrupt routine see a timeout and resets the card
which in turn cancels the send. The end result is lost xmit packets and slow
outward bound traffic (< 500 bps).
I dont know if this problem is specific to the Lan City modem or shows up in
other slow modem devices. Note that the outbound cable network speed is
throttled to < 50Kbps.
My fix is to remove the reset at the end of the eepro_transmit_interrupt
routine. A real fix would be to determine the transmit speed of the cable modem
at configuration time and set the timeout appropriately.
The eepro driver that came with the stock 6.2 kernel (2.2.14-5) did not have
Created attachment 11341 [details]
temporary fix to the eepro driver for slow cable modems
Should be resolved in newer eepro drivers, if not feel free to reopen