Hello All, Alan, Looking at the Dropbear repository, it still appears to be active: https://github.com/mkj/dropbear. A new version was released a few days ago. Therefore, I will implement a build-time solution that fetches a specific commit SHA. This SHA could be configurable through Kconfig.
I will use Telnet and init.d as reference cases while we decide on the best integration approach. Em qui., 14 de mai. de 2026 às 14:43, Matteo Golin <[email protected]> escreveu: > Personally I think we should just do init.d. NSH should really stop being > the de-facto do-all program and just be a shell. > > On Thu, May 14, 2026, 7:10 PM Michal Lenc <[email protected]> wrote: > > > Telnet deamon is also automatically spawned from NSH init via call to > > nsh_telnetstart function if CONFIG_NSH_DISABLE_TELNETSTART option is not > > set. > > > > https://github.com/apache/nuttx-apps/blob/master/nshlib/nsh_init.c#L176 > > > > It should be easy to replicate this for SSH as well. I would vote to > > include this option as well for ssh port to keep it independent on > > init.d approach. It's then super easy for the user to configure SSH and > > get it running without needing to figure out init.d. > > > > Michal > > > > On 5/14/26 17:12, Tomek CEDRO wrote: > > > Hello Felipe and thank you for this work, it is much desired and > > appreciated :-) > > > > > > Regarding the daemons you can take a look at telnetd or dhcpd (and > > > other daemons): > > > > > > https://github.com/apache/nuttx-apps/tree/master/netutils/telnetd > > > https://github.com/apache/nuttx-apps/tree/master/netutils/dhcpd > > > > > > Regarding the daemon startup there is a current INIT.D approach and > > > new upcoming NXINIT. Daemon should also handle system signals for > > > restart, kill, etc, for manual handling. You should NOT start daemons > > > from board logic, not these should be entry points in place of nsh, > > > this is bad and non-portable practice because other boards would not > > > have this functionality without modification, and no other application > > > could run concurrently in a standardized way. Here is some detailed > > > info on NuttX initialization: > > > > > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629500#NuttXInitializationSequence-nsh_initialize() > > > > > > The INIT.D approach is similar to any Unix like systems where shell > > > scripts from /etc/init.d/ are executed on system start. Please stick > > > to this solution for now. Here is an example: > > > > > > > > > https://github.com/apache/nuttx/tree/master/boards/sim/sim/sim/src/etc/init.d > > > > > > NXINIT is a work in progress and would provide more granular control > > > over system services, but I am not sure if it is already usable and/or > > > documented? This can be next step after INIT.D approach is working :-) > > > > > > There are two more things to consider with SSHD: > > > > > > 1. You need to be ready to support both FLAT and PROTECTED builds, see > > > https://nuttx.apache.org/docs/latest/guides/protected_build.html. > > > > > > 2. There are many different ways to implement sshd from system, > > > crypto, libraries, and signals point of view. That would impact > > > efficiency, complexity, and code size. Dropbear may be good reference > > > starting point with measurable results. But looking at ssh related > > > proposals for GSoC this year there were some really nice ideas on how > > > things can be improved in specific places. Please take a look at them > > > maybe these will inspire you in some areas when in pinch :-) > > > > > > Thank you and have fun! :-) > > > Tomek > > > > > > -- > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > > > On Thu, May 14, 2026 at 1:22 PM Felipe Moura Oliveira > > > <[email protected]> wrote: > > >> Hi all, > > >> > > >> I am working on a preliminary Dropbear server port for NuttX and would > > like > > >> to confirm the expected integration approach before moving further. > > >> > > >> As a starting point, I followed David’s ESP-IDF-based steps and, after > > some > > >> adjustments, I was able to get Dropbear running on an ESP32-C3. I then > > >> started porting it to NuttX. > > >> > > >> For the initial proof of concept, I placed the Dropbear server code > > under > > >> apps/netutils and kept the integration as simple as possible. With > this > > >> approach, I was able to get it working. > > >> > > >> Before improving the port, I would like to confirm whether this is the > > >> correct location for the Dropbear source code, or if there is a more > > >> appropriate place in the NuttX apps tree. > > >> > > >> I also have a question about service initialization. Currently, I need > > to > > >> manually start the Dropbear application. My expectation is that the > SSH > > >> server should be started automatically when enabled in the > > configuration. > > >> > > >> However, as far as I understand, there is no generic apps autostart > > >> mechanism that works across all boards. The alternative would be to > add > > >> board-specific startup logic in each board bring-up code, but I would > > >> prefer to avoid that if possible. > > >> > > >> What would be the recommended approach for initializing this kind of > > >> network service in NuttX? Should this be handled by board bring-up > > logic, > > >> NSH initialization, an application-level startup mechanism, or some > > other > > >> pattern? > > >> > > >> Any guidance on the preferred architecture would be appreciated > before I > > >> continue refining the port. > > >> > > >> > > >> -- > > >> *Felipe Moura de Oliveira* > > >> *Universidade Federal de Minas Gerais* > > >> Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0> > > >> <https://twitter.com/FelipeMOliveir?lang=pt-br> > > > > > -- *Felipe Moura de Oliveira* *Universidade Federal de Minas Gerais* Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0> <https://twitter.com/FelipeMOliveir?lang=pt-br>
