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.
