This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 962145 - in.telnetd immediately closes connection
in.telnetd immediately closes connection
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: util-linux (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Karel Zak
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 1299351
  Show dependency treegraph
 
Reported: 2013-05-11 20:45 EDT by Ed Greshko
Modified: 2017-06-09 20:42 EDT (History)
6 users (show)

See Also:
Fixed In Version: util-linux-2.23.1-2.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1299351 (view as bug list)
Environment:
Last Closed: 2013-06-07 00:37:02 EDT
Type: Bug
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 Ed Greshko 2013-05-11 20:45:28 EDT
Description of problem: 

[root@localhost system]# telnet localhost
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Fedora release 19 (Schrödinger’s Cat)
Kernel 3.9.1-301.fc19.x86_64 on an x86_64 (2)
Connection closed by foreign host.


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


How reproducible:


Steps to Reproduce:
1. install telnet-server-0.17-56.fc19
2. systemctl start telnet.socket
3. try to telnet to the locahost
  
Actual results:


Expected results:


Additional info: if you add -D options to the in.telnetd line in telnet@.service the connection will be made.
Comment 1 Michal Sekletar 2013-05-13 08:24:07 EDT
I reproduced this bug, but it is not always the case that connection is closed immediately. Sometimes I am able to login. I installed older package telnet-server-0.17-55.fc19.x86_64 which uses xinetd activation and result was the same.
 
Everything works correctly in Fedora 18 regardless of activation mechanism. I think we are hitting bug in some other component than telnet-server. Not sure about right component tough.
Comment 2 Ed Greshko 2013-05-13 08:30:07 EDT
Have a look at https://bugzilla.redhat.com/show_bug.cgi?id=904182

It may be tied to the same component.
Comment 3 Michal Sekletar 2013-05-14 08:36:12 EDT
Looks like that telnet is broken because of the change in util-linux. Karel Zak already committed the fix to the upstream git repository[1]. I tried to replace the login binary with the newest one and it fixed the problem for me. Ed it would be great if you could try it out and confirm that it fixed the issue.

[1] https://github.com/karelzak/util-linux
Comment 4 Ed Greshko 2013-05-14 10:11:22 EDT
Sadly I'm not conversant in github and don't know the process to obtain a new login binary to test.  (I test out of koji)

If you point me to a link which describes the process, I'd be happy to do it in my AM. (GMT+8).
Comment 5 Karel Zak 2013-05-14 10:41:32 EDT
(In reply to comment #4)
> Sadly I'm not conversant in github

 git clone https://github.com/karelzak/util-linux.git
 cd util-linux
 ./autogen.sh
 ./confugure
 make login

 cp /usr/bin/login /usr/bin/login.org
 cp login /usr/bin/login

.. or be patient, I'm going to release v2.23.1 next week with the bugfix.
Comment 6 Ed Greshko 2013-05-14 11:03:00 EDT
Being patient is not one of my virtues.  :-)

After resolving missing pieces it get.....

[egreshko@localhost util-linux]$ make login
  CCLD     login
gcc: fatal error: no input files
compilation terminated.
make: *** [login] Error 4

A simple "make" builds plenty of stuff like fsck, lscpu and others....  But no login.
Comment 7 Karel Zak 2013-05-14 15:24:33 EDT
(In reply to comment #6)
> Being patient is not one of my virtues.  :-)

then you have to learn new things :-) lesson 2: see ./configure output, I guess you don't have installed pam-devel.
Comment 8 Ed Greshko 2013-05-14 17:37:10 EDT
Thanks for that....  Building "login" worked but things are still not well.....

-rwxr-xr-x. 1 root root 112947 May 15 05:29 login
-rwxr-xr-x. 1 root root  40264 May 15 05:29 login.org

egreshko@localhost bin]$ telnet localhost
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Fedora release 19 (Schrödinger’s Cat)
Kernel 3.9.1-301.fc19.x86_64 on an x86_64 (5)
Connection closed by foreign host.

and from another system....

[egreshko@meimei ~]$ telnet 192.168.0.158
Trying 192.168.0.158...
Connected to 192.168.0.158.
Escape character is '^]'.
Fedora release 19 (Schrödinger’s Cat)
Kernel 3.9.1-301.fc19.x86_64 on an x86_64 (5)
Connection closed by foreign host.
Comment 9 Karel Zak 2013-06-04 07:05:15 EDT
It seems that something is wrong with interaction between telnetd and vhangup() code in login(1).

