Ssh connection occasionally aborted by dropbear while establishing the connection (regression) about dropbear HOT 6 CLOSED

Thanks for the report. I think the problem might occur when SIGCHLD arrives after loophandler() gets called, but before channelio()'s channel_signal_pending test. (loophandler() is the callback svr_chansess_checksignal())

If it's easy for you to currently reproduce, would you be able to try putting a call svr_chansess_checksignal(); at the start of sesscheckclose() ? I'll try add a reproducible test case for myself and see if there's a less bodgy fix.

from dropbear.

Hello mkj! Thanks for the response.

Our automated test can reproduce the problem rather quickly.
I tried the patch that you proposed in the previous comment. It did not fix the problem.
To make sure the setup is consistent with past observations, I also ran the same test :

• with no mod at all – the failure is present
• with our hack in session_loop() – the failure is absent

Note that for the tests today, I removed the debug traces we previously added, so they don’t interfere. These traces tend to increase the occurrence of the issue.

from dropbear.

Ah yes, my theory doesn't make sense - I'd forgotten that the signal handler is no longer asynchronous (noticed some other things to clean up there too).

I'm a bit puzzled why ses.channel_signal_pending is set if chansess.pid isn't initialized. A sigchld should only occur after the pid has been filled out, unless another child process (unrelated to that channel) has exited? Could you give me some more details of your test setup so I can try reproduce it (or if you want to paste/email me debug traces I have a look at them)

from dropbear.

Deleted.

from dropbear.

Hello Matt. Thanks for the support.

Your last comment helped us understand how the problem happens. We previously made a modification in srv_auth.c (function recv_msg_userauth_request()) where we fork a child process to perform user/password validation.

This fork causes a call to sesssigchild_handler() (in srv-chansession.c) , which writes into ses.signal_pipe. This then causes session_loop() to set ses.channel_signal_pending to 1 before there is a pid in ChanSess.pid.

The reason why this worked in the past is probably because the older versions of dropbear did not nave the « chansess->pid==0 » condition in the return() statement of sesscheckclose().

And the reason why it doesn’t fail all the time is because most of the time, there is nothing to read from ses.sock_in in the same loop iteration.

I’m trying to find a way to deal with that. Do you have suggestions?
I can imagine a few potential ideas, but nothing solid yet.

• Find a way to make sesssigchild_handler() ignore the fork made for password validation (don’t know if this is possible)
• Avoid calling read_packet() in the same loop iteration when ses.channel_signal_pending == 1 (have not enough insight to foresee side effects)

from dropbear.

I close this issue. Thanks for the hints, this was very helpful
The problem was caused by a modification that we made that forks a child process, causing the SIGCHLD handler to be called and thus setting ses.channel_signal_pending to 1. It was solved by exiting the sigchld handler immediately at the begining in this situation.

from dropbear.