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:
uh, s.th. very strange. Maybe you can attach the strace output and do an ltrace, too..
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).
Changing QA contact to dkl