[riot-devel] RIOT integration options for Whitefield

Rahul Jadhav rahul.ietf at gmail.com
Mon Jul 31 21:25:55 CEST 2017

Hi Ludwig,

Communication  between whitefield and riot would be using sysv msgq IPC.(Having said that, this layer is loosely coupled and may change in future, if required). Note that these IPC calls are wrapped in a library provided by whitefield.

So if I have to picture it, I would add a driver for whitefield in riot which would essentially be of 802154_type. Would override the recv/send callback in this driver to send /recv the packet over to whitefield. I assume I can override USEMODULES in the specific example app to use this driver and automatically 6lo would come into effect(because driver is of type 802154_type) and I will get 6lo adapted packets in the send callback of this driver.

Just to add more details here about how whitefield operates: whitefield creates a virtual node (which essentially is an instantiation of node in  ns3 which provides for realistic RF) for every riot node which runs in its own individual linux process space. Whenever riot calls a send in the 802154_type driver, the packet would be passed on to the virtual node in whitefield. The packet would then be received by one or more of other virtual nodes. The packet will be sent on the IPC Interface and passed on to the appropriate riot node(s) process(es) calling the corresponding 802154_type driver's recv call, thus completing the packet lifecycle.

 The main page of whitefield github repo (https://github.com/whitefield-framework/whitefield) has a block diagram which would give a clear picture.

Also, Writing a driver would give finer control which would help in providing advanced OAM commands.


> On 31-Jul-2017, at 10:59 PM, Ludwig Knüpfer <ludwig.knuepfer at fu-berlin.de> wrote:
> Hi Rahul,
> Regarding implementation proposal 2:
> As I don't know anything about Whitefield: what would that implementation look like in detail? In particular: how would RIOT communicate with Whitefield? (Unix) socket/thread messages/other IPC?
> Cheers,
> Ludwig
> Am 30. Juli 2017 17:13:51 MESZ schrieb Rahul Jadhav <rahul.ietf at gmail.com>:
>> Hello team RIOT,
>> I m trying to integrate RIOT with a simulation framework called as
>> Whitefield (which i m developing for interop testing) ... For details:
>> https://github.com/whitefield-framework/whitefield
>> I ll use RIOT in native mode. Whitefield will provide for 802.15.4
>> phy/mac
>> and RIOT will provide for 6lo/ipv6/udp/blah.
>> As far as possible i wanted to check integration options which do not
>> involve changing RIOT.
>> For integration i ve thought of foll options:
>> 1. using tapX interface (but without tapbrX intf) ... i.e. RIOT will
>> send
>> packets on tap and whitefield will sniff in promiscous mode on tap and
>> then
>> redirect the packets to the whitefield RF layer ... similarly sending
>> pkts
>> to the RIOT node by using raw sockets and then injecting on tap
>> interface.
>> **The problem here is that with netdev_tap, 6lo adaptation is not
>> included** ... I saw an option to use gnrc_zep + gnrc_nomac which could
>> ve
>> enabled 6lo for tap (
>> https://github.com/RIOT-OS/RIOT/wiki/Testing-6LoWPAN-on-Ethernet-based-devices)
>> but seems these two modules are no more part of RIOT.
>> 2. writing a driver for whitefield in RIOT ... This would be a
>> clean/easy
>> solution (and this is what i did for contiki integration) ...  But this
>> would mean changes to RIOT, and i m not sure if RIOT team would be
>> interested in such PR.
>> 3. Another option is to use fakelb, which simulates a 802.15.4 phy intf
>> on
>> linux. Thus i assume RIOT 6lo will work on this phy device. Then i go
>> about
>> the same way with integration, the way i planned for tap interface as
>> in 1.
>> Problem here is, fakelb is not available by default, thus there are
>> clumsy
>> (kernel module compilation) setup steps and i m still not sure if this
>> is
>> the right way to go.
>> Wanted to seek advise from RIOT team regarding which option to use.
>> Thanks,
>> Rahul
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20170801/33061e7c/attachment.html>

More information about the devel mailing list