Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 4 product line. The current stable release is 4.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 922942

Summary:

TCP Re-transmits not occurring as expected.

Product:

Red Hat Enterprise Linux 4

Reporter:

warrenolson

Component:

distribution

Assignee:

RHEL Program Management <pm-rhel>

Status:

CLOSED WONTFIX

QA Contact:

Nobody <nobody>

Severity:

urgent

Docs Contact:

Priority:

unspecified

Version:

4.9

CC:

toneata

Target Milestone:

Target Release:

---

Hardware:

x86_64

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2020-01-13 16:45:20 UTC

Type:

Bug

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
Screencaps of broken/expected behavior.	none

Description warrenolson 2013-03-18 20:18:20 UTC

Created attachment 712227 [details]
Screencaps of broken/expected behavior.

Description of problem:

TCP Re-transmits are not occurring in the timeframe expected.

Related Device Info:
--Squid 2.6--stable23 running on RHEL4 Update 9
--FortiGate 60C running 4.3.7 FortiOS.

Communication Path:
Client --> Squid --> FortiGate --> DSL

Issue: While attempting to log into http://portal.greatsouthernwood.com via above comm path, the login will hang until timeout occurs. Upon investigation into packet capture, we found the following series of events occurring each time we issue the Login button:

1. Client --> Squid: POST request to /Service.asmx/IsLoggedIn
2. Squid --> FortiGate: sends above POST request to inside interface on FortiGate.
3. FortiGate --> Squid: FortiGate replies back to POST request with a TCP ZeroWindow followed up by a TCP Window Update. This is by design and part of the webfilter module of the device in order to "pause" the connection to do a URL lookup, and then restart the connection if that returns successfully.

What should happen next is Squid/Redhat should be immediately retransmitting the original POST based on the RTO (rexmit time out), but what does happen is 120 seconds passes THEN the re-xmit occurs.

For whatever reason this does not happen 100% of the time, and I have linked pcap images showing when it does/does not happen. I need to understand why it seems Redhat/Squid chokes on either the ZeroWindow happening or the Window Update(seems more likely the ZeroWindow), and then doesn't retransmit until 120 seconds later. 

Version-Release number of selected component (if applicable):
N/A at this time.

How reproducible: Very


Steps to Reproduce:
1. Navigate to http://portal.greatsouthernwood.com
2. Attempt to login(have to use valid credentials)
3. Check PCAP for behavior described above.

Comment 1 warrenolson 2013-04-01 21:25:46 UTC

Hello,

The exact version I am testing with is:

3.6.10-4.fc18.i686 #1 SMP Tue Dec 11 18:24:49 UTC 2012 i686 i686 i386 GNU/Linux

This is happening on *all* 1900+ occurrences of this OS running Squid 2.6. The issue seems more network stack related with OS which is what prompted us to open bug. Any assistance pinpointing what's going on would be greatly appreciated.

The essential issue is that the squid server running RH version above does not retransmit packets after receiving a tcp window update as expected. I did not find any known issues around this but it's very reproduceable for me.