Bug 43374

Summary:	in.telnetd exits w/ status 1 immediately after login
Product:	[Retired] Red Hat Linux	Reporter:	David L. Parsley <parsley>
Component:	telnet	Assignee:	Harald Hoyer <harald>
Status:	CLOSED CURRENTRELEASE	QA Contact:	David Lawrence <dkl>
Severity:	low	Docs Contact:
Priority:	medium
Version:	6.2	CC:	pekkas
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-08-05 08:17:47 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description David L. Parsley 2001-06-04 14:15:00 UTC

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 07:52:32 UTC

uh, s.th. very strange. Maybe you can attach the strace output and do an 
ltrace, too..

Comment 2 Pekka Savola 2001-09-06 07:33:43 UTC

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 13:56:57 UTC

Changing QA contact to dkl