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>
