-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pkg: initial import of emb6 stack #4713
Conversation
f5ec779
to
ec881f8
Compare
No longer WIP. |
@@ -0,0 +1,33 @@ | |||
PKG_NAME=emb6 | |||
PKG_URL=git://github.com/hso-esk/emb6.git |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any particular reason for not using the http URL here?
(Just realized that in some networks other ports may be blocked, while port 80 is usually open.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general: because it's faster than http(s). But when reading the doc I realized that Git made some advancements and has a Smart HTTP protocol now, too.
How can I test? I tried flashing on iotlab-m3 nodes and use ping6, but couldn't see any result (neither success nor failure). |
} | ||
|
||
static const shell_command_t shell_commands[] = { | ||
{ "ping6", "Send and receive pings", ping_cmd }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A shell comand to receive pings?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It registers the ping receive callback if not already set, so I would say so, yes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So without executing this command, the node won't answer with pongs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wi pongs you mean echo replies, right? Yes, without calling this command no handling of echo replies is done, as most ping implementations do. Whyshould it expect replies if it did not sent any requests yet?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I wrote "won't answer with pongs" (aka ICMP echo replies) and that's not a behavior I've ever seen from a ping implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A node answers to echo requests (regardless of the fact that this command was called or not). Echo replies need not be answered (because they are already answers AKA replies), just handled and I don't know any implementation that handles them without a request send beforehand: Neither does this the GNRC implementation nor do I know any linux host that handles randomly incoming pongs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Read again: the command description says "Send and receive pings" and my only question was about if I need to perform this command to be able to receive pings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah so the wording is all you wanted to change. Better in the current commit?
I tested with |
Just an update about emb6: according to it's developers its currently based upon https://github.com/contiki-os/contiki/tree/43aeddbd89c7b7a2ba0a8c51ef3c713b2142857c (about a year old, pre v3.0) with plans for an update in "the near future". |
FYI: I usually run tests with PR on top of master. |
Then you either must wait until the backlog got merged or live with some merge commits here. What way do you prefer? |
I don't understand the first variant. |
I'm to lazy to rebase all the dependencies, so you have to wait until they got merged ;) |
afa24ab
to
d62c1c2
Compare
Rebased to current #4646. |
d62c1c2
to
0cbf181
Compare
Rebased to current #4646. |
Great! I'll test now |
A simple make works at the build step, testing if the test itself works... |
Destroyed something lwIP related. Will look into it :/ |
the test works like a charm, tested with 2 samr21-xpro |
Fixed lwIP override and Murdock related issues. |
@haukepetersen any idea? |
I vote that we make an exception for this PR regarding the feature freeze. But if it's not merged until Sunday, we must postpone. corrected - thanks @kaspar030 |
You mean regarding the feature freeze? +1 |
Yes, sorry, too late, too many open PRs. ;-) |
Provided a fix for the LED issue on udoo at #5212 |
#5212 is merged, restarted Murdock |
Murdock is happy :-) |
Do we want to find out what happens on @emmanuelsearch's machine before merging or should we make a follow-up of that? |
let me try again. |
still the same error. Something must be broken in my setup. |
Then I only need an ACK. |
ACK |
\o/ |
emb6 is a fork of Contiki's uIP without the requirement for proto-threads. As with #3551 this is import is mainly for benchmarking, but maybe some of you are interested in a smaller 6LoWPAN stack.
Still WIP.
netdev2
wrapperconn
(not done because not simple).conn_ip
wrapperconn_udp
wrapperDepends on
#4646(merged).