Hello all,

This question came out a discussion with Mar about the architectural correct place for implementing the ubiquitous button_sensor on the contiki platform. The correct/intended way to implement extra sensors is not clear. Maybe I have missed some documentation somewhere!

So as a general statement in the contiki/platform/sensor scheme of things, say if you were creating additional sensors, you really would want to make them autonomous and independent of any platform, placing them under (/core/dev/button-sensor) and then using architectural specific code (/platform/redbee-econotag/dev/button-arch) to configure them and allow them run on any platform?

Would it be correct to say that this is the intended 'contiki way/pattern' ?

Further, in the absence of clear documentation, on most platforms the button_sensor code and other 'generic' sensors have not been implement that way, instead hard coding sensors to platforms.

An example of 'intended' way would be /code/dev/sht11, an example of the other way its /platform/wismote/dev/sht15 and /platform/iris/dev/ds2401 among others.

Is this a correct view of the situation?

I would appreciate any guidance on the intended best practice from the core devs.
Sorry for the double post. I posted this question on the mailing list before I realised that Mar met put it up on the github issue tracker.
Regards
Robert

What little documentation there is:
http://contiki.sourceforge.net/docs/2.6/a01671.html
and
https://github.com/contiki-os/contiki/wiki/Timers#wiki-The_Rtimer_Library
and the sys/rtimer.h file all imply that rtimer_set can actually return some sort of status.

however, in the source, the only possible return code is RTIMER_OK.

Is this a) a bug, or b) by design?

contikimac.c uses the function rtimer_arch_sleep(), but that's not listed in any documentaiton, and only defined for AVR and mc1322x. Bug or design?

Is the rtimer code actually meant to be used by any user processes, or is it purely designed for use by the MAC driver code?

