Whitefield with contiki-ng about whitefield HOT 44 CLOSED

@philok93 #93 adds support for contiki-ng in Whitefield.

• cmd_* are stubbed and working.
• I tested that nodes are sending/receving msgs but the network is not getting formed. I guess some debugging is still required. Pcap is normally created and the logs show normal output.

The problem with undefined references .. was handled by sequencing the libs in the Makefile.

The plan to directly use native-mode binaries is still on but I thought this can be handled soon for you to continue with your experiments.

from whitefield.

Hello,
Is there support for contiki-ng along with this whitefield framework? I would like to see a combination with the recent development of contiki.

contiki-ng is not supported, but it should be easy to add since contiki Whitefield platform code (I am hoping) can be reused as-is. If you can give me some background about what you are trying to do, maybe I can try to hack it up in a week's time.

Also, do you plan to add any other features like border router in contiki?

Right now, the border-router is supported but it does not take the traffic out of the simulation. You can argue, technically this is the main function of BR and it doesn't do it and I will have to concede. I had plans to add it apart from tons of things, check out https://trello.com/b/9bdugZxX/project-whitefield

from whitefield.

Hi,
thank for your reply! Well I already use contiki-ng and trying to study the behaviour of RPL-lite so that I can create an IDS for z1 motes. Also, I made modification to allow sniffing in the mac layer and ipv6 layer. Cooja is very slow in large networks and the BR cannot handle more than 10 routes/neighbors in the routing table. If I move into whitefield, the BR have unlimited space for neighbors and routes?
My idea is to integrate contiki-ng into your framework so that using ns3 I can simulate large networks. But its important to me to support sniffing packets from nodes and sending custom rpl packets to other nodes. The example I use is rpl-udp.

from whitefield.

Hi,
thank for your reply! Well I already use contiki-ng and trying to study the behaviour of RPL-lite so that I can create an IDS for z1 motes. Also, I made modification to allow sniffing in the mac layer and ipv6 layer. Cooja is very slow in large networks and the BR cannot handle more than 10 routes/neighbors in the routing table. If I move into whitefield, the BR have unlimited space for neighbors and routes?

That's right. Whitefield operates in native mode and thus without any memory limitations. You can change the routing/nbr table size to whatever you want.
But you mentioned about sniffing in the mac layer. For Whitefield, the mac layer is used from NS3. The packet capture in pcap format is available and exported from NS3. I am not sure if this helps you? I still don't understand what you do by sniffing in mac layer.

My idea is to integrate contiki-ng into your framework so that using ns3 I can simulate large networks. But its important to me to support sniffing packets from nodes and sending custom rpl packets to other nodes. The example I use is rpl-udp.

Sniffing packets is supported. You can change rpl-udp or contiki-rpl-layer to send whatever custom rpl packets you want to send. Infact in your case with Whitefield you can do more. For e.g., if you want to create custom packets based on some inputs at runtime. You can open a socket in rpl-udp and control it from command-line and use the input to create these custom packets.

from whitefield.

That's right. Whitefield operates in native mode and thus without any memory limitations. You can change the routing/nbr table size to whatever you want.
But you mentioned about sniffing in the mac layer. For Whitefield, the mac layer is used from NS3. The packet capture in pcap format is available and exported from NS3. I am not sure if this helps you? I still don't understand what you do by sniffing in mac layer.

Actually I want to sniff packets from neighbours and calculate metrics such as packets drops/number of DIO,DIS packets etc. The pcap capture helps me to calculate these stats for overall networks metrics.
When I mentioned for mac layer, I wanted to pass the filtering done by nodes when a packet arrives so a sniffer node does not drop it. So, I changed the mac and ip layer to allow processing of packets destined to other neighbours so that metrics can be calculated by sniffer node.

Sniffing packets is supported. You can change rpl-udp or contiki-rpl-layer to send whatever custom rpl packets you want to send. Infact in your case with Whitefield you can do more. For e.g., if you want to create custom packets based on some inputs at runtime. You can open a socket in rpl-udp and control it from command-line and use the input to create these custom packets.

I agree, changing rpl packets for me now is the solution but if you have this feature in whitefield may sounds better. I plan to make an intrusion detection that specific motes will communicate (using custom rpl packets) based on some parameters and take decisions. All these if I could simulate in large-scale will be great. Do you have any paper written for whitefield framework? I see also you have RPL npdao but for me I just use the current implementation of RPL-lite in contiki-ng.
If you can import contiki-ng into whitefield I believe will be a great idea because your framework will be accessible to more people as the community on contiki is large.

from whitefield.

That's right. Whitefield operates in native mode and thus without any memory limitations. You can change the routing/nbr table size to whatever you want.
But you mentioned about sniffing in the mac layer. For Whitefield, the mac layer is used from NS3. The packet capture in pcap format is available and exported from NS3. I am not sure if this helps you? I still don't understand what you do by sniffing in mac layer.

Actually I want to sniff packets from neighbours and calculate metrics such as packets drops/number of DIO,DIS packets etc. The pcap capture helps me to calculate these stats for overall networks metrics.

How would you get the packet drops for multicast packets? DIO/DIS are both (mostly) multicast.

When I mentioned for mac layer, I wanted to pass the filtering done by nodes when a packet arrives so a sniffer node does not drop it. So, I changed the mac and ip layer to allow processing of packets destined to other neighbours so that metrics can be calculated by sniffer node.

So you need promiscuous mode such that you receive packets from all regardless the destination/source. This also is supported in NS3-pcap but right now is not enable by default in Whitefield. I can put a knob in config for this. For ref:

Currently, it is false by default but can be made configurable.

Sniffing packets is supported. You can change rpl-udp or contiki-rpl-layer to send whatever custom rpl packets you want to send. Infact in your case with Whitefield you can do more. For e.g., if you want to create custom packets based on some inputs at runtime. You can open a socket in rpl-udp and control it from command-line and use the input to create these custom packets.

I agree, changing rpl packets for me now is the solution but if you have this feature in whitefield may sounds better. I plan to make an intrusion detection that specific motes will communicate (using custom rpl packets) based on some parameters and take decisions. All these if I could simulate in large-scale will be great.

Large-scale realistic simulation is Whitefield's forte. I have tested with 1200 nodes max but not on a laptop but a 3.xGHz desktop machine.

Do you have any paper written for whitefield framework?

Nope, there ain't no paper as of now. I am interested but it seems too much effort which I would rather invest in extending whitefield.

