sys/shell: added UDP shell commands #2720
Conversation
haukepetersen
added
Type: new feature
| return; | ||
| } | ||
| /* allocate IPv6 header */ | ||
| ip = ng_ipv6_hdr_build(udp, NULL, 0, (uint8_t *)&ip_addr, sizeof(ip_addr)); |
There was a problem hiding this comment.
Would prefer use of ng_netreg_hdr_build() here, so we later can swap the IP header type easily depending on the format of the IP address.
There was a problem hiding this comment.
as long as we do not have support for IPv4, I do not really see the necessity of introducing an additional function call. Once IPv4 is introduced, some of this code has to be re-factored anyhow...
|
made use of |
| @@ -159,6 +159,10 @@ extern void _netif_send(int argc, char **argv); | |||
| #endif | |||
| #endif | |||
|
|
|||
| #ifdef MODULE_NG_UDP | |||
| extern void _udp(int argc, char **argv); | |||
There was a problem hiding this comment.
Just a heads-up: shell-handlers have the signature
int void <name>(int argc, char **argv);now ;-)
There was a problem hiding this comment.
yap, I saw that (though I have no idea why that was introduced...).
OlegHahm
force-pushed
the
master
branch
3 times, most recently
from
9f184dd to
45554bf
Compare
|
As far as I can see this PR contains more than just adding the shell command, or am I mistaken? For the shell command itself, I think this is typical case for #2755. |
OlegHahm
added
the
State: waiting for other PR
|
Yes #2719 is still in here (which was merged). @haukepetersen please rebase to master. |
miri64
removed
the
State: waiting for other PR
|
will do. |
OlegHahm
added
the
State: waiting for other PR
|
rebased. It still depends on #2430. |
|
Come to think about it, why do are these commands automatically compiled in? They are more or less just test commands. Why aren't they just part of e.g. a UDP test application. |
|
(if someone wants to use them in their application they can just copy it from there) |
|
in the end, everything related to the shell is more or less for testing... How about I change this PR into a UDP example application? |
|
Yes and no. Most are for configuration or bootstrapping. I'd prefer the example application. |
|
btw that's what I meant with
|
|
Ok. The only problem at the moment is, that we do not have a network stack bootstrapping/auto_init mechanism in place. So a sample application will look most ugly at the moment... I will spend some time on the init stuff today and see if I can finally come up with something. |
|
The only thing still missing is device and MAC layer initialization. Everything above bootstraps already via their respective init functions called from |
|
Yap, but thats the interesting part :-) I will propose something here soon. |
|
|
||
| void _send(char *addr, char *port, char *data) | ||
| { | ||
| uint16_t port; |
There was a problem hiding this comment.
Is that normal that port is redefined here?
There was a problem hiding this comment.
probably not (This PR is not tested too well, and as we discussed above will be heavily re-structured anyway...)
|
I close this in favor of #2895. |
based on #2719This code is not compilable/runnable at the moment, as it depends on some IPv6 and UDP functionality, which is not yet merged...
Basically this code serves two purposes: (i) to have simple to use shell commands for sending and receiving UDP packets and (ii) for having a simple example on howto do this :-)
Update:
depends on #2430