Simulation Contiki for blackhole about rpl-attacks HOT 17 CLOSED

Hey Sonxay, nice to meet you ! I'm glad you appreciate this project ! I'm always very happy to welcome newcomers on this repository.

About serial.log, if I correctly understand, you experience some problems with it. Could you post an error trace or something that could indicate an error ?

For your second question, I think this is more or less a duplicate of Issue #25 . I think you should get in contact with dmabm and SwitchIsMine for this matter as, unfortunately, I don't have time to spend on the project at this time. Please read and participate to Issue #25 , this should be an interesting sharing.

from rpl-attacks.

Hello All,
I am still looking for a solution for this mattes for nearly three weeks. I can simply start collect-view tool with brand new simulation created with cooja simulator directly, but the problem is how to integrate that in to this project.

The other thing is I was able to load a simulation created using this Framework manually, with Contiki inbuilt cooja simulator. Then I run it manually while opening the collect-view too but that tool did not capture and data form any mote. But it seems serial port is connected to project since some of the serial logs can be observed once collect-view tool is connected.

I am also a graduate student and looking for a experimental test-bed for my research stuff and generate some results to get published. So far the RPL attack framework would be the best environment I fond. (Thanks to dhonta a lot) I am also planning to make some more attacks on this framework and see the behavior of some other parameters.

If I am able to figure it out this issue, surely I will post the solution as soon as possible.

from rpl-attacks.

from rpl-attacks.

@dmabm : Did you manage to get your things work ? Or do you still have some troubles with the Collect View tool ?

NB: At a first sight, I don't figure out if your troubles are related to the following considerations but keep this in mind ; there was a change in the Javascript engine used by Cooja a few months ago. This means that, while the former version of Cooja used OpenJDK 7 with Rhino JS engine, it now uses OpenJDK 8 with Nashorn, which can cause some errors. For this problem, I added a few lines at the beginning of script.js which solved the problem while upgrading to OpenJDK 8, but I cannot confirm it is backward-compatible and pointed out that it already caused problems for @sonxay (see Issue #28 ). Maybe this change will still cause other problems...

from rpl-attacks.

from rpl-attacks.

Hi...how are you?

can I ask you some question ..?

could you tell me , how do you do the graph like the pics

how many minutes , did you run for the simulation to get the graph like this

hope i can get your askwer

thanks
regard
Sonxay

from rpl-attacks.

Hi Sonxay,

I ran like 2 minus to generate this type of graph. But I did not do it manually and these are automatically drawn or generated by the RPL attack Framework once a particular simulation is executed.

I have a questions about INT (Interference), what is this INT? and how it is calculated ? and What is this parentage (%) mean ? I need proper interpretations for my questions

Thank you
DMABM

from rpl-attacks.

Hi all,

@sonxay : As @dmabm told, the default duration of a simulation is 120 seconds and it automatically draws the graph. It uses a custom VisualizerScreenshot plugin in Cooja to get the WSN topology but also draws the DODAG with a graph library and puts the results in the subfolder results of your simulation folder. For the power consumption graphs, these are generated using pyplot while parsing the collected powertracker.log. Note that the duration can be configured through your experiment.json. For more information about configuring this, you can consult this additional documentation.

@dmabm : For the INT metric, I would consider the following :

• Each mote is ON for a reduced period during a defined interval (for low power consumption purpose)
• Each mote has an interference range (configurable through experiment.json) which influences, during its ON period, the transmission of other motes that are also ON in its interference range
• INT thus expresses the contributions of other motes in the range of the considered one

More concretely :

• Looking at Radio.java, you can see the following code :

   /**
   * Returns true if this radio had a connection that was dropped due to interference.
   *
   * @return True if this radio is interfered
   */
   public abstract boolean isInterfered();

• Looking at PowerTracker.java, you can see the following code :

[...]
public class PowerTracker extends VisPlugin {
  [...]
  public static class MoteTracker implements Observer {
    [...]
    public MoteTracker(Mote mote) {
      [...]
      } else if (radio.isInterfered()){
        lastRadioState = RadioState.INTERFERED;
      [...]
    }
    [...]
    public void update() {
      [...]
      /* Radio tx/rx */
      [...]
      } else if (lastRadioState == RadioState.INTERFERED) {
        accumulateRadioIntefered(now - lastUpdateTime);
      }

      /* Await next radio event */
      [...]
      } else if (radio.isInterfered()) {
        lastRadioState = RadioState.INTERFERED;
      [...]
      radioWasOn = radio.isRadioOn();
      lastUpdateTime = now;
    }
    [...]
    protected void accumulateRadioIntefered(long t) {
      radioInterfered += t;
    }
    [...]
  }
  [...]
}

This shows the control flow for managing the interference state of a mote ; while a mote has connections dropped due to interferences, the resulting period is added to the INT metric (radioInterfered in PowerTracker.java).

As a consequence, applied to the example of the flooding attack :

• In the situation without the malicious mote, everything works fine, that is, with a reduced interference on each mote.
• In the situation with the malicious mote, some motes are forced to more often remain ON and are thus more impacted by the interferences of their neighbors (e.g. the malicious mote 11 is impacted by motes 3, 7, 10 and has thus a non-negligible INT metric).

Answers to your questions :

1. What is INT ? This is a metric that represents the interference of neighbor motes, that is, the time that the considered mote was unable to proceed due to interferences.
2. How is it calculated ? An accumulator in the MoteTracker class instance sums all periods during which the mote remained interfered.
3. What is the percentage ? The metric is normalized regarding the ON period of the mote.

Warning : Do not be confused regarding the ON metric ; in my previous explanation, I mention the ON period which is not the same. This period is this during which the mote remains turned on while the ON metric represents the period during which the mote remains turned on AND idle. This can be seen with the IDLE radio state in PowerTracker.java.

from rpl-attacks.

Hi dhondta,

Thank you very much for your detail explanation. I requested those information since I am tiring to do this analysis in different way to interpret the same result in different way. I am going to count CPU, RX, TX separately and draw graphs manually using EXCEL. To do that I plan to use simulation generated data with different networks. That would be my 1st experiment and later I would like to do more similar experiments with some more different parameters instead of "POWER", in that case I may want to connect collect view tool with this Framework.

Thanks again
DMABM

from rpl-attacks.

Please refer to #31 .

from rpl-attacks.

hi all,
i am huma i am new user of cooja simulator em doing my thesis... dhondta abd dmabm can you both plz help me?
I want to know how plot the graph of delay, Packet Rx and Tx and energy consumtion?

from rpl-attacks.

My last question is ... how to run two different motes on different protocols separately? kindly share the link or give me the detailed answer.

from rpl-attacks.

from rpl-attacks.

from rpl-attacks.

from rpl-attacks.

from rpl-attacks.

simply set TARGET=z1 for using Z1 mote binary.

from rpl-attacks.