I see also you have RPL npdao but for me I just use the current implementation of RPL-lite in contiki-ng.
If you can import contiki-ng into whitefield I believe will be a great idea because your framework will be accessible to more people as the community on contiki is large.

I will try to analyze how best to do this in a few days and then post the high-level design here for more feedback. I know that most folks are interested in using their own version of contiki/riot and not use the version that Whitefield integrates with. I need to solve this issue in a way that Whitefield should simply use or take input the native-mode compiled binary from the user and then somehow patch the Whitefield platform code on top of this binary. Does it make sense to you?

from whitefield.

How would you get the packet drops for multicast packets? DIO/DIS are both (mostly) multicast.
I agree that almost all nodes receive multicast packets. In my project I want is to count how many packets are TX from a node, what kind of packets are TX (DIS flooding,DIO,DAO,UDP), sniff all these, count/calculate a formula, and find if its an attacker that floods the networks.

Another thing I plan to do (if also possible here), is to create two DODAG instances at the same time using 1 BR. I want for example a normal DODAG network with nodes to work along with IDS DODAG (which has sniffers and communicate in other network for security reasons) using the same BR (or even another BR to make things easier) to take decisions like to ban an attacker node. In contiki-ng, multiple DODAG is not supported because its light implementation. Would this be possible or will be a constraint of contiki?

Another thing, will be possible to use powertracker (for energy measuring) as usual in contiki and whitefield framework?

So you need promiscuous mode such that you receive packets from all regardless the destination/source. This also is supported in NS3-pcap but right now is not enable by default in Whitefield. I can put a knob in config for this. For ref:

Currently, it is false by default but can be made configurable.

This sounds good, if configurable will be better!

I will try to analyze how best to do this in a few days and then post the high-level design here for more feedback. I know that most folks are interested in using their own version of contiki/riot and not use the version that Whitefield integrates with. I need to solve this issue in a way that Whitefield should simply use or take input the native-mode compiled binary from the user and then somehow patch the Whitefield platform code on top of this binary. Does it make sense to you?

Giving as input only mote as binary will be even great to allow simulations in your framework. This will allow anyone with custom changes in contiki/riot to compile and just run the binary in your framework. But of course importing whitefield platform into contiki it's the first step. I will wait for a description on how to make this possible :)
I really appreciate your effort to build this platform! I hope that will help me to create some results to publish as in the literature researchers are using mostly cooja.

from whitefield.

If you have any updates on how-to for contiki-ng please write. I currently tried to make some modifications but seems I can't compile (have error with lbwf_commline.a, undefined reference to cmd_rpl_stats). Thanks!

from whitefield.

This is the plan.

Terms used:

stackline: Any network stack implementation such as Contiki, Contiki-ng, RIOT, Openthread, Zephyr.
airline: Air interface simulation engine. Currently only NS3.
commline: Conduit between stackline and Airline.

An overview of how to integrate

Use input as native-mode compiled binary of Contiki-ng. In native-mode, Contiki uses a TUN interface to send/receive packets to other nodes. Use LD_PRELOAD to override tun-create, tun-send/recv and use it to operate on Whitefield's commline fd.

Using LD_PRELOAD to integrate Whitefield platform stubs

tun-create will be overridden to return the Whitefield's Unix domain socket descriptor (check cl_get_descriptor()) which it uses on commline to communicate with NS3.

Note that tun interface is applicable only to Contik-NG and other stackline's may not use tun interface. For e.g., OpenThread uses UDP sockets to communicate. So the LD_PRELOAD will have to override UDP sockets. The ensuing code after overriding tun/UDP socket will remain the same.

Contiki uses command line input for specifying node ID which is, in turn, made use of for forming the L2 address (eventually getting used to form IPv6 address). This means that the main has to be overridden. Libc __libc_start_main() can be overrided by ld_preload which in turn can supply node ID to contiki's main().

Impact on airline

Doing this would imply that stackline is in charge of L2 header framing which is currently handled in Airline-NS3. However, NS3 is designed to support only PHY+MAC with L2 framing handled by other components. Thus this should be easy to handle. OpenThread anyways needs this support because it mixes L2 frame headers between 802.15.4 long-addresses and short-addresses.

Impact on OAM

Since now the Whitefield does not tightly couple with Contiki (or any other stackline), there is an impact on OAM. Currently wfshell talks to Contiki Whitefield's platform code to get internal Contiki stats. Now the OAM has to use Contiki's internal "shell process" to get these stats. Actually this arrangement is better because this removes any API dependency of Whitefield from stackline's code. Also this becomes generic i.e., applicable to any stackline because every stackline provides some sort of shell (I know RIOT, Contiki-NG, OpenThread support their own shell, haven't looked in Zephyr).

Pros of this approach

1. Easier integration: Users can compile stackline (Contiki, RIOT, OpenThread, zephyr) in their environment in Linux native-mode and present the binary to the Whitefield.
2. Less dependency on future changes in any stackline. The only dependency is the interface stackline uses to send/recv. For e.g., if Contiki in the future changes TUN to something else then Whitefield will stop working. I should add a way to identify this and give an early error in Whitefield.
3. This approach will work consistently across any stackline (Contiki, Contiki-NG, RIOT, Zephyr, OpenThread which compiles in native mode). In the future, it will be very easy to integrate with LWIP and Linux kernel stack implementation.

Cons of this approach

LD_PRELOAD only works with dynamic libraries and the assumption is that the user is using standard Linux distros which uses glibc as a shared so. I believe this should not be a problem.

Tasks involved:

• Override using LD_PRELOAD
  • Override main() with __libc_start_main() to provide node ID
  • Override tun-create and return Whitefield's FD from cl_get_descriptor()
  • Wrap tun-send/recv using Whitefield's commline
  • Wrap tun-ioctl() to not return failure.
• NS3 updates
  • Remove L2 header framing from NS3
• OAM updates
  • Provide access to stackline's shell from Whitefield framework
  • Make NS3 pcap available in promiscuous mode. Check discussion in this thread above.
• (Low priority) Identify binary type (Contiki, RIOT etc) and apply LD_PRELOAD rules accordingly.
• Give an error in Whitefield if certain expected interfaces such as tun-create etc were not observed getting called from stackline on startup.

from whitefield.

If you have any updates on how-to for contiki-ng please write. I currently tried to make some modifications but seems I can't compile (have error with lbwf_commline.a, undefined reference to cmd_rpl_stats). Thanks!

cmd_rpl_stats needs to be implemented in Contiki-NG's Whitefield platform code. An undefined ref is easy to debug. I am assuming that you just copied Contiki Whitefield's platform code to Contki-ng? This should work.

