timed out ssh sessions interfere with newly created ssh sessions

[hoanga]

i have been noticing this phenomenon for some time after beta4 was released (last observed on hrev57117 but even before version).

if you keep a long running ssh session that eventually times out and disconnects. if you establish a new ssh session to the same haiku host, it appears that the 'old' ssh session also sometimes returns data on the new established ssh session. a workaround when this happens is to send EOF (Ctrl-D) multiple times to log out of the new ssh session and then log back in under yet another ssh session and this appears to clear up the old disconnected connection from interfering with new sessions.

not sure what would be helpful to capture when this happens, but i consider the workaround sufficient for when this situation happens.

[waddlesplash]

Not sure I quite understand here. You mean that sometimes command output from the "old" session will show up on the new one?

[hoanga]

pardon if i my explanation wasn't very clear. when this situation occurs, what appears to be happening is that the input and output from the "old" session gets multiplexed/mixed onto the "new" session. so, yes the command output from the "old" session when this situation happens will show up on the new one.

it almost seems like the stdin, stdout (and maybe stderr) from the "old" session somehow gets mixed in with the "new" session. so when entering input into the "new" session, some of the input would go to the "old" session and some of the input goes to the "new" session.

an example that hopefully might illustrate this.

• connect on "old" session. cd to ~/config
• "old" session times out
• sometime later, "new" session is established
• mixing situation occurs
• at this point just hitting enter continuously returns back sometimes ~/config and sometimes ~/
• trying to enter commands usually fails at this stage
• just continuously sending EOF (Ctrl-D) at this point appears to clean up "old" session and "new" session
• establish "newer" session appears okay

[waddlesplash]

Can you check the process tree on Haiku after establishing the "new" session? And then get a tcpdump on the (I guess Linux?) machine that's connecting to the Haiku machine?

[waddlesplash]

Can you also check if hrev56987 is hrev at which the problem starts occurring, and hrev56980 or prior has no problem (note that intermediate hrevs between those two have a bug that will prevent TTYs from working properly, so don't bother testing them.)

[pulkomandy]

I think I had something similar happen with Terminal.

• Ran cat on a binary file which eventually froze Terminal
• Killed Terminal
• Started a new Terminal

All commands I type in the new terminal are misunderstood. For example I type "cd" and bash replies "d: command not found". I type "reset; cd; exit" and bash replies "retdex: command not found".

I would guess something is consuming tty bytes that it shouldn't be?

[waddlesplash]

Sounds like the TTY isn't getting closed/hung up properly, there's probably a lingering bash process, indeed.

[waddlesplash]

Fixed in hrev57141.

[hoanga]

a short follow up as i haven't had enough time to setup a proper setup to try checking the suggested hrevs for when this problem might have manifested. however in keeping in sync on nightly builds, i have not noticed this occurring (and have tried to get this to occur) when using hrev57141 or higher. thanks for the quick turnaround!