Bug 43374 - in.telnetd exits w/ status 1 immediately after login
in.telnetd exits w/ status 1 immediately after login
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: telnet (Show other bugs)
6.2
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Harald Hoyer
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-06-04 10:15 EDT by David L. Parsley
Modified: 2007-04-18 12:33 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-08-05 04:17:47 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)

  None (edit)
Description David L. Parsley 2001-06-04 10:15:00 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.1-pre7 i686)

Description of problem:
After doing some experimenting, telnetting to a RH6.2 (patched up to date
as of 5/01)
causes in.telnetd to exit w/ status 1 when telnetting from certain HP and
SUN systems.
None of our own sun boxen have trouble (it was a specific remote vendor
needing
temporary telnet access).
The exit happens immediately after supplying the password.  I did an strace
-f -ff of
inetd, and it appeared that in.telnetd segfaulted immediately after a call
to 'gettimeofday'.  This problem did NOT occur before the update; somehow I
suspect
it's related to glibc.

How reproducible:
Always

Steps to Reproduce:
1. Update an RH62 box to current
2. Try telnetting to the box w/ a variety of SUN (sol 7 & 8) and HP boxen
3. If you're holding your mouth right, in.telnetd might crash
4. The hosts that fail fail EVERY TIME, so in that sense it's completely
reproduceable
5. I'm sorry I don't have a sure-fire formula for triggering this bug 'in
the lab'
	

Actual Results:  On failing hosts, in.telnetd crashes immediately after
supplying the correct password.

Expected Results:  Should have gotten a shell prompt.

Additional info:
Comment 1 Harald Hoyer 2001-06-05 03:52:32 EDT
uh, s.th. very strange. Maybe you can attach the strace output and do an 
ltrace, too..
Comment 2 Pekka Savola 2001-09-06 03:33:43 EDT
You might also want to get tcpdump with like 'tcpdump -vvv -s 512 -n port 23'
(please
use tcpdump-3.6 from Red Hat Rawhide).

Another additional way would be to pass '-D options' to telnetd (options
negotiation debugging).

(telnet options negotiation might be significant).

And oh:

> None of our own sun boxen have trouble (it was a specific remote vendor
> needing temporary telnet access).

It wasn't root account, was it? :-)  root isn't allowed to log in
(/etc/securetty).
Comment 3 Glen Foster 2001-09-06 09:56:57 EDT
Changing QA contact to dkl

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