Re: [riot-devel] RIOT integration options for Whitefield

[Rahul Jadhav]

Thank you. I ll look into zep and understand pros and cons with this mode of 
integration.
Thanks for the discussion.

Regards,
Rahul 

> On 21-Mar-2018, at 6:09 PM, Martine Lenders  wrote:
> 
> Hi Rahul,
> 
> (context for the rest of the list: we talked f2f today about this after lwig 
> @ IETF101)
> 
> I agree with Ludwig that option 2 is the best option to implement this. If 
> you looking for a template to implement against netdev, have a look at 
> `socket_zep` [1] (and ignore what I proposed at our F2F meeting ;-)). I think 
> this can give you a good idea, since it is also an emulated network device, 
> based on IEEE 802.15.4 (though it is lacking some features like channel 
> selection and other radio related options).
> 
> Cheers,
> Martine
> 
> [1] 
> https://github.com/RIOT-OS/RIOT/blob/master/cpu/native/socket_zep/socket_zep.c
> 
> 2017-07-31 20:25 GMT+01:00 Rahul Jadhav :
>> 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  
>>> 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 :
 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
 

Re: [riot-devel] RIOT integration options for Whitefield

[Martine Lenders]

Hi Rahul,

(context for the rest of the list: we talked f2f today about this after
lwig @ IETF101)

I agree with Ludwig that option 2 is the best option to implement this. If
you looking for a template to implement against netdev, have a look at
`socket_zep` [1] (and ignore what I proposed at our F2F meeting ;-)). I
think this can give you a good idea, since it is also an emulated network
device, based on IEEE 802.15.4 (though it is lacking some features like
channel selection and other radio related options).

Cheers,
Martine

[1]
https://github.com/RIOT-OS/RIOT/blob/master/cpu/native/socket_zep/socket_zep.c

2017-07-31 20:25 GMT+01:00 Rahul Jadhav :

> 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 
> 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  >:
>
> 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
> 

Re: [riot-devel] RIOT integration options for Whitefield

[Rahul Jadhav]

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  
> 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 :
>> 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

Re: [riot-devel] RIOT integration options for Whitefield

[Ludwig Knüpfer]

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 :
>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

[riot-devel] RIOT integration options for Whitefield

[Rahul Jadhav]

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