[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-inetutils] Bug report for gnu inetutils telnetd

From: Chris Severance
Subject: Re: [bug-inetutils] Bug report for gnu inetutils telnetd
Date: Wed, 19 Aug 2015 22:11:47 -0400

On Sat, Aug 15, 2015, at 05:22 PM, Mats Erik Andersson wrote:
> On the other hand, with the reversion you suggest and support,
> the same server binary running on an OpenIndiana system is not
> able to detach the connection after an 'exit' issued by the
> client, two [sic] further carrage returns are required by the
> calling side before a proper disconnect is reported.

The return codes for readstream() are different than the return codes
for read(). From what I can tell the Solaris readstream() code cannot
return a 0. The Linux read() clearly returns a 0 quite often. The
readstream() wrapper for OS that don't do streams isn't written properly
to duplicate a read() with streams. I suspect the read() was added
because Linux had stream support and the conditional was  fixed to
match, which then broke the readstream code for OS not tested.

I see easy fixes but I'd rather have it fixed right so we can stop the
problems from ping pong back and forth between the OS.

> A pledge: Could you find time to insert debugging input into
> pty_read() reporting on error status when a connection is
> rejected during your connection flooding? It would help me
> understanding this matter.

I could send you some debug logs but this will get done faster with
access to a running Linux. I've built an empty Arch Linux server with
the inetutils code ready to compile and test. To fix this you'll need to
work many systems in parallel to get the return codes for readstream
straightened out.

I've verified that telnet tunneled through a SSH LAN connection fails in
the expected manner.

This can be a tough bug to reproduce. When setting up the Arch Linux
server, LAN connections through the onboard Broadcom Gigabit NIC only
disconnected 1 of 15 logins. I added a PCI-e Broadcom Gigabit NIC and
then I couldn't get a single telnet login prompt in 15 tries. Then I
went to another site and accessed the server through an IPSec VPN and
all of 15 attempts showed a login. At other times those same connections
through the VPN disconnect 9 of 10 attempts.

Even at one connection per second, clicking by hand isn't fast enough to
be considered a connection flood. The first few times I thought it was a
network problem or a PEBCAK. Once you get a system that exhibits the
problem, clicking fast highlights that it's definitely a computer
problem, not a user problem. This bug rejects connections of any rarity.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]