@mahboobkarimian interesting, but I'm afraid I don't get where the problem is coming from! First, what do you mean by "native node" in Cooja? Second, timing in Cooja should be perfectl, with no drift (unless you use msp430 nodes and explicitly configure the drift)
@atiselsts By native node, I mean compiled to x86 code.
I was using TSCH, after some time, I could see misalignments in TSCH timeslots between TX and RX nodes. I will take a screenshot next time.
Also once the node chooses a DODAG root, it stays in that DODAG
linkaddr_set_node_addr(&new_addr)as specified by the
linkaddr_node_addrdocumentation. But when I do that, the RPL network does not build. The IPv6 addresses indicated by the RPL logs do not use my new link layer address, and I can see in the logs that DIS and DIO are sent. Can anyone help me?
examples\antelope\netdb\netdb-client.c , the
if (ev == serial_line_event_message && data !=NULL) will work.
And, you can see the
CONTIKI = ../../../ APPS += antelope CFLAGS += -DPROJECT_CONF_H=\"project-conf.h\" SMALL = 1 all: netdb-client netdb-server CONTIKI_WITH_RIME = 1 include $(CONTIKI)/Makefile.include
after I did some tests, I found that you must set
CONTIKI_WITH_RIME = 1 in your own Makefile to make
ev == serial_line_event_message available.
So is this the end of the story? No, soon you will find that you will get into a dilemma.
If you set a another statement like
CONTIKI_WITH_IPV6 = 1 , this will make
ev == serial_line_event_message unavailable again!
I don't know if this is a simple-minded question, or I read the standard incorrectly, but I have a question about TSCH seqno.
I've started a project for parsing some network behaviour via the Contiki-NG logging system. I've based on the python result-visualization example, and I was trying to trace the TSCH packet via its seqno.
216048000 4 [INFO: App ] app generate packet seqnum=48 node_id=4 216048000 4 [INFO: TSCH ] send packet to 0001.0001.0001.0001 with seqno 153, queue 1/64 1/64, len 21 43 216055136 1 [INFO: TSCH ] received from 0004.0004.0004.0004 with seqno 153 216055136 1 [INFO: App ] app receive packet seqnum=48 from=fd00::204:4:4:4 216055136 4 [INFO: TSCH ] packet sent to 0001.0001.0001.0001, seqno 153, status 0, tx 1
The App generates a packet (UDP) and sends it to sink (1), the TSCH seqno is 153 and is received and acknowledged by the sink with the simple seqno.
There are some kinds of broadcast messages that the TSCH seqno change. I read in the standard (I just have access to 802.15.4-2015), and I understood that in some cases the macEbsn has to be used but, the logging system returns the seqno 65536. In the case below I think that should be 117 or 192.
19500000 4 [INFO: RPL ] sending a DIS to ff02::1a 19500000 4 [INFO: TSCH ] send packet to ffff.ffff.ffff.ffff with seqno 117, queue 1/64 1/64, len 14 24 19522888 4 [INFO: TSCH ] packet sent to 0000.0000.0000.0000, seqno 192, status 0, tx 1 19522888 1 [INFO: TSCH ] received from 0004.0004.0004.0004 with seqno 65535 19522888 1 [INFO: RPL ] received a DIS from fe80::204:4:4:4 19522888 1 [INFO: RPL ] reset DIO timer (Multicast DIS)
If this behaviour is right, why the TSCH seqno is 65536? Any light? Thank you for your time :)
/* Seqno of 0xffff means no seqno */- 65535 is 0xffff in hex, meaning no seqno. I think that broadcast packets including EB are sent without a seqno (with Sequence Number Suppression field in the frame header set to 1). The problem is on the sender side, where the seqno 192 shows up, even though its not used in the frame.
the Error in Contiki 3.0
/home/user/contiki-Contiki-CoAPS/tools/cooja/build.xml:199: The following error occurred while executing this line:
Could not find the MSPSim build file. Did you run "git submodule update --init"?