Thursday den 13 August 2015 klockan 22:45 skrev Chris Severance detta: > On Thu, Aug 13, 2015, at 01:17 PM, Mats Erik Andersson wrote: > > Morally it can be argued that this failure is a good thing! > > Yes, but the other side of that coin is that Random Foo Linux should not > be less capable than any old Unix. Telnet is perfectly acceptable > through secure tunnels like IPSec VPN or SSH where the endpoints are > trusted. Some things can only connect to a telnet server because they > don't know how to speak ssh.
I only intended that rejection of connection flooding can be viewed as a good thing; I still regard Telnet clients and servers as very important ingredients in a computer landscape, all the more since our is supporting Kerberos authentication and encryption. > I've used this patch since I posted the bug and it's working very well. > No more disconnects before the banner. 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. I just had a commit prepared, when comparative builds unearthed the problem above, which I now remember having used as a reason for the change in March. As a further observation, since I am maintaining netkit-telnetd and netkit-telnetd-ssl for Debian, and also there the condition is identical to BSD code, I can not avoid a conclusion that this matter needs further study. Having two conflicting issues is really problematic. 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. Best regards, M E Andersson
