Compiling and installing dropbear for an old version

Installing and Using OpenWrt
1

Hello,

We have a strange situation.

We have a mass-produced router which runs a manufacturer's custom version of OpenWRT (based on Chaos_calmer 15.05.1). This router:

[1] has the hidden option of giving network access to it through telnet.

[2] this router is not yet directly supported by OpenWRT in toh.openwrt.org.

[3] the CPU platform of this router has begun being supported by OpenWRT 24.10 for some other routers with this same CPU platform.

The wish we are trying to achieve is to install dropbear in this router, so as not to use telnet (and disable telnet).

What we have done is compile the dropbear package for that CPU platform in OpenWRT 24.10, using the OpenWRT SDK musl for that CPU platform ( following https://openwrt.org/docs/guide-developer/toolchain/using_the_sdk )

This cross-compilation has generated .apk files for the dropbear package and its required packages.

These .apk packages can be transferred to the router. The issue is:

[A] The router seems to be running a variant of Chaos_calmer 15.05.1, so its opkg supports .ipk files, but not .apk files.
[B] (There are no SDK toolchains for that CPU platform for versions prior to 24.10, so that with one of those older SDK generate an .ipk file: this option is not possible, because the only SDKs available for this CPU platform is for 24.10.x )
[C] We don't know, even if we could generate an .ipk package file for dropbear for that CPU platform, if current dropbear (requiring the latest versions of libraries) could run there, because the router is running a variant of Chaos_calmer 15.05.1, so the libraries could be old. E.g., the SDK cross-compilation left also these packages versions as required:

     dropbear-2024.86-r1.apk
     dropbearconvert-2024.86-r1.apk
     libatomic1-14.3.0-r4.apk
     libc-1.2.5-r4.apk
     libgcc1-14.3.0-r4.apk
     libpthread-1.2.5-r4.apk
     librt-1.2.5-r4.apk
     libstdcpp6-14.3.0-r4.apk

while the versions the router has are:

     router# opkg list-installed | grep -e librt -e libatomic -e libc -e libgcc1  -e  libpthread -e libstdcpp6 -e dropbear
         libc - 1.1.16-1
         libcurl - 7.58.0-1
         libpthread - 1.1.16-1
         librt - 1.1.16-1
         uclibcxx - 0.2.4-1

-although opkg supports alternate installation paths, to install there those libraries and not to conflict with the existing ones.)

[D] One workaround would be to compile dropbear statically without a package and without any library dependency, and to pass such dropbear binary as-is to the router. E.g., like the binary from the SDK cross-compilation at

     ./staging_dir/<path>/usr/sbin/dropbear

The issue seems to be that this binary obtained by the SDK 24.10 cross-compilation requires an interpreter (and we guess that it requires the proper version of this interpreter, which might be different in Chaos_calmer 15.05.1):

   $ file  ./staging_dir/<path>/usr/sbin/dropbear
        ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-aarch64.so.1, with debug_info, not stripped

(This binary also needs to be stripped.)

Please, if you know how to compile a dropbear in such circumstances, let us know.

Thank you very much for your attention and patience. (Huge thanks indeed, it seems difficult at first hand how to install a current dropbear in such environment.)

2

You need to ask the manufacturer for help. OpenWrt 15.05 is entirely unsupported here in general, and manufacturer forks are "black-boxes" to us since we don't know what they've done.

That almost certainly won't work because of, at the very least, kernel version differences.

You are welcome to help bring support for that device to official OpenWrt:

... or you can reach out to the vendor for help (and hopefully their SDK).

But this is entirely out of scope for anything we can help you with.

1 Like
3
  • Chaos Clamer is over 10 years old and unsupported
  • Chaos Calmer didn't use musl

Compile software for a 10 year old highly-modified OS that we know nothing about. Highly unlikely.

1 Like