mkj
failed assertion in common-channel.c:705: `!channel->sent_close'
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.)
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.
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.
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.
FTR, i'm also seeing this while using guix deply. it seems to be consistently reproducible, it breaks every time.
the guix bug report: https://issues.guix.gnu.org/73306
I've figured what's going on and have a fix here, will push it after a bit of cleaning up later this week.
I think #326 should fix this, I haven't yet added the testcase for it.
Good news! I'm going to apply this on top of 2024.85 next week and will retry it based on our use case.
I think #326 should fix this, I haven't yet added the testcase for it.
Good news! I'm going to apply this on top of 2024.85 next week and will retry it based on our use case.
The change appears to be good. Ran the mentioned test again and manually stopped it after about 5400 iterations with no error.
@mkj I'm going to suggest this fix for Yocto, trying to also get it into its current LTS version, which is still using dropbear-2082.83. Is there anything wrong with applying it to that version? The patch applies mostly clean on top of 2082.83 and our test case does not show any issues.
@mkj I'm going to suggest this fix for Yocto, trying to also get it into its current LTS version, which is still using dropbear-2082.83. Is there anything wrong with applying it to that version?
It should be right to apply for 2082.83
@mkj I'm going to suggest this fix for Yocto, trying to also get it into its current LTS version, which is still using dropbear-2082.83. Is there anything wrong with applying it to that version?
It should be right to apply for 2082.83
Sorry for the typo, of course I meant 2022.83.