from whitefield.

Really detailed plan on your post! So you think its easy to integrate it until end of week?

cmd_rpl_stats needs to be implemented in Contiki-NG's Whitefield platform code. An undefined ref is easy to debug. I am assuming that you just copied Contiki Whitefield's platform code to Contki-ng? This should work.

Yeah I just copied the platform to Contiki-ng in contiki/arch/platform/whitefield/ and I see that
cmd_rpl_stats (also other 7-8 commands) are located in command.c. Where should I implement it? Maybe needs change in makefile.

from whitefield.

Really detailed plan on your post! So you think its easy to integrate it until end of week?

No way, until the end of week. I plan to handle this during the first week of May. But I see no technical risk except for NS3 header framing point and so it should be done by the end of first week of May.

cmd_rpl_stats needs to be implemented in Contiki-NG's Whitefield platform code. An undefined ref is easy to debug. I am assuming that you just copied Contiki Whitefield's platform code to Contki-ng? This should work.

Yeah I just copied the platform to Contiki-ng in contiki/arch/platform/whitefield/ and I see that
cmd_rpl_stats (also other 7-8 commands) are located in command.c. Where should I implement it? Maybe needs change in makefile.

Yep most likely your Makefile is not correct. Let me know if I can help, and if yes, share your updated contiki-ng code.

from whitefield.

No way, until the end of week. I plan to handle this during the first week of May. But I see no technical risk except for NS3 header framing point and so it should be done by the end of first week of May.

Alright sounds good, I will try to implement something until then as I am in hurry to write a paper soon.

Yep most likely your Makefile is not correct. Let me know if I can help, and if yes, share your updated contiki-ng code.

Well the makefile in contik-ng is different. Here it is:

CONTIKI_PROJECT = udp-client udp-server
all: $(CONTIKI_PROJECT)

CONTIKI=../..
include $(CONTIKI)/Makefile.include

Based on configuration system, the project-conf. h is already included so is different from contikios makefile
https://github.com/contiki-ng/contiki-ng/wiki/The-Contiki%E2%80%90NG-configuration-system
Build system:
https://github.com/contiki-ng/contiki-ng/wiki/The-Contiki%E2%80%90NG-build-system

Command: make TARGET=whitefield viewconf

When I run make from the whitefield root folder, it compiles correctly the libwf_commline.a library in the bin/ but this is the problem it shows:

Where should I implement the cmd functions so that contiki can have visibility? Also, I tried and changed all the commline files include <> into "" to avoid other issues.
In the /contiki/platform/whitefield I modified headers to be correct but still face this problem.

Here is the makefile.whitefield under platform folder:

ifndef CONTIKI
  $(error CONTIKI not defined! You must specify where CONTIKI resides!)
endif

ifeq ($(HOST_OS),Darwin)
  AROPTS = rc
endif

WF_DIR=../../../..
ifeq ($(wildcard $(WF_DIR)/src/.*),)
WF_DIR=../../../../..
endif

include $(WF_DIR)/config.inc
CFLAGS+=-I$(WF_DIR)/src/
TARGET_LIBFILES+=-L$(WF_DIR)/bin -lwf_commline -ldl 

CONTIKI_TARGET_DIRS = . dev
CONTIKI_TARGET_MAIN = ${addprefix $(OBJECTDIR)/,contiki-main.o}

CONTIKI_TARGET_SOURCEFILES = contiki-main.c clock.c wfmac_driver.c wfradio_driver.c \
    button-sensor.c pir-sensor.c vib-sensor.c sensors.c command.c command_storing_mop.c \
    command_ns_mop.c

CONTIKI_SOURCEFILES += $(CONTIKI_TARGET_SOURCEFILES)

.SUFFIXES:

### Define the CPU directory
CONTIKI_CPU=$(CONTIKI)/arch/cpu/native
include $(CONTIKI_CPU)/Makefile.native

MODULES+=os/net os/net/mac os/net/ipv6/ip64-addr

from whitefield.

In your compilation screenshot, I could not see command.c getting compiled! Wonder why?
Anyways, you can simply remove these commands dependencies from Whitefield since you don't need them. You can comment out PLAY_CMDs from src/commline/cl_stackline_helpers.c and it should be fine. You aren't going to use these stats commands anyways. In the next version, I plan to remove these commands altogether and only depend on the internal shell provided by contiki/riot/...?

from whitefield.

In your compilation screenshot, I could not see command.c getting compiled! Wonder why?
Anyways, you can simply remove these commands dependencies from Whitefield since you don't need them. You can comment out PLAY_CMDs from src/commline/cl_stackline_helpers.c and it should be fine. You aren't going to use these stats commands anyways. In the next version, I plan to remove these commands altogether and only depend on the internal shell provided by contiki/riot/...?

I just removed the PLAY_CMDs and now compiles fine. At the end of compilation, I get this output:

make[7]: Nothing to be done for 'install-data-am'.
 /bin/mkdir -p '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/lib'
 /usr/bin/install -p -m 644  libopenthread-platform-utils.a '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/lib'
 ( cd '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/lib' && ranlib libopenthread-platform-utils.a )
Making install in whitefield
make[7]: Nothing to be done for 'install-data-am'.
 /bin/mkdir -p '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/lib'
 /usr/bin/install -p -m 644  libopenthread-whitefield.a '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/lib'
 ( cd '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/lib' && ranlib libopenthread-whitefield.a )
make[7]: Nothing to be done for 'install-exec-am'.
make[7]: Nothing to be done for 'install-data-am'.
Making install in apps
Making install in cli
make[7]: Nothing to be done for 'install-data-am'.
 /bin/mkdir -p '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin'
  /bin/bash ../../../libtool   --mode=install /usr/bin/install -p ot-cli-ftd ot-cli-mtd '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin'
libtool: install: /usr/bin/install -p ot-cli-ftd /home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin/ot-cli-ftd
libtool: install: /usr/bin/install -p ot-cli-mtd /home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin/ot-cli-mtd
Making install in ncp
make[7]: Nothing to be done for 'install-data-am'.
 /bin/mkdir -p '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin'
  /bin/bash ../../../libtool   --mode=install /usr/bin/install -p ot-ncp-ftd ot-ncp-mtd ot-ncp-radio '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin'
