Bug 146033 - RHR2 net test fails with "Connection reset by peer"
Summary: RHR2 net test fails with "Connection reset by peer"
Alias: None
Product: Red Hat Ready Certification Tests
Classification: Retired
Component: net (Show other bugs)
(Show other bugs)
Version: 2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Rob Landry
QA Contact: Rob Landry
Depends On:
Blocks: 143442
TreeView+ depends on / blocked
Reported: 2005-01-24 20:30 UTC by Daniel W. Ottey
Modified: 2007-04-18 17:18 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-28 13:47:07 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
NETWORK/output.log (3.54 KB, text/plain)
2005-01-24 20:30 UTC, Daniel W. Ottey
no flags Details
NETWORK/hardware.log (697 bytes, text/plain)
2005-01-24 20:30 UTC, Daniel W. Ottey
no flags Details
output.log from e100 (PASS) and e1000 (FAIL) (44.82 KB, text/plain)
2005-01-26 16:45 UTC, Daniel W. Ottey
no flags Details
hardware.log from e100 (PASS) and e1000 (FAIL) (700 bytes, text/plain)
2005-01-26 16:47 UTC, Daniel W. Ottey
no flags Details

Description Daniel W. Ottey 2005-01-24 20:30:17 UTC
Description of problem:
RHR2 net test fails with "Connection reset by peer"

It looks to me like the SSH connection is what is failing, but I cannot
determine why.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:
Test fails

Expected results:
Test passes

Additional info:
Failure is reproducable both with a static and a DHCP ip address.

Comment 1 Daniel W. Ottey 2005-01-24 20:30:18 UTC
Created attachment 110155 [details]

Comment 2 Daniel W. Ottey 2005-01-24 20:30:51 UTC
Created attachment 110156 [details]

Comment 3 Daniel W. Ottey 2005-01-25 17:11:51 UTC
Raising severity to HIGH.  I tried to find a severity of BLOCKER, because this
is blocking our ability to certify the hardware, but that severity is not in the

An issue tracker will be opened shortly.

Comment 4 Richard Li 2005-01-25 18:04:59 UTC
What version of RHEL are you running on the iSpec server?

This may be the same as bug 145570. Can you try the change described in that
ticket (change the ab parameters) and see if that addresses the problem?

Comment 5 Daniel W. Ottey 2005-01-25 19:09:48 UTC
The iSpec server is running RHEL4 prec-RC2.  We can upgrade it if need be, but
we looked at the RPM versions of both Apache and SSH between the pre-rc2 and the
final and couldn't find any difference.

We will test the work-around by modifying the 'ab' command in
/usr/share/rhr/tests/network/tcp as suggested in bug 145570.

Comment 6 Richard Li 2005-01-25 19:11:50 UTC
I agree; I do not think that upgrading the iSpec server will change anything.
Let us know how the ab change goes.

Comment 7 Daniel W. Ottey 2005-01-26 16:44:23 UTC
I am sorry to report that the ab change did not help us.  We are still receiving
the "Connection reset by peer" error.

We've now run the test against an Integrated e100 NIC and that one passes (but
for some reasons its name is dev6536 and not ethx).  But the test still fails
when run against our gigabit Intel controllers which use the e1000 driver.

I will post a new log file set shortyl.

Comment 8 Daniel W. Ottey 2005-01-26 16:45:40 UTC
Created attachment 110252 [details]
output.log from e100 (PASS) and e1000 (FAIL)

Comment 9 Daniel W. Ottey 2005-01-26 16:47:08 UTC
Created attachment 110253 [details]
hardware.log from e100 (PASS) and e1000 (FAIL)

Comment 10 Rob Landry 2005-01-26 16:59:59 UTC
Can the ab line be run by hand against the e1000 NIC and pass or does that
always fail?

Comment 11 Daniel W. Ottey 2005-01-28 13:47:07 UTC
Yes, the ab command was able to pass "by hand" against the e1000 NIC.  This was
by running it from the ispec server and not through an SSH command.

I believe the SSH was timing out.

A good reason for this is that while our SUT had a gigabit connection, the ispec
server did not.  So ab was downloading a 125MB file over a 100mbit connetion. 
It would take atleast 15 minutes for text "Processed 100 Requests" to be
displayed to the screen.  I think the lack of interaction (display and typing)
caused the SSH connection to time out.

We have since moved ispec to a newer server that supports gigabit.  We rerun the
 test and it passes as expected.

Thak you for all your help, and I apologize for our error when setting up our

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