login(1) closes all terminal file descriptors before it calls vhangup() -- this thing is probably incorrectly interpreted by telnetd as end of the session and all is terminated (SIGTERM).

If I remove the close() code from login(1) than all work as expected. See the code:

https://github.com/karelzak/util-linux/blob/master/login-utils/login.c#L404


Note that old xinetd based solution does not have this problem, the *same* login(1) binary works as expected with old telnetd+xinetd on F18. 

It's also possible that the problem is with 3.9 kernel, it would be nice to try to use f19 kernel in f18 with xinetd.

See also:
https://lkml.org/lkml/2012/6/5/145
https://lkml.org/lkml/2013/1/15/641
https://bugzilla.redhat.com/show_bug.cgi?id=904182
Comment 10 Karel Zak 2013-06-05 03:50:55 EDT
I have tried to update kernel on my system and all works as expected with kernel-3.9.4 + xinetd + login from util-linux 2.23. 

So it does not seem like kernel problem.
Comment 11 Karel Zak 2013-06-05 04:07:54 EDT
OK, another hint -- all works as expected if I install telnet-server (with socket activation) and login(1) from f19 to f18.

$ rpm -q systemd telnet-server; uname -r               
systemd-201-2.fc18.7.x86_64
telnet-server-0.17-56.fc19.x86_64
3.9.4-200.fc18.x86_64
Comment 12 Karel Zak 2013-06-05 08:10:00 EDT
I think I found the problem:

code:
        ttt.c_cflag &= ~HUPCL;
        tcsetattr(0, TCSAFLUSH, &ttt);
                
        /*      
         * Let's close file decriptors before vhangup
         * https://lkml.org/lkml/2012/6/5/145
         */     
        close(STDIN_FILENO);
        close(STDOUT_FILENO);
        close(STDERR_FILENO);
                
        signal(SIGHUP, SIG_IGN);        /* so vhangup() wont kill us */
        vhangup();
        signal(SIGHUP, SIG_DFL);
                
        /* open stdin,stdout,stderr to the tty */
        open_tty(cxt->tty_path);


f18:
    
ioctl(0, SNDCTL_TMR_CONTINUE or SNDRV_TIMER_IOCTL_GPARAMS or TCSETSF, {B9600 opost isig icanon 
close(0)                                = 0
close(1)                                = 0
close(2)                                = 0
rt_sigaction(SIGHUP, {SIG_IGN, [HUP], SA_RESTORER|SA_RESTART, 0x3c95c35c20}, {SIG_IGN, [], 0}, 
vhangup()                               = 0
--- SIGHUP {si_signo=SIGHUP, si_code=SI_KERNEL} ---
--- SIGCONT {si_signo=SIGCONT, si_code=SI_KERNEL} ---
rt_sigaction(SIGHUP, {SIG_DFL, [HUP], SA_RESTORER|SA_RESTART, 0x3c95c35c20}, {SIG_IGN, [HUP], S
open("/dev/pts/4", O_RDWR|O_NONBLOCK)   = 0
    

f19:
 
ioctl(0, SNDCTL_TMR_CONTINUE or SNDRV_TIMER_IOCTL_GPARAMS or TCSETSF, {B9600 opost isig icanon 
close(0)                                = 0
close(1)                                = 0
close(2)                                = 0
--- SIGHUP {si_signo=SIGHUP, si_code=SI_KERNEL} ---
--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1, si_uid=0} ---
+++ killed by SIGTERM +++


The problem is TCSAFLUSH, because it postpone the action and we get SIGHUP and SIGTERM before we setup signal(SIGHUP, SIG_IGN). The solution is to use TCSANOW and probably also move signal(SIGHUP, SIG_IGN) before we close the std{out,in,err}.
Comment 13 Fedora Update System 2013-06-05 09:30:05 EDT
util-linux-2.23.1-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/util-linux-2.23.1-2.fc19
Comment 14 Ed Greshko 2013-06-05 11:04:06 EDT
Confirmed Fix and gave karma ....  Thanks....
Comment 15 Fedora Update System 2013-06-05 12:51:45 EDT
Package util-linux-2.23.1-2.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing util-linux-2.23.1-2.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-10075/util-linux-2.23.1-2.fc19
then log in and leave karma (feedback).
Comment 16 Michal Sekletar 2013-06-06 07:17:56 EDT
I tested the update and it resolved the issue. Thanks.
Comment 17 Fedora Update System 2013-06-07 00:37:02 EDT
util-linux-2.23.1-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

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