libtool: install: /usr/bin/install -p ot-ncp-ftd /home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin/ot-ncp-ftd
libtool: install: /usr/bin/install -p ot-ncp-mtd /home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin/ot-ncp-mtd
libtool: install: /usr/bin/install -p ot-ncp-radio /home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin/ot-ncp-radio
make[7]: Nothing to be done for 'install-exec-am'.
make[7]: Nothing to be done for 'install-data-am'.
make[6]: Nothing to be done for 'install-exec-am'.
make[6]: Nothing to be done for 'install-data-am'.
Making install in tests
make[6]: Nothing to be done for 'install-exec-am'.
make[6]: Nothing to be done for 'install-data-am'.
Making install in tools
Making install in spi-hdlc-adapter
make[6]: Nothing to be done for 'install-data-am'.
 /bin/mkdir -p '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin'
  /bin/bash ../../libtool   --mode=install /usr/bin/install -p spi-hdlc-adapter '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin'
libtool: install: /usr/bin/install -p spi-hdlc-adapter /home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin/spi-hdlc-adapter
make[6]: Nothing to be done for 'install-exec-am'.
make[6]: Nothing to be done for 'install-data-am'.
Making install in doc
make[5]: Nothing to be done for 'install-exec-am'.
make[5]: Nothing to be done for 'install-data-am'.
make[5]: Nothing to be done for 'install-exec-am'.

Is this normal? I will try to run it and inform you for the output.

Output when running the whitefield:

Which commands are usable now? I can't do anything,shows error when a command is run in the wfshell

Looking at the logs of normal nodes it shows errors:

