Skip to content
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.

Sign up for GitHub

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

Jump to bottom

pkg: initial import of emb6 stack #4713

Merged
merged 5 commits into from
Mar 31, 2016
Merged

pkg: initial import of emb6 stack #4713

merged 5 commits into from
Mar 31, 2016

Conversation

miri64
Copy link
Member

@miri64 miri64 commented Jan 29, 2016

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 wrapper
  • conn
    • conn_ip wrapper (not done because not simple).
    • conn_udp wrapper

Depends on #4646 (merged).

@miri64 miri64 added State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet Type: new feature The issue requests / The PR implemements a new feature for RIOT Area: pkg Area: External package ports State: waiting for other PR State: The PR requires another PR to be merged first labels Jan 29, 2016
@miri64 miri64 added this to the Release 2016.03 milestone Jan 29, 2016
@miri64 miri64 force-pushed the pkg/port/emb6 branch 5 times, most recently from f5ec779 to ec881f8 Compare February 7, 2016 18:54
@miri64 miri64 removed the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Feb 7, 2016
@miri64
Copy link
Member Author

miri64 commented Feb 7, 2016

No longer WIP.

OlegHahm
OlegHahm reviewed Feb 15, 2016
View reviewed changes
pkg/emb6/Makefile
@@ -0,0 +1,33 @@
PKG_NAME=emb6
PKG_URL=git://github.com/hso-esk/emb6.git
Copy link
Member

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.)

Copy link
Member Author

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.

@OlegHahm
Copy link
Member

How can I test? I tried flashing on iotlab-m3 nodes and use ping6, but couldn't see any result (neither success nor failure).

OlegHahm
OlegHahm reviewed Feb 15, 2016
View reviewed changes
tests/emb6/main.c
}

static const shell_command_t shell_commands[] = {
{ "ping6", "Send and receive pings", ping_cmd },
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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?

@miri64
Copy link
Member Author

miri64 commented Feb 16, 2016

How can I test? I tried flashing on iotlab-m3 nodes and use ping6, but couldn't see any result (neither success nor failure).

I tested with samr21-xpro and it worked. Don't know if there is a significant difference in the radios that could cause this.

@miri64
Copy link
Member Author

miri64 commented Feb 16, 2016

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".

@OlegHahm
Copy link
Member

FYI: I usually run tests with PR on top of master.

@miri64
Copy link
Member Author

miri64 commented Feb 16, 2016

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?

@OlegHahm
Copy link
Member

I don't understand the first variant.

@miri64
Copy link
Member Author

miri64 commented Feb 18, 2016

I'm to lazy to rebase all the dependencies, so you have to wait until they got merged ;)

@miri64
Copy link
Member Author

miri64 commented Feb 23, 2016

Rebased to current #4646.

@miri64
Copy link
Member Author

miri64 commented Feb 24, 2016

Rebased to current #4646.

This was referenced Mar 5, 2016
Closed
Merged
@kYc0o
Copy link
Contributor

kYc0o commented Mar 30, 2016

Great! I'll test now

@kYc0o
Copy link
Contributor

kYc0o commented Mar 30, 2016

A simple make works at the build step, testing if the test itself works...

@miri64
Copy link
Member Author

miri64 commented Mar 30, 2016

Destroyed something lwIP related. Will look into it :/

@kYc0o
Copy link
Contributor

kYc0o commented Mar 30, 2016

the test works like a charm, tested with 2 samr21-xpro

@miri64
Copy link
Member Author

miri64 commented Mar 30, 2016

Fixed lwIP override and Murdock related issues.

@miri64
Copy link
Member Author

miri64 commented Mar 30, 2016

udoo issue seems to be more an issue with #5028 #5064.

@miri64
Copy link
Member Author

miri64 commented Mar 30, 2016

@haukepetersen any idea?

@OlegHahm
Copy link
Member

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

@kaspar030
Copy link
Contributor

I vote that we make an exception for this PR regarding the PR.

You mean regarding the feature freeze? +1

@OlegHahm
Copy link
Member

Yes, sorry, too late, too many open PRs. ;-)

@miri64 miri64 mentioned this pull request Mar 30, 2016
Merged
@miri64
Copy link
Member Author

miri64 commented Mar 30, 2016

Provided a fix for the LED issue on udoo at #5212

@haukepetersen haukepetersen added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Mar 31, 2016
@haukepetersen
Copy link
Contributor

#5212 is merged, restarted Murdock

@miri64
Copy link
Member Author

miri64 commented Mar 31, 2016

Murdock is happy :-)

@miri64
Copy link
Member Author

miri64 commented Mar 31, 2016

Do we want to find out what happens on @emmanuelsearch's machine before merging or should we make a follow-up of that?

@emmanuelsearch
Copy link
Member

let me try again.

@emmanuelsearch
Copy link
Member

still the same error. Something must be broken in my setup.
If it works for other people, I'd say: let's merge it.
I will try to narrow down on my problem, and open an issue later if need be.

@miri64
Copy link
Member Author

miri64 commented Mar 31, 2016

Then I only need an ACK.

@kYc0o
Copy link
Contributor

kYc0o commented Mar 31, 2016

ACK

@miri64
Copy link
Member Author

miri64 commented Mar 31, 2016

\o/

@miri64 miri64 merged commit 8ab89c4 into RIOT-OS:master Mar 31, 2016
@miri64 miri64 deleted the pkg/port/emb6 branch March 31, 2016 22:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@OlegHahm OlegHahm

Labels
Area: pkg Area: External package ports CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: new feature The issue requests / The PR implemements a new feature for RIOT
Projects
None yet
Milestone
Release 2016.04
Development

Successfully merging this pull request may close these issues.

None yet
6 participants
@miri64 @OlegHahm @emmanuelsearch @kYc0o @kaspar030 @haukepetersen