Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 25493 - masqueraded outbound traffic slows to < 500bps
masqueraded outbound traffic slows to < 500bps
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Michael K. Johnson
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-01 11:36 EST by Gregg Lebovitz
Modified: 2007-04-18 12:31 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-09 10:50:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Gregg Lebovitz 2001-02-01 11:36:36 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.16-22 i586)


Hardware:

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 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.
Comment 1 Gregg Lebovitz 2001-02-01 11:39:14 EST
Created attachment 8645 [details]
rc/init.d file for starting the masquerade proxies and loading the rules.
Comment 2 Gregg Lebovitz 2001-02-27 09:36:41 EST
Update

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
investigating.
Comment 3 Gregg Lebovitz 2001-02-28 11:20:50 EST
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
masquerading.

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 11:26:29 EST
Created attachment 11341 [details]
temporary fix to the eepro driver for slow cable modems
Comment 5 Alan Cox 2003-06-09 10:50:21 EDT
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.