I think it would be interesting to use Github pages (http://pages.github.com/) in order to host the Doxygen HTML documentation of Contiki online. Maybe having a git post-commit script that will build the html version of the documentation and push it to the gh-pages branch in the right folder.

I can work on this if people think it's a good idea ;-)

As mentioned in #244 the ipv6 web server still doesn't build for ipv6 out of the box.

the following diff makes it build an ipv6 image properly at least, but it's clearly not the right way of fixing it.

$ git diff
diff --git a/examples/webserver-ipv6/Makefile b/examples/webserver-ipv6/Makefile
index 25a545c..d3c807e 100644
--- a/examples/webserver-ipv6/Makefile
+++ b/examples/webserver-ipv6/Makefile
@@ -36,6 +36,7 @@ endif

 UIP_CONF_IPV6=1
 DEFINES=WITH_UIP6
+CFLAGS+=-DUIP_CONF_IPV6=1

 # Make no RPL the default for minimal-net builds
 ifeq ($(TARGET),minimal-net)

Should the WITH_UIP6 define do this automatically? Should the UIP_CONF_IPV6 make variable do anything?

$ sudo ./webserver6.minimal-net 
RPL enabled
ifconfig tap0 up

*******Contiki-2.6-566-g0f135af online*******
IPV6 Addresss: [fe80::206:98ff:fe00:232]
.....
$ ping6 -I tap0 fe80::206:98ff:fe00:0232
PING fe80::206:98ff:fe00:0232(fe80::206:98ff:fe00:232) from fe80::9cbe:7cff:fea8:6bb1 tap0: 56 data bytes
64 bytes from fe80::206:98ff:fe00:232: icmp_seq=1 ttl=64 time=0.154 ms
64 bytes from fe80::206:98ff:fe00:232: icmp_seq=6 ttl=64 time=0.120 ms
^C

I'm using a cc2530 zigbee module with a button in port 0 and pin 1. I'm using this code of example button-test.c:
PROCESS_THREAD(buttons_test_process, ev, data)
{
struct sensors_sensor *sensor;

PROCESS_BEGIN();
SENSORS_ACTIVATE(button_1_sensor);
while (1) {
leds_on(LEDS_GREEN);
PROCESS_WAIT_EVENT();
leds_off(LEDS_GREEN);
/* If we woke up after a sensor event, inform what happened */
sensor = (struct sensors_sensor *)data;
if(sensor == &button_sensor) {
PRINTF("Button Press\n");

}

}

PROCESS_END();
}

When I push button it does not generate any event and the green led does not toggles. I have reviewed the ports and the pins and are correct. Could you help me with any suggestions??

If we call LPP's off() and pass 1 as its argument, the radio will be kept on as intended:

static int
off(int keep_radio_on)
{
  lpp_is_on = 0;
  if(keep_radio_on) {
    turn_radio_on();
  } else {
    turn_radio_off();
  }
  return 1;
}

However, after we return from off(), the value of keep_radio_on is forgotten. Later on, in various locations, the driver calls turn_radio_off();, which has no way of checking for the value of keep_radio_on.

static void
turn_radio_off(void)
{
  if(lpp_is_on && is_streaming == 0) {
    NETSTACK_RADIO.off();
  }
  /*  leds_off(LEDS_YELLOW);*/
}

As a result, turn_radio_off(); will disable the RF regardless. To my understanding this is incorrect behaviour, it is certainly different to what ContikiMAC does.

The twitter app is totally incapable of tweeting, as basic auth was switched off in august 2010.

However, the app does provide a useful example of doing http post with basic auth, so perhaps there's no need to completely remove it. Perhaps a rename would be in order? It would be less misleading, and avoid mail threads like this: http://article.gmane.org/gmane.os.contiki.devel/18315

I think it would be a nice feature to have an option in the command line of Cooja that locate the output of the pcap file instead of having it in the build folder.

I'm working on adressing this issue but the COOJA code base is quite large and I don't know how to do it in a clean way.

Documentation states: "When the event timer expires, the event PROCESS_EVENT_TIMER will be posted to the process that called the etimer_set() function." (from doc of etimer_set()).

This is not true, if an unexpired etimer is being etimer_set by another process than the current owning process.

Fix is simple: in add_timer() directly after the comment "/* Timer already on list, bail out. */" the line

timer->p = PROCESS_CURRENT();

has to be added.

I hope this fix will not break anything existing.

Background: in our application there is a protothread which does some action (of course). In the end the protothread is waiting either for an event or a timeout, implemented by an etimer. The etimer is a static variable of the protothread, the internals of the protothread are protected by a semaphore.

The protothread itself is called by several processes via PROCESS_PT_SPAWN().

If the protothread exits via its usual path (without timeout), the etimer still belongs (until expiration) to the calling first process.

Then the second process is calling the protothread and sets the etimer - unfortunately for the first process. If the actual completion event is not sent (due to some failure), the etimer timeout is sent to the wrong process and the protothread is stuck - and the calling second process.

Other case: the first process is exiting after returning from the protothread (unexpired etimer). Then the etimer (still owned by the first process) is removed from the etimer list. Again no event to the second process.

In commit 03ce7c6, the documentation at https://github.com/contiki-os/contiki/wiki/Out-of-Tree-Development on how to specify out of tree applications was broken, and consequently, anyone who was using out of tree apps.

platform apps explicitly look for apps in an apps subdirectory of the platform, which must be underneath $(CONTIKI) which seems to preclude out of tree platforms too.

Changing line 92 to APPDS += instead of APPDS =, and then changing my out of tree makefile to use APPDS instead of APPDIRS like in the existing documentation works, but It would be nicer if this had maintained compatibility with the existing code. Or, updated the documentation to match reality

I have noticed that commit b43dad0 ("Cleaned up RF230BB, and refactored FRAME_RETRIES and CSMA_RETRIES") has broken reception of packets for the avr-raven and avr-ravenusb platforms. Sending packets is unaffected. I'm not able to test the effect of this commit on other platforms which use RF230BB.

Reverting the change once again allows these platforms to work properly.

Investigation seems to indicate that the radio interrupt is no longer firing. Before b43dad0, TIMER1 was being used to generate interrupts because both the avr-raven and avr-ravenusb boards do not connect the IRQ pin on the RF230 to a pin on the µC which can directly generate an interrupt. I'm guessing that this has been disrupted and the timer is no longer generating the interrupts that RF230BB needs.

Tagging @dak664 because he is relatively familiar with this code.

b43dad0 was contributed by @idelamer.

This doesn't currently compile for it's default configured target, minimal-net. It almost compiles if you remove the local copy of tapdev6.c that is already in the minimal net platform code, but it then has another compile problem with initializing the uip_addres

testv6.co: In function `process_thread_test_process':
/home/karlp/src/contiki-locm3/examples/test-ipv6/testv6.c:51: undefined reference to `uip_hostaddr'

Further, there's no readme, or any useful commentary in the code about what this even meant to do. I suggest the entire directory simply be removed. less to maintain, less noise and clutter in the tree.

(Let's not even get into a discussion about that line not having a uip_hostaddr() call, it's hidden behind some crazy macro expansion of function names!)

see http://sourceforge.net/mailarchive/message.php?msg_id=30373561

the following is broken:

ifneq ($(TARGET), minimal-net)
ifneq ($(TARGET), native)
ifneq ($(TARGET), econotag)
ifneq ($(findstring avr,$(TARGET)), avr)
PROJECT_SOURCEFILES += static-routing.c
endif
endif
endif
endif

suggested fix:

ifeq ($(STATIC_ROUTING), 1)
PROJECT_SOURCEFILES += static-routing.c
DEFINES+=ER_REST_CONF_STATIC_ROUTING=1
endif

After 843d236, anything that tries to read rimestats.foo will fail to compile unless RIMESTATS_CONF_ENABLED is 1. The items below are definitely broken, perhaps there's more:

• apps/webserver-nano
• examples/sky/sky-collect.c
• Various things under examples/sensinode and examples/cc2530dk

Additionally, the commit introduced RIMESTATS_CONF_ENABLED, webserver-nano uses RIMESTATS_CONF_ON which, as far as I can understand, is meant to achieve the same thing... (or is it?)

Possible fixes

• Introduce a project-conf.h and enable rimestats for the examples in question
• Introduce RIMESTATS_GET(foo) and then replace all direct references to rimestats.foo.
• The quick and dirty fix: Move the declaration of struct rimestats outside the #if block. This will make sure things compile but will lead to confusing behaviour: If RIMESTATS_CONF_ENABLED is 0, RIMESTATS_ADD(foo) will do nothing but if the code references rimestats directly, the module will get linked in anyway.

I'm working on various pulls so I'll knock something together for this one too. Any preference in terms of how to fix?

Dear all

I am a new contiki developing

I am trying to make that example Web-server nano Ajax streaming example

but I have a problem that how to edit the .js file to to force a new httpd-fs.c build

that is the link of example

https://github.com/contiki-os/contiki/wiki/Webserver-nano_AJAX_streaming_Example_Guide

thanks in advance

Hi there,

whenever I take the plain Contiki examples (like "hello-world") and build them for the Zolertia Z1, I can't use the terminal console afterwards, since it just returns the same bytes that are incorrectly interpreted (i.e. something is wrong with the serial settings).

I tried calling serialdump-linux manually with different baud rates, and I also tried GNU screen with different baud rates and settings for parity bits, stop bits, etc. Example: screen /dev/ttyUSB0 115200,cs8,-parenb,-cstopb

What am I doing wrong? The examples worked fine on my TelosB Motes. One major difference is that the Z1 uses uart0.h etc while the Sky uses the uart1. files.

FYI, here is the output of ../../tools/sky/serialdump-linux -x -b115200 /dev/ttyUSB0
AAAA5B41 BB2FE9BC 290EDAD5 BC0B8AC1 B4566EED ..[A./..)........Vn. 90983922 A5A8100E C29A98E2 98E298E2 98E298E2 ..9"................ 98E29882 A3EBE1B1 55DBC296 AB29DA99 A30E8A71 ........U....).....q 98D66B82 BB2FE9BC 29CE0932 DDB429AA D190AA16 ..k../..)..2..)..... B2DDBCCA D5BCA9A3 521A41A3 EBE1B155 DB85A309 ........R.A....U.... 8AD1B1EB C5B48AD1 B5D40BC2 C5BC29FE 9822F994 ..............)..".. C2C5B4AA 0B8AD1B1 EBC5B43E 964BD8A5 C5BA2FEB ...........>.K..../. CD901A5A D1B40BDA DDBA4B41 B8D63BC5 BBD64A88 ...Z......KA..;...J. D5B4EB51 90FF2BD1 B4F1 ...Q..+...^C

My system is Ubuntu 12.10. with Contiki from GitHub. The Zolertia Z1 are brand-new, just arrived via mail.

In afe13b2 the uIP IPv6 route handling code was replaced. As a side effect, the isused field was removed from uip_ds6_route_t and uip_ds6_defrt_t. Some cleanup was done in 99f541e but references to these fields remain in conditionally-compiled code in apps/webserver-nano/httpd-cgi.c (encountered reproducing #249) and per "git grep" avr-ravenusb. There's also commented-out code that still uses it.

I get the following error in a numerous amount of examples with a simple make :

cc -DPROJECT_CONF_H="project-conf.h" -DCONTIKI=1 -DCONTIKI_TARGET_NATIVE=1 -Wall -g -I/usr/local/include -O -I. -I../../..//platform/native/. -I../../..//platform/native/dev -I../../..//platform/native/ctk -I../../..//cpu/native/. -I../../..//cpu/native/net -I../../..//core/dev -I../../..//core/lib -I../../..//core/net -I../../..//core/net/mac -I../../..//core/net/rime -I../../..//core/net/rpl -I../../..//core/sys -I../../..//core/cfs -I../../..//core/ctk -I../../..//core/lib/ctk -I../../..//core/loader -I../../..//core/. -I../../..//apps/antelope -I../../..//platform/native/ -DCONTIKI_VERSION_STRING="Contiki-2.6-487-g96e85cc" -MMD -c ../../..//platform/native/ctk/ctk-curses.c -o obj_native/ctk-curses.o
../../..//platform/native/ctk/ctk-curses.c:34:20: erreur fatale: curses.h : Aucun fichier ou dossier de ce type
compilation terminée.
make: *** [obj_native/ctk-curses.o] Erreur 1

define DMA_PRIO_HIGHEST 0x03

define DMA_PRIO_HIGH 0x02

define DMA_PRIO_GUARANTEED 0x01

define DMA_PRIO_LOW 0x00

but

PRIORITY[1:0] The DMA channel priority:
00: Low, CPU has priority.
01: Assured, DMA at least every second try
10: High, DMA has priority
11: Reserved

Hi all,

im new there, but I study contiki o lot of time. Now Im looking to MAC, NULLRDC and FRAMER-802154

I have one simple question, if I need autoack feature enabled I only saw in transmitting that nullrdc add this

packetbuf_set_attr(PACKETBUF_ATTR_MAC_ACK, 1);

and if receive packet there is

if(packetbuf_datalen() == ACK_LEN)
{
/* Ignore ack packets /
/ PRINTF("nullrdc: ignored ack\n"); */
}

PLEASE CAN ME ANYONE EXPLAYN WHERE IS SENDING ACK RESPONSE TO SUCCESFULLY RECEIVED FRAME?

Thanks so much.

TARGET=iris can't build. It's caused by

• node-id isn't fix yet (#39)
• legacy clock(clock_delay) is undefined

The latter is discussed, but seems unsolved. ( in http://sourceforge.net/mailarchive/forum.php?thread_name=C89C454FFAAD4FBBACF3B89CE7840D35%40Ginger&forum_name=contiki-developers )

Dear all
I am asking about how to edit the web contents of any example of webserver .
I would like to ask which html files I should change & if there is another files I should change to edit web contents
thanks in advance

Seeing that simple changes in "top-level" applications like #346 have an effect on various targets I wonder if the targets are to fat in terms of the bootstrapping they do?

For a long time I have the feeling that targets should just initialize

• clocks
• timers
  (- UART or other debugging hardware)
• contiki process scheduler

and then launch into the main project process. Then inside the main project process a device can decide which other processes (e.g. resolv, tcpip or netstack) are required and start them.

This separation would also give the targets more flexibility in the configurations they run as the target would merely be a "board support code" so that any contiki code can be run on it.

Or is there any reason why these targets have become so fat other than not taking care of proper abstraction and refactoring?

In route-discovery is the hddr->rreq_id an 8 bit integer. When continuously sending route-discovery requests, at some point this integer gets to 255 and wraps after that to 0, but the c->last_originator_seqno in netflood, which is a 16 bit integer, continues to increase after 255, which will cause the check if(!(rimeaddr_cmp(&hdr.originator, &c->last_originator) &&hdr.originator_seqno <= c->last_originator_seqno))
in netflood.c in function recv_from_polite to be always 0 after this point. In order to fix this, I had to explicitly wrap c->last_originator_seqno to 0 when it reaches 255.

Hi,

Problem:
Uart1 is not working properly in CC2530 contiki port.
It transmits 0xff after every byte sent. This is because,
'U1UCR = 0x80' line in function uart1_init(uart1.c file) overwrites 'U1UCR = 0x02' configuration.

Solution:
Replace 'U1UCR = 0x80' with 'U1UCR |= 0x80'.

Regards,
Mahesh Sutariya
www.energycloud.co.in

This test should probably be disabled until it can be fixed so that this issue doesn't continue to affect everyone else.

In my code some data is sent via USB to host periodically. If I plug the CC2531 device without running Putty to receive data, then after a while, open Putty, no data can be received. I guess some buffer overflows, and there are no proper code to recover from it. I made a simple patch but if someone have a way to make the device be able to recover from the overflow that will be better.

My solution now is to add these code:

if(!(usb_cdc_acm_get_line_state() & 0x01)){
    leds_toggle(LEDS_RED);
    return;
 }

to function usb_serial_writeb function in usb-serial.c .

So no single byte can be written to usb_tx_data[] buffer if DTR in line state word is not set.

I think this can possibly prevent some buffer from overflow if no application is reading from the USB. This patch is tested and it works, and host computer is using Putty or cat on Ubuntu 12.04.

But if someone have a way to make the device be able to recover from the overflow that will be better.

#328 added a set of CC2538 UART configuration options. However, the implementation is not 100% correct (OK, it's broken). Specifically, cpu/cc2538/dev/uart.c does this:

  /* Set PA[1:0] to peripheral mode */
  REG(GPIO_A_BASE | GPIO_AFSEL) |= (0x00000002 | 0x00000001);

Ergo, we are setting peripheral mode of PA[1:0], ignoring configuration altogether.

This works for the CC2538DK platform, because in this instance the port/pin combination is correct. However, for hardware with different pin assignments this will break.

OK, so I'm confused enough to make this a separate issue from the pull I wanted to submit where I tried to work around it. The basic question: what header file(s) should be included to ensure all application and platform options are applied consistently across all modules, and where in the sequence of include files should it appear? (I do see the discussion around #178 but I didn't get a clear sense of direction from it.)

There's contiki.h and contiki-conf.h and (now) contiki-default-conf.h.

contiki.h seems to be for applications as it includes a bunch of useful sys headers, so I can see that just including "contiki.h" everywhere is probably not what should normally be used in core/* or platform files. It does make sure that contiki-conf.h and contiki-default-conf.h both get included right away, though, so including it first should produce a well-defined configuration.

In other source and header files in core I see some include contiki.h and some just include contiki-conf.h. One includes both directly; others probably do indirectly. Sometimes these files are the first ones included, but some times other core headers are included first, making it possible that they act on the visible defaults before all defaults have been read.

core/net/uip-icmp6.c is the only file other than contiki.h that explicitly includes contiki-default-conf.h, which it maybe doesn't have to because it first includes net/uip-ds6.h which includes net/uip.h which includes net/tcpip.h which includes contiki.h.

There are conditionals based on potentially default values for the same macro in multiple places: contiki-default-conf.h, other headers, and source files. At this time the defaults appear to be consistent, but I'd worry about that remaining true in the future. If contiki-default-conf.h ever does something more than/different from what's done by the individual headers that also assume defaults, source files that include only contiki-conf.h have the potential to have different defaults than ones that also include contiki.h.

I haven't found a clear case where something goes wrong, but it does seem fragile with a risk that different files will get built with different defaults. I guess I just want to raise the issue to see if anybody shares my concern, and more importantly to get advice on what I should do to reduce risk in my own code.

I observed that DIOs are now being sent fragmented without having grown in size!

The problem is in L1463 in core/net/sicslowpan.c:

if((int)uip_len - (int)uncomp_hdr_len > (int)MAC_MAX_PAYLOAD - framer_hdrlen - (int)rime_hdr_len) {

We are leaving too little space for the L2 payload. We reduce it by 25 first inside MAC_MAX_PAYLOAD (which defaults to 127 - 25) and then we further subtract framer_hdrlen.

There was nothing wrong with the old condition, so am I right to suspect it may be related with crypto at L2?

What we should be doing is subtract the highest of 25 or framer_hdrlen, like so (obviously formatted correctly etc):

(int)127 - (framer_hdrlen > 25 ? framer_hdrlen : 25) - (int)rime_hdr_len)

There are two more instances of MAC_MAX_PAYLOAD - framer_hdrlen which would need adjustments as well.

One could argue that this is not a bug however it needs changed, since at the moment we don't have RPL in platforms which don't support 6lowpan fragmentation.

Contiki's build environment nominally supports using WERROR=1 to turn on gcc -Werror checking. I find this feature helps reduce the number of bugs I introduce, but Contiki's source has several "errors" in core files that prevent its use.

Most of these are variables that are declared and either unused or set but never referenced. Often the reference is in code that is present but normally excluded from compilation (e.g., debug blocks).

Some are uses of functions without a prototype in scope. Others are violations of the edges of the C standard. A few appear to be wrong code that happens to work in most cases.

Is there support for patches to fix these issues? A current set of such changes can be viewed at https://github.com/pabigot/contikix/tree/features/werror. I don't want to spend the time refactoring and submitting a pull request if it's clear the approach would be rejected.

BTW: I am aware that -Wno-error=unused-variable could be used to reduce the number of changes. I don't support that approach, so if review prefers it somebody else can take over from here by cherry-picking any other changes that are judged worthwhile.

Hi
I downloaded source and tried to compile and upload hello-world example to Iris. Compilation was successful but when I try to upload, I got this error:

$ make TARGET="iris" hello-world.u
cp hello-world hello-world.out
cp: cannot stat ‘hello-world’: No such file or directory
make: *** [hello-world.out] Error 1

If I remove - so filename is helloworld.c, upload works.

All this happens on Arch linux, if I try to do it from Instant-Contiki vm, upload works fine.

I am not sure what is cause for this strange error.

Also, is there some reason for %.u instead %.upload in AVR makefile?

What is the function of *ptr in Contiki RPL?

Using contiki from git at current master (807293a), I'm trying to verify a working IPv6 webserver configuration.

As documented in #249 examples/webserver-ipv6 doesn't build an IPv6-capable webserver. Following the hints in that thread, I add these lines:

 DEFINES=WITH_UIP6
+CFLAGS += -DUIP_CONF_IPV6=1
+CFLAGS += -DUIP_CONF_IPV6_RPL=0

Then "make TARGET=minimal-net WITH_WEBSERVER=webserver" and I get an executable. Running this under sudo, ping works:

llc[429]$ ping6 aaaa::206:98ff:fe00:232
PING aaaa::206:98ff:fe00:232(aaaa::206:98ff:fe00:232) 56 data bytes
64 bytes from aaaa::206:98ff:fe00:232: icmp_seq=1 ttl=64 time=0.139 ms

However this does not:

llc[517]$ wget -O - 'http://[aaaa::206:98ff:fe00:232]/'
--2013-06-16 11:22:47--  http://[aaaa::206:98ff:fe00:232]/
Connecting to aaaa::206:98ff:fe00:232:80... ^C
llc[518]$ 

Wireshark shows a TCP SYN request from the browser getting SYN,ACK response, but there must be something in it the source doesn't like because the browser's IP stack immediately replies with RST. This repeats until timeout.

The same behavior is observed with webserver-nano.

Am I doing something wrong here, or is there a bug? FWIW, this is reproducible on both Ubuntu 12.04 and Fedora 16 all the way back to f8edbbb. The predecessor commit 6ba28bf produces a program that aborts with a different error ("uip_ds6_prefix_add() failed") so if this is a Contiki problem the underlying cause may pre-date this.

Compiling powertrace for my platform (arm cortex m3) results in the following warnings.

contiki/apps/powertrace/powertrace.c:134:10: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'clock_time_t' [-Wformat]
contiki/apps/powertrace/powertrace.c:134:10: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'clock_time_t' [-Wformat]
contiki/apps/powertrace/powertrace.c:183:18: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'clock_time_t' [-Wformat]
contiki/apps/powertrace/powertrace.c:183:18: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'clock_time_t' [-Wformat]

I thought this would be easy to fix with inttypes.h and the PRIu32 printf format string helpers. however, clock_time_t is not a fixed size. I had expected it to always be 32bit, or always 16bit, and the "long unsigned int" problems were coming from 8/16 bit micros. But, it's really quite a diverse implementation, so I'm not sure the right way forwards.

 ~/contiki $ ack clock_time_t | grep typedef | cut -d':' -f3 | sort | uniq -c
      3 typedef uint32_t clock_time_t;
      1 typedef unsigned clock_time_t;
      3 typedef unsigned int clock_time_t;
     26 typedef unsigned long clock_time_t;
     12 typedef unsigned short clock_time_t;

Some of these defintions are in dead/not actively maintained platforms, and some are behind "#if 0" type constructs. The docs at https://github.com/contiki-os/contiki/wiki/Timers#wiki-The_Clock_Module say that clock_time_t is platform dependent, but is there any solution for the powertrace app then? Would printing it as 32bit always be suitable?

Dear Contiki developers,

I am trying to use etimer's function timer_reset() which should reset an etimer without loosing precision:

When my etimer is reset with timer_reset() it expires immediately which is wrong and breaks my system!

timer_reset() is implemented as:

As you can see timer_reset() actually postpones the t->start into a future's value compared to current time returned by clock_time().
The etimer_process checks timer_expired() which immediately returns true (which is wrong).

typedef unsigned int clock_time_t;


Variable "diff = clock_time() - t->start" cannot result in a negative value instead it is treated as a high positive value which then compared with t->interval is always true.

What is wrong? Is probably an implementation of these functions buggy?

Thanks for any advice.

spachner

Changing the MCU main frequency in platform-conf.h misconfigures the uart0's baudrate, as the ubr is fixed. Using the value passed by the BAUD2UBR macro at uart0_init works (tested with 8/16MHz with serialdump script).

Travis test 1 outputs this:

$ tail regression-tests/??-$BUILD_TYPE/*.testlog
tail: cannot open `regression-tests/??-compile/*.testlog' for reading: No such file or directory

Not sure whether that's a problem with travis or with the test itself

As best I can tell, this example code is completely out of date. Better examples are platform/seedeye/dev/mrf24j40/mrf24j40.c and cpu/cc2538/dev/cc2538-rf.c are probably better. Even core/dev/cc2420.c is a better example I believe, though it's a lot harder to see through the noise.

I'm really looking for better guidance for porting the radio layers, and neither /doc nor the wiki have any current info on porting the networking layers.

Travis has multiple failures.

• AVR compiles failing
• econotag compiles failing
• all cooja simulations failing (only on that passes does so b/c it doesn't contain any tests)
• native compiles failing
• 8051 failing

The Z1's node_id_burn has an extra line compared to the sky's which copies the old node_mac in the remaining 12-byte buffer after setting the magic number and the 16-bit node-id.

void
node_id_burn(unsigned short id)
{
  unsigned char buf[12];
  buf[0] = 0xad;
  buf[1] = 0xde;
  buf[2] = id >> 8;
  buf[3] = id & 0xff;
  memcpy(&buf[4], node_mac, 8);
  xmem_erase(XMEM_ERASE_UNIT_SIZE, NODE_ID_XMEM_OFFSET);
  xmem_pwrite(buf, 12, NODE_ID_XMEM_OFFSET);
}

This doesn't play nicely with contiki-z1-main.c, which ignores the nodeid if the mac is set after executing node_id_restore:

/* Restore node id if such has been stored in external mem */
node_id_restore();

/* If no MAC address was burned, we use the node ID. */
if(!(node_mac[0] | node_mac[1] | node_mac[2] | node_mac[3] |
     node_mac[4] | node_mac[5] | node_mac[6] | node_mac[7])) {
  node_mac[0] = 0xc1;  /* Hardcoded for Z1 */
  node_mac[1] = 0x0c;  /* Hardcoded for Revision C */
  node_mac[2] = 0x00;  /* Hardcoded to arbitrary even number so that
                        the 802.15.4 MAC address is compatible with
                        an Ethernet MAC address - byte 0 (byte 2 in
                        the DS ID) */
  node_mac[3] = 0x00;  /* Hardcoded */
  node_mac[4] = 0x00;  /* Hardcoded */
  node_mac[5] = 0x00;  /* Hardcoded */
  node_mac[6] = node_id >> 8;
  node_mac[7] = node_id & 0xff;
}

What is the point of retrieving a leftover MAC inside node_id_burn if, as the function implies, the point is to set a nodeid? Maybe there is a good reason which I'm missing?

I would prefer to see a memset(buf,0,sizeof(buf)) there and only assign the first 4 bytes of buf: magic number + 16-bit node id.

It would then generate MAC and link-local IPv6 addresses of the form:

c1:0c:00:00:00:00:12:34
fe80::c30c:0000:0000:1234

If this is desirable a PR will follow.

Currently indent (tools/indent.pro) is used to format and check formating the code. Unfortunately indent is unable to non-basic type pointers coerrectly:

 Indent:  sometype * foo, int *bar
 Correct: sometype *foo, int *bar

Although I haven't tried it http://uncrustify.sourceforge.net/ might be an option.

Issue

A No-Path DAO is a DAO with the Transit Information Option "lifetime" field set to 0, to signal to a node that the prefix(es) given in the Target Option are no longer reachable. This triggers route suppression in dao_input (rpl-icmp6.c), by setting an expiration timeout for a particular route, which is later suppressed in rpl_purge_routes (rpl.c).

Currently, No-Path DAOs are sent in two circumstances:

• To the previous preferred parent when the preferred parent is changed.
• To the previous preferred parent in case it becomes NULL due to unacceptable rank.

I did some tests with the current implementation and this works quite well. However, No-Path DAOs are not propagated upwards towards the sink. When a router deletes route which is its last known route towards a particular prefix, it should schedule a No-Path DAO with that prefix set in the Target Option. It's mentionned as a valid event to generate a new DAO message in Section 9.2.2 of RFC6550

In Storing mode, a DAO message is "new" if
it satisfies any of these criteria for a contained Target:

1. it has a newer Path Sequence number,
2. it has additional Path Control bits, or
3. it is a No-Path DAO message that removes the last Downward route
   to a prefix.

When No-Path DAOs are not generated in the way I just described, traffic routed from the sink or outside the RPL network will not be affected, because normal DAOs sent after the parent switch occurs will successfully update the routes along the new path, including the sink. However, this affects p2p traffic originating in the sub-dodag in which the target was previously present.

Example

To illustrate, consider the scenario below where 1 is the sink:

• node 6 selects node 2 as preferred parent in the DAG formation
• after a while, node 7 appears as a potential parent for 6, and becomes the preferred parent (for whatever reason).
• 6 switches to 7, and sends a No-Path DAO to 2

• 2 suppresses its route to 6
• 6 sends a DAO to 7
• 7 adds a route for 6, and announces that prefix to its parent in a DAO

If 2 does not propagate the fact that it cannot reach 6 anymore, 5 will have an inconsistent routing table. This doesn't affect traffic coming from the sink, or from anywhere outside node 5's sub-dodag. However, if node 4 tries to reach 6, node 5 will forward traffic along 2 and a loop will appear.

Partial Solution

A partial solution in the above scenario is to generate a No-Path DAO from 2 to 5, containing node 6's prefix, and to propagate it towards the sink.

In this branch, I added dao_output_target for DAO generation to an arbitrary target and I call this to generate no-path DAOs when rpl_purge_routes detects that a deleted route entry is the last one for a given target. This is enough to delete the routes up until we reach a common ancestor. I'm not doing a pull request because it will probably evolve some more and it needs merging with dao_output. It also needs to be generalized for multi-instances/dags.

Note that this doesn't avoid the problem completely, it only lowers the chances of it occurring. If the No-Path DAO of the leaving node is not heard by the previous parent, or if it's lost somewhere along the path, there will still be an inconsistency. Making the DAOs Ackable might be an improvement, yet still limited.

I have brought this issue in the mailing list but it was posed as question more than a report.

I believe there is an issue with the function lollipop_greater_than in rpl-dag.c

the following code, I believe, fails to fully implement the spec rfc1982 sec 3.1

static int
lollipop_greater_than(int a, int b)
{
  /* Check if we are comparing an initial value with an old value */
  if(a > RPL_LOLLIPOP_CIRCULAR_REGION && b <= RPL_LOLLIPOP_CIRCULAR_REGION) {
    return (RPL_LOLLIPOP_MAX_VALUE + 1 + b - a) > RPL_LOLLIPOP_SEQUENCE_WINDOWS;
  }
  /* Otherwise check if a > b and comparable => ok, or
     if they have wrapped and are still comparable */
  return (a > b && (a - b) < RPL_LOLLIPOP_SEQUENCE_WINDOWS) ||
    (a < b && (b - a) > (RPL_LOLLIPOP_CIRCULAR_REGION + 1-
             RPL_LOLLIPOP_SEQUENCE_WINDOWS));
}

it appears the code implements the check specified in 7.2.2.1 of rfc6550

2. In the case where both sequence counters to be compared are less than 
or equal to 127, and in the case where both sequence counters to be compared 
are greater than or equal to 128:

             1.  If the absolute magnitude of difference between the two
             sequence counters is less than or equal to
             SEQUENCE_WINDOW, then a comparison as described in
             [RFC1982] is used to determine the relationships greater
             than, less than, and equal.

             2.  If the absolute magnitude of difference of the two
             sequence counters is greater than SEQUENCE_WINDOW, then a
             desynchronization has occurred and the two sequence
             numbers are not comparable.

Assuming that 2^(SERIAL_BITS - 1) == 127 I don't think the code implements the following specified in rfc1982 sec 3.1

(i1 < i2 and i2 - i1 > 2^(SERIAL_BITS - 1)) or
(i1 > i2 and i1 - i2 < 2^(SERIAL_BITS - 1))

Am I completely wrong here and missing something basic?

I'm trying out IPv6/6LoWPAN with nodes that are true leaf nodes and are definitely not routers. When I set UIP_CONF_ROUTER to 0, uip-nd6.c no longer compiles:

CC        ../../../../contiki/core/net/uip-nd6.c
../../../../contiki/core/net/uip-nd6.c: In function 'uip_nd6_ra_input':
../../../../contiki/core/net/uip-nd6.c:823:9: error: 'uip_ds6_nbr_t' has no member named 'lladdr'
../../../../contiki/core/net/uip-nd6.c:824:22: error: 'uip_ds6_nbr_t' has no member named 'lladdr'

It seems that the uip_ds6_nbr_t struct in uip-ds6-nbr.h changed without all of the code being updated. I think I tracked it down to this commit: ec609b4.

Also, the top of uip-ds6-nbr.h: #ifndef __UIP_DS6_NEIGHBOR_H__ didn't get updated.

Dear all,
It's not a bug , I just wonder why the RTIMER_ARCH_SECOND in the cpu/cc253x/rtimer-arch.h is (15625U)
Isn't it be 65536/4=16384?
because the timer1 is 16bit and cc2530 is 32MHz clock

yours Daniel-D Dax,

Tags need to be pushed to this repo, the old repo had these tags:

• 2.0
• 2.1
• 2.2
• 2.2.1
• 2.2.2
• 2.2.3
• 2.3
• 2.4
• 2.5
• 2.5-release
• 2.6
• 2.6-rc0
• 2.x

I'm not too sure whether all of the above are needed, but at least a subset is certainly important to keep.

The original problem reported isn't a bug any where but is still a problem. If two border-routers are within range, the can add each other as the default route which causes the fallback interface to fail.

border-router_econotag.bin is not functional somewhere after pull #45. Bisecting the issue has not been useful as it seems the intermediate commits might be flaky (perhaps the problem depends on how things start up?). The current master, #69 fails all the time.

To reproduce: run a border-router and try to ping it. It will fail.

Debug output from bad 56ce924:

'''
IPv6 packet received from aaaa::1 to aaaa::205:c2a:8c9e:4f20
icmp6_input: length 104 type: 128
Upper layer checksum len: 64 from: 40
Received Echo Request from aaaa:0000:0000:0000:0000:0000:0000:0001 to
aaaa:0000:0000:0000:0205:0c2a:8c9e:4f20
Upper layer checksum len: 64 from: 40
Sending Echo Reply to aaaa:0000:0000:0000:0000:0000:0000:0001 from
aaaa:0000:0000:0000:0205:0c2a:8c9e:4f20
Sending packet with length 104 (64)
sicslowpan output: sending packet len 104
before compression (64):
6000000000403a40aaaa00000000000002050c2a8c9e4f20aaaa00000000000000000000000000018100be303f4e01d5c8b9e95000000000c80f070000000000101112131415161718191a1b1c1d1
e1f202122232425262728292a2b2c2d2e2f3031323334353637
IPHC: compressing dest or src ipaddr - setting CID
IPHC: compressing src with context - setting CID & SAC ctx: 0
'''

Debug output from good 0cb4bf4:

'''
IPv6 packet received from aaaa::1 to aaaa::205:c2a:8c9e:4f20
icmp6_input: length 104 type: 128
Upper layer checksum len: 64 from: 40
Received Echo Request from aaaa:0000:0000:0000:0000:0000:0000:0001 to aaaa:0000:0000:0000:0205:0c2a:8c9e:4f20
Upper layer checksum len: 64 from: 40
Sending Echo Reply to aaaa:0000:0000:0000:0000:0000:0000:0001 from aaaa:0000:0000:0000:0205:0c2a:8c9e:4f20
Sending packet with length 104 (64)
Packet from SLIP of length 104 - write TUN
'''

To me, this looks like for some reason the bad code send the ping reply out sicslowpan instead of using the fallback interface which will send the ping out SLIP.

Ping isn't the only thing to fail but so does going to the BR webpage.

In file rpl-dag.c:
in function rpl_process_dio:

The following branch is not reachable:

  } else if(dio->rank == INFINITE_RANK && dag->joined) {
    rpl_reset_dio_timer(instance);
  }

because of this check performed before:

  if(dio->rank == INFINITE_RANK) {
    PRINTF("RPL: Ignoring DIO from node with infinite rank: ");
    PRINT6ADDR(from);
    PRINTF("\n");
    return;
  }

Here is the use case that presets the bug:

Start a network with a bunch of installed nodes. The border-router doesn't have a global prefix for some reason, so it uses a site-local prefix (fdfd or the contiki aaaa). Network starts up and every node gets that prefix.

Now the BR get a global prefix (maybe it took some time or someone had to enter it in). If you restart the BR with the new prefix, but the nodes still have the old prefix, then everything gets really messed up.

It appears the only way to change the prefix of a running network is to reboot all the nodes (which is no good if you are actually doing an installation :) )