You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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 notrelevant).
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.)
The text was updated successfully, but these errors were encountered:
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.
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.)
The text was updated successfully, but these errors were encountered: