Hi Matteo and Michal,

I think what we need is something that has the same easy way to use as
Michal noticed, but at the same time doesn't add NSH as a requirement.

I think the NXInit will help to fix this issue.

BR,

Alan

On Thu, May 14, 2026 at 2:43 PM Matteo Golin <[email protected]> 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>
> >
> >
>

Reply via email to