net: initial import of the ZEP protocol #2627

miri64 · 2015-03-17T15:35:41Z

Main idea is to use this with native as "fully" supported IEEE 802.15.4 device.

This modules is both a ng_netdev and ng_netapi module. It speaks through UDP via ng_netapi, but imitates an IEEE 802.15.4 device through ng_netdev to be indistinguishable from normal devices.

~~Depends on #2430.~~ (merged)

Fixes #163

haukepetersen · 2015-03-18T11:59:11Z

Did you choose the naming yourself or is this a (well-known) protocol of some sort? Havn't heard about it so far...

Also I don't seem to understand this implementation. What is the duality of netdev and netapi about? And why does the protocol need it's own nettype entry? If it is running on top of UDP, netdev and the nettype should not be needed!

OlegHahm · 2015-03-18T12:02:30Z

It's a Wireshark specific header: https://www.wireshark.org/docs/dfref/z/zep.html It's on RIOT's wishlist for a long time: #163

miri64 · 2015-03-18T12:40:02Z

Also I don't seem to understand this implementation. What is the duality of netdev and netapi about? And why does the protocol need it's own nettype entry? If it is running on top of UDP, netdev and the nettype should not be needed!

Yes, nettype might be replaceable with port demux_ctx. The netdev inclusion is explained in the description: this module will mock a netdev-compatible IEEE 802.15.4 device. For the major use-case (debugging/testing 6LoWPAN) the stack would look like that:

+-------------------+
|   App   |   ZEP   |---+
+-------------------+   |
|        UDP        |   |
+-------------------+   |
|       IPv6        |   |
+---------+---------+   |
|  nomac  | 6LoWPAN |   |
+---------+---------+   |
| tapnet  |  nomac  |   |
+---------+---------+   |
     |    | zep_dev |---+
    TAP   +---------+

[edit: added addition App layer]

haukepetersen · 2015-03-18T16:06:07Z

I am not completely sure if I understand it fully, but if it is the way I am thinking this is indeed useful. So +1 for this.

But there is still stuff missing in the implementation, right?

miri64 · 2015-03-18T16:07:07Z

Yes it is still WIP.

miri64 · 2015-04-26T02:46:02Z

I've done some work on this again, and it's based on UDP (#2430) now.

The basic behavior (send data frames and receive data frames) should work now. I reorder and document the stuff when I find some time, but in general I would add no more further functionally to the module for now.

miri64 · 2015-04-27T07:35:18Z

Rebased to current master

OlegHahm · 2015-04-27T08:24:13Z

@Lotterleben, if you don't want to review just re-assign to me (or someone else). I'm definitely interested in reviewing, but my backlog is increasing by the minute...

miri64 · 2015-07-01T17:55:16Z

Squashed. Only merge conflict was regarding the change in 6eb6367.

miri64 · 2015-07-01T18:03:58Z

WTF … okay somehow the history is broken… Will fix

miri64 · 2015-07-01T18:11:24Z

Somehow the commit that is now d5d4b3f was deleted when I squashed in bulk. Now that I squashed and reordered step by step everything is fine. The statement to merge conflicts still upholds, its SHA is now 089bbdb

miri64 · 2015-07-01T20:14:18Z

PR needed some fixing. Can I have a re-ACK?

OlegHahm · 2015-07-02T07:50:47Z

re-ACK, but don't merge yet. @haukepetersen wanted to review, too.

haukepetersen · 2015-07-02T09:17:54Z

Japp, doing it as we speak

miri64 · 2015-07-02T09:43:15Z

Squashed and fixed the disconcerning naming of new to new_pkt.

haukepetersen · 2015-07-02T09:43:43Z

sys/net/application_layer/ng_zep/ng_zep.c

+    dev->dst.u64[0] = dst->u64[0];
+    dev->dst.u64[1] = dst->u64[1];
+    dev->dst_port = dst_port;
+    dev->version = 2;


is the version expected to change? Otherwise we could throw it out and make it constants?!

Not in the current version. An older version of this implementation send version 1 packets and it is still possible with an easy update of ng_netconf.h (and setting this variable), which I neglected for now.

TL;DR changing the version is possible, but not implemented yet though.

miri64 · 2015-07-02T12:28:59Z

Rebased to current master to simplify testing and updated for changes in #3159

haukepetersen · 2015-07-02T13:27:26Z

Code wise I am fine with the PR for now. Though it does not work on my system: When rebasing on the newest master, initialize zep on two nodes and ping from one to the other, the receiver crashes (segfaults) when receiving neighbor solicitations over the ZEP interface. I put this in our debugging list...

So if this PR is working for other people, I am ok with merging ZEP as is and fixing the findings in a next step. If it is working for no-one, it needs to be fixed first! :-)

miri64 · 2015-07-02T13:38:03Z

It works for me and @PeterKietzmann in the most current version (which is already rebased to the most current master) so what's the verdict? Should I squash?

haukepetersen · 2015-07-02T13:42:35Z

ack

miri64 · 2015-07-02T13:47:35Z

Squashed

net: initial import of the ZEP protocol

miri64 · 2015-07-02T14:31:32Z

\o/

miri64 assigned thomaseichinger Mar 17, 2015

miri64 added this to the Network Stack Task Force milestone Mar 17, 2015

