contiki | official git repository for Contiki , the open source OS

You should change uip6.c in the "os/net/ipv6/uip6.c" path. please see this paper :A Reference Implementation for RPL Attacks Using Contiki-NG and COOJA. This is good reference for implementing attacks in Contiki-ng.

There are at least two, potentially three buffer size bottlenecks that determine the max size of a packet that can be send and processed with Contiki-NG network stack; three

1. The size of the radio's packet buffer. This is normally determined by the hardware of the radio, and normally can be read by asking for RADIO_CONST_MAX_PAYLOAD_LEN parameter of the NETSTACK_RADIO driver.

2. The size of the packet buffer. This is by default 125 bytes - small enough to fit in the payload of a standard IEEE 802.15.4 packet (for which the max PHY layer payload is 127 bytes) when a 2 byte FCS is added. The packetbuf size can be changed by the defining a different value of PACKETBUF_CONF_SIZE.

3. If you use IPv6, then also the size of the uIP buffer. This is defined as UIP_CONF_BUFFER_SIZE and is by default quite large (1280 bytes) to be compatible with the IPv6 MTU defined by the relevant RFCs. However, some platforms set it a smaller value to save memory.

If you use simulated Cooja nodes, then the radio packet's buffer can be changed in software, by defining a different COOJA_RADIO_CONF_BUFSIZE value in the project-conf.h or in the Makefile. The default value is 125 bytes (so that when 2 byte FCS is added, the size is the max PHY layer payload of an IEEE 802.15.4 radio).

To solve your problem on Cooja you can try adding in project-conf.h:

With Contiki-NG, you have two options:

1. Use CSMA or NullMAC and turn off the radio from the application code with NETSTACK_RADIO.off().
2. Use TSCH and make sure the schedule has some idle slots. The radio is going to turn off automatically once the node has joined a TSCH network.

If you the latter, still see big consumption, and you're sure about your code, submit an issue to the Contiki-NG git - there can be an energy consumption bug in the OS specific to the CC1350 board.

I have a few suggestions:

1. Specify the literals with either a trailing 'f' or add a decimal place in

temp = rand() % 45; hum = rand() % (85-5)+5;

1. Declare temp and hum as floats and then cast the result of rand()

You can try the websense example at the folder ~/contiki/examples/ipv6/sky-websense

The example in the question you link to is written for a C implementation in which int is 32 bits. In the C implementation you are using, the int type appears to be 16 bits, and this is too short for 16-bit shifts. You will need to adjust the code to use shorter shifts or a wider integer type.

Each integer type has a width, which is the number of bits used to represent it, including a sign bit (if the type is signed) and the value bits but excluding padding bits.

The error message “left shift count >= width of type” says amount of the left shift is greater than or equal to the width of the integer type you are shifting. For example, if you shift a 16-bit number 16 bits left, you shift all bits out of the integer, and there are none left. The C standard essentially treats this as overflow: It does not define the behavior. So the compiler is warning you.

Since the code in the question does not exactly match the error messages in the question, we cannot be sure, but one possibility is you are compiling for target in which the int type is 16 bits wide, so the SHIFT_AMOUNT of 16 bits is too much. Note that shifting an int is also problematic because of the sign bit and how shifts of signed integers are defined in the C standard. It is usually preferable to use an unsigned type when shifting.

Possible remedies include:

• Check your shift amount. Using 16 for a 16-bit int results in a somewhat extreme fixed-point type. You may want a smaller shift amount.
• Use a larger integer type, perhaps long.
• Use a wider type for the shift and convert back. For example, if long is 32 bits, you could define SHIFT_MASK to be ((int) ((1l << SHIFT_AMOUNT) - 1)).
• If SHIFT_AMOUNT is known to be at least one, but not more than 16, then avoid exceeding the width of the type by using a shorter shift with a left operand already shifted a bit: ((2 << SHIFT_AMOUNT-1) - 1).
• Split the operation into two shifts: ((1 << SHIFT_AMOUNT/2 << SHIFT_AMOUNT-SHIFT_AMOUNT/2) - 1).

Note the above options do not deal with the signedness issue. You would need to clarify the context for further advice on that.

Because 5/2 is a form of integer division, what you put in you get out, meaning that if you put in 5/2 you will only get an integer back, in the form of 2.

To fix this, make your 5/2 is 5/2.0 so that it is read in as a float, and that will make sure that you will get an answer that is a floating-point decimal.

There is a uIP neighbor data structure called uip_ds6_nbr_t. These structures are kept in Contiki neighbor tables. When the mapping from an IPv6 address to a MAC address is needed, the code first calls uip_ds6_nbr_lookup(ipv6_address) to find the neighbor, then uses the neighbor to find the link-layer address, by calling the function uip_ds6_nbr_get_ll(nbr).

By default Contiki-NG has RPL-lite enabled, which does not have this function.

To switch to RPL classic, add this line to application's Makefile: