Programmatic shell access

[immesys]

It would be useful to be able to execute shell commands programmatically. For example, my app might want to change radio channel, add an IP address, start RPL etc. There are many such tasks that are trivial to do via the shell, but often quite complex to do via the underlying commands.

With a bit of care to concurrent access, I believe this can be done by exporting the handle_input_line symbol that is currently static in the shell handling code. Before I do the work to make a pull request though, I wanted to ask how other people have been solving this problem. How have people been making nodes that "come up" configured automatically? Perhaps I am going about this the complete wrong way?

[LudwigKnuepfer]

I'd say this is not a good idea.
Did you look at the respective shell commands implementations, see what they do and try to add the same calls in your main?

[immesys]

Initially I was also very against this idea. Then I attempted to execute the same calls without using the shell and discovered that as almost everything used by the shell commands is static, it can take more than 100 lines of code to do something as simple as change channel, set an IP address and start RPL. It requires a long sequence of low level calls, to things like gnrc_netapi_set. There are also a lot of lines doing things like getting the prefix length from the IP address, checking if it is multicast, obtaining handles to the interfaces and so on.

Of course I would prefer a function based API for these tasks. I guess my main concern is the massive gap in difficulty between doing these tasks from the shell and doing them using the underlying calls. It is at least 20x more lines of code doing the latter. This means that moving from a demo on your desk to a setup where it starts working as soon as you plug in the battery is much harder than I would expect.

In addition, there are no examples or documentation for the underlying function API, whereas the shell is extremely well documented with many tutorials. I am not sure it is fair to new users of RIOT to say "in order to make a headless node, the most common mode of use in IoT, you need to delve into an area barren of examples that is much harder than the shell you have used so far"

[miri64]

As far as I read your comment you mainly need some kind of API to set the options for a network interface. Since I ported other stacks for RIOT in the past weeks (see #4713 and #3551) I saw from a totally different problem space (interface initialization + reimplementation of test features) that the current way to go with GNRC isn't ideal. As soon as I find some time (hopefully as of April) I will try to create some common network interface API that could solve this problem.

[jnohlgard]

I wrote a proof of concept implementation for this a while back. I'll post it tomorrow if I remember, otherwise ping me on Monday.

[OlegHahm]

How have people been making nodes that "come up" configured automatically?

I usually outsource this problem to the host side and use pyterm's (undocumented) abilities to trigger commands at startup time, execute shell commands sequentially, define triggers and aliases and so on. Since pyterm is pure Python other functionalities can be added super simple here.

[immesys]

My nodes are not attached to computers, so that approach does not work for me, but it is essentially what I was proposing: being able to execute shell commands automatically

[OlegHahm]

How do you use the shell without a serial connection?

[miri64]

And wouldn't it be way more efficient to just use the functions called by the shell handlers directly?

[miri64]

@gebart

I wrote a proof of concept implementation for this a while back. I'll post it tomorrow if I remember, otherwise ping me on Monday.

For the feature requested in this issue or my proposal of a unified NIC API?

[jnohlgard]

@authmillenon for programmatic shell access

[OlegHahm]

Maybe I misunderstood the initial question or the purpose of this issue: is it about automation of tests or about adding convenience function to the network stack (and the like) for production environment where you don't want to include the shell?

[kYc0o]

As far as I understand (maybe as @OlegHahm say), there's nothing to do with the shell itself, I think it is taken as an example to show that shell commands provides functionalities like iface configuration (channel, address, routes, etc), packet sending using UDP, and so on that are very easy to use through it.

On the other hand, if I want to deactivate the shell (yes, I'm kinda crazy hein?) and setup a node to use some specific channel, IP config and an UDP server waiting for requests in an specified port, that I just power on batteries, it could take several lines of code, that can be reduced for instance if I can call the shell commands that allows to do this easily.

Sometimes people wants something like:

int main()
{
    set_radio_channel(26);
    start_udp_server(1234, my_callback_function);
    led_on(LED_RED);
}

my_callback_function(char *buf)
{
    printf("received udp message on port 1234: %s", buf);
    /* edit: ok, I don't have a shell... */
    led_toggle(LED_RED);
}

Is this possible on RIOT?

[immesys]

Yeah, that's exactly what I'm getting at.

[jnohlgard]

OK, I can't find my previous experiment, but the basic gist of what I did was that I defined a char * autorun_lines[] = { "ps", "ifconfig 7 set page 2", "rpl init 7", NULL }; and in the shell_run function, iterate through that autorun array until the first NULL pointer and call handle_input_line on each element.
I think there was some kind of copying involved as well because the buffer passed to handle_input_line had to be writable, but I don't remember and I didn't try to recreate the code today, it was very ugly anyway and only made for a small proof of concept/test run

[immesys]

My hack looks quite similar:

void sh(char *c)
{
  char lbuf[100];
  strcpy(lbuf, c);
  handle_input_line(NULL, lbuf);
}
int main(void)
{
  sh("ifconfig 7 set chan 25\n"); 
  sh("rpl init 7\n");
 ...

[aignacio]

Hello @immesys did you have and example of creating a RPL network and communicating with udp server?

[OlegHahm]

@immesys, does this issue goes into a similar direction as #4418?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[jdavid]

I'm also interested in this.