miri64 added the NSTF label Mar 17, 2015

miri64 removed this from the Network Stack Task Force milestone Mar 17, 2015

miri64 force-pushed the zep/feat/initial branch from 4ca772a to fed5104 Compare March 21, 2015 01:26

miri64 changed the title ~~net: intial import of the ZEP protocol~~ net: initial import of the ZEP protocol Mar 24, 2015

OlegHahm force-pushed the master branch 3 times, most recently from 9f184dd to 45554bf Compare March 31, 2015 13:01

miri64 mentioned this pull request Apr 9, 2015

[SWP] coap plugtests #1801

Closed

miri64 mentioned this pull request Apr 23, 2015

net/ieee802154: changed FCF to act as bitfield #2355

Closed

miri64 force-pushed the zep/feat/initial branch from fed5104 to 971a62a Compare April 26, 2015 02:43

miri64 added State: waiting for other PR State: The PR requires another PR to be merged first and removed State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet labels Apr 26, 2015

miri64 force-pushed the zep/feat/initial branch from 971a62a to 862c6de Compare April 27, 2015 07:34

miri64 removed the State: waiting for other PR State: The PR requires another PR to be merged first label Apr 27, 2015

OlegHahm assigned Lotterleben and unassigned thomaseichinger Apr 27, 2015

miri64 removed the CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable label Jul 1, 2015

miri64 force-pushed the zep/feat/initial branch from 6eb6367 to ab190e8 Compare July 1, 2015 18:00

miri64 force-pushed the zep/feat/initial branch from ab190e8 to 089bbdb Compare July 1, 2015 18:10

miri64 added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Jul 1, 2015

miri64 added CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable and removed Community: Hack'n'ACK candidate This PR is a candidate for review and discussion during one of RIOT's monthly Hack'n'ACK parties labels Jul 1, 2015

miri64 force-pushed the zep/feat/initial branch from 25ad6b9 to e97c42a Compare July 2, 2015 09:42

haukepetersen reviewed Jul 2, 2015
View reviewed changes

miri64 force-pushed the zep/feat/initial branch from f701c70 to 531fb64 Compare July 2, 2015 12:28

miri64 added 3 commits July 2, 2015 15:47

net: intial import of the ZEP protocol

c531833

tests: add ZEP test application

d96f23f

ng_zep: add stability note

d450079

miri64 force-pushed the zep/feat/initial branch from 531fb64 to d450079 Compare July 2, 2015 13:47

miri64 removed the CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable label Jul 2, 2015

miri64 added a commit that referenced this pull request Jul 2, 2015

Merge pull request #2627 from authmillenon/zep/feat/initial

b138c91

net: initial import of the ZEP protocol

miri64 merged commit b138c91 into RIOT-OS:master Jul 2, 2015

miri64 deleted the zep/feat/initial branch July 2, 2015 14:31

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

net: initial import of the ZEP protocol #2627

net: initial import of the ZEP protocol #2627

miri64 commented Mar 17, 2015

haukepetersen commented Mar 18, 2015

OlegHahm commented Mar 18, 2015

miri64 commented Mar 18, 2015

haukepetersen commented Mar 18, 2015

miri64 commented Mar 18, 2015

miri64 commented Apr 26, 2015

miri64 commented Apr 27, 2015

OlegHahm commented Apr 27, 2015

miri64 commented Jul 1, 2015

miri64 commented Jul 1, 2015

miri64 commented Jul 1, 2015

miri64 commented Jul 1, 2015

OlegHahm commented Jul 2, 2015

haukepetersen commented Jul 2, 2015

miri64 commented Jul 2, 2015

haukepetersen Jul 2, 2015

miri64 Jul 2, 2015

haukepetersen Jul 2, 2015

miri64 commented Jul 2, 2015

haukepetersen commented Jul 2, 2015

miri64 commented Jul 2, 2015

haukepetersen commented Jul 2, 2015

miri64 commented Jul 2, 2015

miri64 commented Jul 2, 2015

net: initial import of the ZEP protocol #2627

net: initial import of the ZEP protocol #2627

Conversation

miri64 commented Mar 17, 2015

haukepetersen commented Mar 18, 2015

OlegHahm commented Mar 18, 2015

miri64 commented Mar 18, 2015

haukepetersen commented Mar 18, 2015

miri64 commented Mar 18, 2015

miri64 commented Apr 26, 2015

miri64 commented Apr 27, 2015

OlegHahm commented Apr 27, 2015

miri64 commented Jul 1, 2015

miri64 commented Jul 1, 2015

miri64 commented Jul 1, 2015

miri64 commented Jul 1, 2015

OlegHahm commented Jul 2, 2015

haukepetersen commented Jul 2, 2015

miri64 commented Jul 2, 2015

haukepetersen Jul 2, 2015

Choose a reason for hiding this comment

miri64 Jul 2, 2015

Choose a reason for hiding this comment

haukepetersen Jul 2, 2015

Choose a reason for hiding this comment

miri64 commented Jul 2, 2015

haukepetersen commented Jul 2, 2015

miri64 commented Jul 2, 2015

haukepetersen commented Jul 2, 2015

miri64 commented Jul 2, 2015

miri64 commented Jul 2, 2015