Bug 25493 - masqueraded outbound traffic slows to < 500bps
Summary: masqueraded outbound traffic slows to < 500bps
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-02-01 16:36 UTC by Gregg Lebovitz
Modified: 2007-04-18 16:31 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2003-06-09 14:50:21 UTC

Attachments (Terms of Use)
rc/init.d file for starting the masquerade proxies and loading the rules. (1.93 KB, patch)
2001-02-01 16:39 UTC, Gregg Lebovitz
no flags Details | Diff
temporary fix to the eepro driver for slow cable modems (52.06 KB, text/plain)
2001-02-28 16:26 UTC, Gregg Lebovitz
no flags Details

Description Gregg Lebovitz 2001-02-01 16:36:36 UTC
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+

Reproducible: Always
Steps to Reproduce:
1. load stock redhat 7.0 (without X server, libraries, or clients)
2. use ipchains rule: ipchains -A forward -s -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.

Comment 1 Gregg Lebovitz 2001-02-01 16:39:14 UTC
Created attachment 8645 [details]
rc/init.d file for starting the masquerade proxies and loading the rules.

Comment 2 Gregg Lebovitz 2001-02-27 14:36:41 UTC

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

Comment 3 Gregg Lebovitz 2001-02-28 16:20:50 UTC
Found the problem and a fix. I have a theory as to what is happening, but it is
not verified.
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
this reset.

Comment 4 Gregg Lebovitz 2001-02-28 16:26:29 UTC
Created attachment 11341 [details]
temporary fix to the eepro driver for slow cable modems

Comment 5 Alan Cox 2003-06-09 14:50:21 UTC
Should be resolved in newer eepro drivers, if not feel free to reopen

Note You need to log in before you can comment on or make changes to this bug.