Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

failed assertion in common-channel.c:705: `!channel->sent_close' #321

Open
rsflo opened this issue Aug 30, 2024 · 3 comments
Open

failed assertion in common-channel.c:705: `!channel->sent_close' #321

rsflo opened this issue Aug 30, 2024 · 3 comments

Comments

@rsflo
Copy link

rsflo commented Aug 30, 2024

Hi,

dropbear is used on the server side to control an application that allows to transfers files.
Sporadically the session breaks entirely as part of an automated test that continuously fetches files from the server.

The mentioned assert is triggered in dropbear-2024.85 server on linux/x86_64 (linux-6.1.86 / glibc-2.38) and is no longer reproducible when commits a7ef149 and 8e6f73e are reverted (related to issue #85).
Issue first occurred after having updated to 2022.83.
2020.81 (and likely earlier versions) do not show this behavior.

Server is invoked using a systemd socket unit and the call
/usr/sbin/dropbear -vvvv -i -r /etc/dropbear/dropbear_rsa_host_key -w -W 1048576

stderr is redirected to a file:
dropbear-2024.85_assert.log

It seems a "channel" is tried to be used, which has just been closed.

The used build of dropbear is based on Yocto, which slightly patches the source (these changes are assumed to be not relevant).
As much as I understand the upstream default build options are used, localoptions.h contains
#define DEBUG_TRACE 5
only.

The remote client triggering the assert is based on libssh and intends to copy a couple of files. Most of the files are a few hundred bytes in size, largest is about 100K. It usually happens during a sequence of smaller files.
(Yet there is little information as to how this is implemented, I could dig into it if it helps to understand the general flow. I mostly have a proprietary CLI tool that allows to initiate the copy operation.)

@mkj
Copy link
Owner

mkj commented Sep 5, 2024

Thanks for the debug log. It looks like something is going wrong when a channel is opened around the same time as another is being closed (which should work fine). I'll try and reproduce it here to debug, if you have any details of the libssh call sequence that would help.

@mkj
Copy link
Owner

mkj commented Sep 6, 2024

if you have any details of the libssh call sequence that would help.

I've reproduced it here so don't need any more details.

@rsflo
Copy link
Author

rsflo commented Sep 9, 2024

I've reproduced it here so don't need any more details.

Great, thanks for looking into it!
Please let me know if you need anything from my side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants