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.

Regards,
Rahul 

> On 31-Jul-2017, at 10:59 PM, Ludwig Knüpfer <ludwig.knuep...@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.i...@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@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Reply via email to