Ha! That is really nice idea to have nsh also started as service along other services! That would help in hiding behind a trigger nsh even on production devices etc :-)
-- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Fri, May 15, 2026 at 9:17 AM Karel Kočí <[email protected]> wrote: > > I would add that this would be the best option, in my opinion. Having init > application that can start services, that can include nsh in the end as well. > It > would be also beneficial if it could monitor their status in some minimal way > and trigger possibly some optional fail safe (such as reset). > > But on the other hand that is another work to do. What Michal suggests is to > do, > for now, exactly what we do with telnet. Then we can both migrate to the new > init, once we implement it. Making these steps virtually independent thanks to > the precedence established by telnetd. > > My two cents.. > Karel > > > On Thu 14 May 2026 07:42:57 PM , Matteo Golin wrote: > > 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> > > > > > >