[INFO: RPL       ] sending a DIS to ff02::1a
[INFO: ICMPv6    ] Sending ICMPv6 packet to ff02::1a, type 155, code 0, len 2
[INFO: 6LoWPAN   ] output: sending IPv6 packet with len 46
[WARN: 6LoWPAN   ] output: failed to calculate payload size - dropping packet
INFO  55116:675 [radio_read:90] RECV ret:29 src:1 dst:0 len:13 flags:2
INFO  55116:675 [sl_handle_cmd:123] responding with:<SL_INVALID_CMD(SL_INVALID_CMD()>
INFO  55116:881 [radio_read:90] RECV ret:29 src:1 dst:0 len:13 flags:2
INFO  55116:881 [sl_handle_cmd:123] responding with:<SL_INVALID_CMD(SL_INVALID_CMD()>

From border router I get similar:

[INFO: RPL       ] sending a multicast-DIO with rank 128 to ff02::1a
[INFO: ICMPv6    ] Sending ICMPv6 packet to ff02::1a, type 155, code 1, len 72
[INFO: 6LoWPAN   ] output: sending IPv6 packet with len 116
[WARN: 6LoWPAN   ] output: failed to calculate payload size - dropping packet
INFO  55093:602 [radio_read:90] RECV ret:26 src:0 dst:0 len:10 flags:2
INFO  55093:602 [sl_handle_cmd:123] responding with:<SL_INVALID_CMD(SL_INVALID_CMD()>
INFO  55095:816 [radio_read:90] RECV ret:26 src:0 dst:0 len:10 flags:2
INFO  55095:816 [sl_handle_cmd:123] responding with:<SL_INVALID_CMD(SL_INVALID_CMD()>
INFO  55098:25  [radio_read:90] RECV ret:26 src:0 dst:0 len:10 flags:2
INFO  55098:26  [sl_handle_cmd:123] responding with:<SL_INVALID_CMD(SL_INVALID_CMD()>
INFO  55100:200 [radio_read:90] RECV ret:26 src:0 dst:0 len:10 flags:2
INFO  55100:200 [sl_handle_cmd:123] responding with:<SL_INVALID_CMD(SL_INVALID_CMD()>

I found that by defining USE_DL in Makefile.commline, the output of BR is the following:

INFO  56372:357 [radio_read:90] RECV ret:26 src:0 dst:0 len:10 flags:2
ERROR 56372:357 [sl_handle_cmd:113] Could not load cmd: <cmd_rtsize> thirdparty/contiki/examples/rpl-udp/udp-server.whitefield: undefined symbol: cmd_rtsize

How can I fix this?

from whitefield.

make[7]: Nothing to be done for 'install-data-am'.
 /bin/mkdir -p '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/lib'
 /usr/bin/install -p -m 644  libopenthread-platform-utils.a '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/lib'
 ( cd '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/lib' && ranlib libopenthread-platform-utils.a )
Making install in whitefield
make[7]: Nothing to be done for 'install-data-am'.
 /bin/mkdir -p '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/lib'
 /usr/bin/install -p -m 644  libopenthread-whitefield.a '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/lib'
 ( cd '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/lib' && ranlib libopenthread-whitefield.a )
make[7]: Nothing to be done for 'install-exec-am'.
make[7]: Nothing to be done for 'install-data-am'.
Making install in apps
Making install in cli
make[7]: Nothing to be done for 'install-data-am'.
 /bin/mkdir -p '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin'
  /bin/bash ../../../libtool   --mode=install /usr/bin/install -p ot-cli-ftd ot-cli-mtd '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin'
libtool: install: /usr/bin/install -p ot-cli-ftd /home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin/ot-cli-ftd
libtool: install: /usr/bin/install -p ot-cli-mtd /home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin/ot-cli-mtd
Making install in ncp
make[7]: Nothing to be done for 'install-data-am'.
 /bin/mkdir -p '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin'
  /bin/bash ../../../libtool   --mode=install /usr/bin/install -p ot-ncp-ftd ot-ncp-mtd ot-ncp-radio '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin'
libtool: install: /usr/bin/install -p ot-ncp-ftd /home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin/ot-ncp-ftd
libtool: install: /usr/bin/install -p ot-ncp-mtd /home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin/ot-ncp-mtd
libtool: install: /usr/bin/install -p ot-ncp-radio /home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin/ot-ncp-radio
make[7]: Nothing to be done for 'install-exec-am'.
make[7]: Nothing to be done for 'install-data-am'.
make[6]: Nothing to be done for 'install-exec-am'.
make[6]: Nothing to be done for 'install-data-am'.
Making install in tests
make[6]: Nothing to be done for 'install-exec-am'.
make[6]: Nothing to be done for 'install-data-am'.
Making install in tools
Making install in spi-hdlc-adapter
make[6]: Nothing to be done for 'install-data-am'.
 /bin/mkdir -p '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin'
  /bin/bash ../../libtool   --mode=install /usr/bin/install -p spi-hdlc-adapter '/home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin'
libtool: install: /usr/bin/install -p spi-hdlc-adapter /home/phil/Documents/whitefield/thirdparty/openthread/output/x86_64-unknown-linux-gnu/bin/spi-hdlc-adapter
make[6]: Nothing to be done for 'install-exec-am'.
make[6]: Nothing to be done for 'install-data-am'.
Making install in doc
make[5]: Nothing to be done for 'install-exec-am'.
make[5]: Nothing to be done for 'install-data-am'.
make[5]: Nothing to be done for 'install-exec-am'.

Is this normal? I will try to run it and inform you for the output.

Yes it is. OpenThread compilation prints all these messages. You can comment OpenThread in config.inc and all this won't show up.

Output when running the whitefield:
Which commands are usable now? I can't do anything,shows error when a command is run in the wfshell

Oh, the monitor.sh depends on cmd_rtsize cmd.

Looking at the logs of normal nodes it shows errors:

[INFO: RPL       ] sending a DIS to ff02::1a
[INFO: ICMPv6    ] Sending ICMPv6 packet to ff02::1a, type 155, code 0, len 2
[INFO: 6LoWPAN   ] output: sending IPv6 packet with len 46
[WARN: 6LoWPAN   ] output: failed to calculate payload size - dropping packet
INFO  55116:675 [radio_read:90] RECV ret:29 src:1 dst:0 len:13 flags:2
INFO  55116:675 [sl_handle_cmd:123] responding with:<SL_INVALID_CMD(SL_INVALID_CMD()>
INFO  55116:881 [radio_read:90] RECV ret:29 src:1 dst:0 len:13 flags:2
INFO  55116:881 [sl_handle_cmd:123] responding with:<SL_INVALID_CMD(SL_INVALID_CMD()>

From border router I get similar:

[INFO: RPL       ] sending a multicast-DIO with rank 128 to ff02::1a
[INFO: ICMPv6    ] Sending ICMPv6 packet to ff02::1a, type 155, code 1, len 72
[INFO: 6LoWPAN   ] output: sending IPv6 packet with len 116
[WARN: 6LoWPAN   ] output: failed to calculate payload size - dropping packet
INFO  55093:602 [radio_read:90] RECV ret:26 src:0 dst:0 len:10 flags:2
INFO  55093:602 [sl_handle_cmd:123] responding with:<SL_INVALID_CMD(SL_INVALID_CMD()>
INFO  55095:816 [radio_read:90] RECV ret:26 src:0 dst:0 len:10 flags:2
INFO  55095:816 [sl_handle_cmd:123] responding with:<SL_INVALID_CMD(SL_INVALID_CMD()>
INFO  55098:25  [radio_read:90] RECV ret:26 src:0 dst:0 len:10 flags:2
INFO  55098:26  [sl_handle_cmd:123] responding with:<SL_INVALID_CMD(SL_INVALID_CMD()>
INFO  55100:200 [radio_read:90] RECV ret:26 src:0 dst:0 len:10 flags:2
INFO  55100:200 [sl_handle_cmd:123] responding with:<SL_INVALID_CMD(SL_INVALID_CMD()>

I found that by defining USE_DL in Makefile.commline, the output of BR is the following:

INFO  56372:357 [radio_read:90] RECV ret:26 src:0 dst:0 len:10 flags:2
ERROR 56372:357 [sl_handle_cmd:113] Could not load cmd: <cmd_rtsize> thirdparty/contiki/examples/rpl-udp/udp-server.whitefield: undefined symbol: cmd_rtsize

How can I fix this?

USE_DL won't work. The right way to fix this is to implement cmd_rtsize in contiki-ng just like for contiki.

from whitefield.

@philok93 #93 adds support for contiki-ng in Whitefield.

• cmd_* are stubbed and working.
• I tested that nodes are sending/receving msgs but the network is not getting formed. I guess some debugging is still required. Pcap is normally created and the logs show normal output.

The problem with undefined references .. was handled by sequencing the libs in the Makefile.

The plan to directly use native-mode binaries is still on but I thought this can be handled soon for you to continue with your experiments.

Amazing work @nyrahul ! Thanks so much! I will try now and see why network is not formed.
To my understanding, you use PHY,MAC from NS-3 and RPL+APP layer from Contiki? Maybe I need to investigate this how they communicate.
From what I see in monitor.sh, Route entries on node 0: 0 is always 0. However, in logs it seems routes are created and nodes communicate normally.Seems strange.

Also, is it possible to start node numbering from 1? Because in Cooja it starts from 1 and doesn't exist 0, maybe plays a role in topology.
Another thing I consider now is that energy consumption will not be possible here as all nodes are native .. as I have no experience with NS3, there is no possibility to simulate a battery-powered node like Zolertia Z1 (used in Cooja) and allow only BR to be the native node? I found this https://www.nsnam.org/docs/models/html/energy.html but need some guidelines how can import libraries to ns3 if you know.
Your plan to use native-mode binaries maybe support this but for now I need to study ns3.

Regarding the panID, if I specify 2 panIDs will create two DODAG instances at the same time using 1 BR? I want for example a normal DODAG network with nodes to work along with IDS DODAG (which has sniffers and communicate in other network) using the same BR (or even another BR to make things easier) to take decisions like to ban an attacker node. In contiki-ng, multiple DODAG is not supported because its light implementation. Would this be possible with ns-3?

from whitefield.

@philok93 #93 adds support for contiki-ng in Whitefield.

• cmd_* are stubbed and working.
• I tested that nodes are sending/receving msgs but the network is not getting formed. I guess some debugging is still required. Pcap is normally created and the logs show normal output.

The problem with undefined references .. was handled by sequencing the libs in the Makefile.
The plan to directly use native-mode binaries is still on but I thought this can be handled soon for you to continue with your experiments.

Amazing work @rabinsahoo! Thanks so much!

Totally my pleasure. Great to go along. Btw, you tagged the wrong person. However, Rabi also is a contributor to Whitefield and a good friend of mine.

I will try now and see why network is not formed.
To my understanding, you use PHY,MAC from NS-3 and RPL+APP layer from Contiki? Maybe I need to investigate this how they communicate.

Yes Phy and MAC layer are from NS3 (even the 802.15.4 framing is done in NS3 right now which will be changed in future). RPL + TCP/UDP IP + APP layer from contiki.

From what I see in monitor.sh, Route entries on node 0: 0 is always 0. However, in logs it seems routes are created and nodes communicate normally.Seems strange.

Contiki API uip_ds6_route_num_routes() is used to get the routes and it seems to be always returning 0.

Also, is it possible to start node numbering from 1? Because in Cooja it starts from 1 and doesn't exist 0, maybe plays a role in topology.

Whitefield starts from node 0 and node 0 is the BR. The scripts assume node 0 is the BR and queries cmd_rtsize from this node. However, node 0 is configurable.

In scripts/helpers.sh

For Whitefield to start with specific node ID is also possible, you can edit the config/wf-contiki-ng.cfg:

Replace $NODEID to $NODEID+1

Another thing I consider now is that energy consumption will not be possible here as all nodes are native .. as I have no experience with NS3, there is no possibility to simulate a battery-powered node like Zolertia Z1 (used in Cooja) and allow only BR to be the native node? I found this https://www.nsnam.org/docs/models/html/energy.html but need some guidelines how can import libraries to ns3 if you know.

Energy consumption measurements are not possible now as of now. It's a shame! I do not even have a design. I just have it on my todo list.

Your plan to use native-mode binaries maybe support this but for now I need to study ns3.

Regarding the panID, if I specify 2 panIDs will create two DODAG instances at the same time using 1 BR?

Two panIDs cannot be used right now. Remember that 802154 framing currently happens in NS3 and DODAG handling is in RPL/Contiki. This problem will be solved with native-mode binary usage wherein NS3 will no longer be handling framing. Just the Phy layer and the contention access in the mac layer will be handled in NS3. Contiki also does not support use of different panIDs for different instances.

You want to use different panIDs to easily filter out packets intended for IDS processing?

I want for example a normal DODAG network with nodes to work along with IDS DODAG (which has sniffers and communicate in other network) using the same BR (or even another BR to make things easier) to take decisions like to ban an attacker node.

Multiple DODAGs within an RPL Instance share the same objective function and the nodes are free to jump between the DODAGs. A node can only be part of one DODAG in a given Instance. I believe what you want is that the same node is attached to two different instances?

In contiki-ng, multiple DODAG is not supported because its light implementation. Would this be possible with ns-3?

Whitefield-NS3 does not/should not do IP layer handling. Multiple DODAGs have to be supported in stackline i.e., contiki-ng in your case. But in your case, I am not sure if you need multiple DODAGs or multiple instances. Your case sounds like you need multiple instances. http://blog.rjed.org/rpl/2019/06/15/rpl_multi_instances_vs_multi_dodags/ might help clear.

from whitefield.

Hi @nyrahul

Contiki API uip_ds6_route_num_routes() is used to get the routes and it seems to be always returning 0.

That's strange. From logs, I see that nodes exchange DAO, DAO-ACK is sent from BR, nodes select a parent but seems BR is not saving the neighbors? Need to check it.

Whitefield starts from node 0 and node 0 is the BR. The scripts assume node 0 is the BR and queries cmd_rtsize from this node. However, node 0 is configurable.

In scripts/helpers.sh

For Whitefield to start with specific node ID is also possible, you can edit the config/wf-contiki-ng.cfg:

Replace $NODEID to $NODEID+1

I configured it as you told me but when printing the graph I get:

wfsh# plot_network_graph t1 p1
Dumped tree based network graph to file t1
Error: node 12 in graph position_network has no position
as required by the -n flag
Dumped position based network graph to file p1

Should I change something else?

Energy consumption measurements are not possible now as of now. It's a shame! I do not even have a design. I just have it on my todo list.

Oh.. so I can't use the NS3 energy module to import it into whitefield like a normal NS3 project? I still can't understand how I can modify whitefield to take more metrics or send a new packet to node. Even if I do it in simulation only, I would need to do it in contiki for a later real-testbed. Maybe I still implement my ideas in contiki and use whitefield for simulating only.

Two panIDs cannot be used right now. Remember that 802154 framing currently happens in NS3 and DODAG handling is in RPL/Contiki. This problem will be solved with native-mode binary usage wherein NS3 will no longer be handling framing. Just the Phy layer and the contention access in the mac layer will be handled in NS3. Contiki also does not support use of different panIDs for different instances.

You want to use different panIDs to easily filter out packets intended for IDS processing?

Actually yes if that's possible.Check my idea below.

Multiple DODAGs within an RPL Instance share the same objective function and the nodes are free to jump between the DODAGs. A node can only be part of one DODAG in a given Instance. I believe what you want is that the same node is attached to two different instances?

Whitefield-NS3 does not/should not do IP layer handling. Multiple DODAGs have to be supported in stackline i.e., contiki-ng in your case. But in your case, I am not sure if you need multiple DODAGs or multiple instances. Your case sounds like you need multiple instances. http://blog.rjed.org/rpl/2019/06/15/rpl_multi_instances_vs_multi_dodags/ might help clear.

I will try to explain you better my problem. Let's say I have 3 udp-clients connected to 1 udp-server. What I want is to create a new node called udp-sniffer, which will join the network and sniff packets of other 3 udp-clients. This sniffer however should not participate in the network like a normal node because imagine that its more safe to separate it from the DODAG used in the normal network. This sniffer will communicate with other sniffers ONLY to exchange data and inform the udp-server (which should be the same as normal BR or can be another udp-server) to take decisions for the IDS. Generally, udp-sniffer must exchange packet if needed only with other sniffers and should not select parent a udp-client (sniffer should behave like being in a different network and avoid responding to DIO,DAO or even forwarding packets of normal nodes). Is it possible this? Based on your blog I think having 2 DODAGs in one RPL instance is the best candidate as sniffers will have their own communication, will sniff packets from other DODAGs/nodes and make some processing based on these packets.
Another thing I would like to implement is to enable udp-sniffer to send packet to a udp-client. But this I know will be difficult and future improvement. Also, BR should be the same because all packets in RPL-lite go through BR and then reach their destination.

I hope you can understand my problems and ideas. I am open to any suggestions on how to implement this :)

from whitefield.

This requires two different RPL Instances.
Instance 1 for udp-clients.
Instance 2 for sniffers.
UDP clients and sniffers will join only their respective instances.
Using multiple DODAGs in the same Instance, how will you limit sniffers from attaching to udp-clients. Are you planning to put a check based on DODAGID? Using multiple DODAGIDs from root means that the root needs to have multiple global ipv6 addresses on its lowpan interface.

from whitefield.

This requires two different RPL Instances.
Instance 1 for udp-clients.
Instance 2 for sniffers.
UDP clients and sniffers will join only their respective instances.
Using multiple DODAGs in the same Instance, how will you limit sniffers from attaching to udp-clients. Are you planning to put a check based on DODAGID? Using multiple DODAGIDs from root means that the root needs to have multiple global ipv6 addresses on its lowpan interface.

I agree with you but seems impossible in contiki-ng to implement this (correct?). That's why I am thinking to find a way to avoid a sniffer to attach in a udp-client. If it was possible with 2 DODAGs I would check based on DODAGID..but you are right I need to add ipv6 addresses.
An idea for now is that if I hardcode in the source code 2 RPL instance IDs, nodes will work correctly in the simulation?
Regarding the nbr count displayed 0, I think the function call should be uip_sr_num_nodes() because only root has route table in RPL-lite (non-storing mode). Also, I found the uip_ds6_nbr_num() function but returns the neigbours, not routes.

But still have the problem of last node:

Error: node 12 in graph position_network has no position

from whitefield.

Using two dags is more difficult than two instances.
I am wondering if you could do this:
Compile two sets of binaries each with a different rpl instance. Even the br will be different. The two Br can talk to each other on backplane. With backplane I mean fallback interface in cooja. When using Whitefield you can make use of regular sockets since it’s native mode.

from whitefield.

This requires two different RPL Instances.
Instance 1 for udp-clients.
Instance 2 for sniffers.
UDP clients and sniffers will join only their respective instances.
Using multiple DODAGs in the same Instance, how will you limit sniffers from attaching to udp-clients. Are you planning to put a check based on DODAGID? Using multiple DODAGIDs from root means that the root needs to have multiple global ipv6 addresses on its lowpan interface.

I agree with you but seems impossible in contiki-ng to implement this (correct?). That's why I am thinking to find a way to avoid a sniffer to attach in a udp-client. If it was possible with 2 DODAGs I would check based on DODAGID..but you are right I need to add ipv6 addresses.
An idea for now is that if I hardcode in the source code 2 RPL instance IDs, nodes will work correctly in the simulation?
Regarding the nbr count displayed 0, I think the function call should be uip_sr_num_nodes() because only root has route table in RPL-lite (non-storing mode). Also, I found the uip_ds6_nbr_num() function but returns the neigbours, not routes.

This can be fixed easily then. I will have a go at it tomm.

But still have the problem of last node:

Error: node 12 in graph position_network has no position

Will check this too tomm.

from whitefield.

Using two dags is more difficult than two instances.
I am wondering if you could do this:
Compile two sets of binaries each with a different rpl instance. Even the br will be different. The two Br can talk to each other on backplane. With backplane I mean fallback interface in cooja. When using Whitefield you can make use of regular sockets since it’s native mode.

I tried to build 2 udp-servers with different instance IDs but udp-clients select any of udp-servers as parent (compiled also udp-clients with differnt rpl instance id). Is it normal or should join only the instance defined RPL_CONF_DEFAULT_INSTANCE they have as default?

from whitefield.

Using two dags is more difficult than two instances.
I am wondering if you could do this:
Compile two sets of binaries each with a different rpl instance. Even the br will be different. The two Br can talk to each other on backplane. With backplane I mean fallback interface in cooja. When using Whitefield you can make use of regular sockets since it’s native mode.

I tried to build 2 udp-servers with different instance IDs but udp-clients select any of udp-servers as parent (compiled also udp-clients with differnt rpl instance id). Is it normal or should join only the instance defined RPL_CONF_DEFAULT_INSTANCE they have as default?

This is not normal. The node must join only to the instance they have been configured to join. And I can see that the code to handle this is present:

Also I fixed the cmd_rtsize based on your suggestion and it seems to be working.

It takes almost a minute and a half for 10 nodes to join! As compared to my earlier observations this time is high.

from whitefield.

This is not normal. The node must join only to the instance they have been configured to join. And I can see that the code to handle this is present:

Also I fixed the cmd_rtsize based on your suggestion and it seems to be working.

It takes almost a minute and a half for 10 nodes to join! As compared to my earlier observations this time is high.

I don't know why it takes so long for all nodes to join. Maybe problem of commline and contiki?
Regarding the instance ID, I saw that nodes join the instance that they first receive in DIO. So I just added a check in the process_dio_init_dag() in rpl-dag.c to accept only specific rpl instance id. In Cooja works but whitefield seems no.
Thanks for the help :) We still need to configure correctly the nodes numbering and the rest problems.

For 2 udp-servers, do you support it now in whitefield? Because I see that network is not formed.

from whitefield.

I am trying to check how 2 udp-servers can be deployed in whitefield. Also, I check the promiscuous mode and see if works. If you have any idea for both of them let me know 😃

from whitefield.

I am trying to check how 2 udp-servers can be deployed in whitefield. Also, I check the promiscuous mode and see if works. If you have any idea for both of them let me know

I will try this on weekend, if you face any problems doing it.

from whitefield.

I wonder, how can I configure TX/RX range for the nodes? Is it configurable from NS3 and whitefield takes them as default?

I will try this on weekend, if you face any problems doing it.

Thanks a lot! I will need some help to add it monitor.sh and show 2 BR.

from whitefield.

I wonder, how can I configure TX/RX range for the nodes? Is it configurable from NS3 and whitefield takes them as default?

The only thing you can configure is TX power level. TX/RX range is determined internally by NS3 and that is the whole point of using Whitefield .... i.e., you want realistic RF.

I will try this on weekend, if you face any problems doing it.

Thanks a lot! I will need some help to add it monitor.sh and show 2 BR.

What I plan to do is take the BR id as an optional input for monitor.sh ... This way you can have two monitor.sh running each showing its own network. This needs to be generalized for other tools (such as plot_network) as well.

from whitefield.

The only thing you can configure is TX power level. TX/RX range is determined internally by NS3 and that is the whole point of using Whitefield .... i.e., you want realistic RF.

Ok then I can leave it as it is the PHY/MAC layer config. I want to make sure that nodes are in range of each other when I deploy random topologies. That's how I did it in cooja. If have any tips on how to define the max distance between nodes will really help me.

What I plan to do is take the BR id as an optional input for monitor.sh ... This way you can have two monitor.sh running each showing its own network. This needs to be generalized for other tools (such as plot_network) as well.

Yeah, it will be great idea to show 2 monitor for different networks. For now, I managed to show nodes connected to 2 server and works good. Nodes join the specified RPL instance. The only problem is the plotting of network graph. Here is the result:

Tree:

Position:

Normally, the network should be: 3-->0(parent) and 2-->1 (parent)
Something is wrong with plot. Its always showing node 1 having self-arrow. My config is:

nodeExec[0]=thirdparty/contiki-ng/examples/rpl-udp/udp-server-instance0.whitefield $NODEID AUTO_START=1
nodeExec[1]=thirdparty/contiki-ng/examples/rpl-udp/udp-server-instance1.whitefield $NODEID AUTO_START=1
nodeExec[2]=thirdparty/contiki-ng/examples/rpl-udp/udp-client-instance1.whitefield $NODEID AUTO_START=1
nodeExec[3]=thirdparty/contiki-ng/examples/rpl-udp/udp-client-instance0.whitefield $NODEID AUTO_START=1

Is there other way to visualize network? I saw that nsanim exists for ns3 but should not work for us.

from whitefield.

Another problem I have is that I enabled promiscuous mode as you told me in previous posts, but sniffed packets appear only in pcap. They are not processed/forwarded to higher layers. Do you know how to achieve this? Thanks a lot!

from whitefield.

Another problem I have is that I enabled promiscuous mode as you told me in previous posts, but sniffed packets appear only in pcap. They are not processed/forwarded to higher layers. Do you know how to achieve this? Thanks a lot!

The sniffed packets will only appear in pcap. Those are not meant to be forwarded to the node. This needs to be checked on how to achieve this. Does Cooja support such mode?

For enabling logs for IPv6/ or other module, you need to change the corresponding contiki-ng source code file and enable the print. I have done that only for RPL/sicslowpan module as of now.

from whitefield.

The sniffed packets will only appear in pcap. Those are not meant to be forwarded to the node. This needs to be checked on how to achieve this. Does Cooja support such mode?

Yes in Cooja I could modify the MAC layer to allow input packets that are not destined for the node, to process them and go up to IP layer. Is not possible to modify AirlineManager.cc in the msgrecvCallback to forward all packets up?
In contiki-ng also exist the function packetbuf_addr(PACKETBUF_ADDR_RECEIVER) to get the receiver of the packet (not the final destination). By this I can check if packet is destined for the node or if it should forward the packet to next hop. Now, the packet structure is different in NS3, right?

For enabling logs for IPv6/ or other module, you need to change the corresponding contiki-ng source code file and enable the print. I have done that only for RPL/sicslowpan module as of now.

I found it yes thanks! I look forward to your help for the visualization of graph problem described before.

from whitefield.

The sniffed packets will only appear in pcap. Those are not meant to be forwarded to the node. This needs to be checked on how to achieve this. Does Cooja support such mode?

Yes in Cooja I could modify the MAC layer to allow input packets that are not destined for the node, to process them and go up to IP layer. Is not possible to modify AirlineManager.cc in the msgrecvCallback to forward all packets up?
In contiki-ng also exist the function packetbuf_addr(PACKETBUF_ADDR_RECEIVER) to get the receiver of the packet (not the final destination). By this I can check if packet is destined for the node or if it should forward the packet to next hop. Now, the packet structure is different in NS3, right?

For enabling logs for IPv6/ or other module, you need to change the corresponding contiki-ng source code file and enable the print. I have done that only for RPL/sicslowpan module as of now.

I found it yes thanks! I look forward to your help for the visualization of graph problem described before.

Can you attach your udp-client/server bins here?

from whitefield.

Sure, check the arhive. The udp-client-sniffer connects to udp-server-instance1 (both are compiled with instance 1).

mybins.zip

from whitefield.

In Airline.cc, the function void Airline::SendPacketToStackline(McpsDataIndicationParams & params, Ptr<Packet> p) sends packet to contiki? I was thinking if we can modify the destination node_id to send packet to sniffer (with specific id) so that can sniff all packets in the RX range of node.

from whitefield.

As I understand you want to sendpacket to the node as well as sniffer in the SendPacketToStackline()? Currently monitor/forker have special purpose nodeid. Similarly, you can have a special-purpose nodeid for the sniffer.

from whitefield.

As I understand you want to sendpacket to the node as well as sniffer in the SendPacketToStackline()? Currently monitor/forker have special purpose nodeid. Similarly, you can have a special-purpose nodeid for the sniffer.

Yeah I would like to send packets in RX range of sniffer to it so I can do calculations. How special-purpose nodeid is generated?

from whitefield.

As I understand you want to sendpacket to the node as well as sniffer in the SendPacketToStackline()? Currently monitor/forker have special purpose nodeid. Similarly, you can have a special-purpose nodeid for the sniffer.

I try to understand the code and find this special nodeid. The SPAWN_STACKLINE(GetNode()->GetId()) references to device 0? So stackline starts only on BR 0? I really appreciate if you explain me a bit the airline code so I can add a special id to forward packets to sniffers.

from whitefield.

As I understand you want to start your own sniffer process and get the packets going to all the nodes in that process.

You can follow forker.c. Forker forks the stackline processes and also monitors for external OAM command. Usually the message routing is done based on node-id. But forker/monitor don't have node-ID and hence they are considered special.

Following are the steps you need to do:

1. Add your own SNIFFER below MONITOR in the above enum.
2. Start your own process and do cl_init(CTYPE(SNIFFER, CL_MGR_ID), CL_ATTACHQ)
3. Wait on cl_recvfrom_q(MTYPE(SNIFFER, CL_MGR_ID), mbuf, sizeof(buf), 0) after initing.
4. In airline use cl_sendto_q(MTYPE(SNIFFER, CL_MGR_ID), mbuf, sizeof(msg_buf_t)); alongside existing node send.

This was all the messages from all the nodes would be received in the sniffer process on recvfrom.

from whitefield.

Thanks a lot for your detail instructions! This means that all the messages from all the nodes are received only if they are in RX range? I mean I don't want a sniffer to get a message from a node that is not in its RX range. If it's happening like this then it will not be realistic.
The point 3 I am not sure where to put it in the code.

To make it more clear, I would like to receive the packets (from TX range) in the contiki-ng so that when they arrive in RPL layer, nodes will perform some calculations.

from whitefield.

Thanks a lot for your detail instructions! This means that all the messages from all the nodes are received only if they are in RX range? I mean I don't want a sniffer to get a message from a node that is not in its RX range. If it's happening like this then it will not be realistic.
The point 3 I am not sure where to put it in the code.

To make it more clear, I would like to receive the packets in the contiki-ng so that when they arrive in RPL layer, nodes will perform some calculations.

Is it clear what I want to achieve? I tried to implement your instructions but didn't understand where to put the line of point 3. Is another process sniffer really needed to sniff packets of my neighbours?

from whitefield.

closing this issue as Contiki-NG is now supported in Whitefield.

from whitefield.