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> > >
