[Contiki-developers] Neighbor discovery problem

[zeak.inc]

Hi everyone,

I am new to developing Contiki and I am working on simply Contiki port
for TI CC2520DK. It uses MSP430F2618 MCU and cc2520 radio chip. The port
is mostly based on timote sky port. For debugging I use UART. To test
my cc2520 driver I use two nodes where one of them ping another one.
Both nodes can see each other but when I enabled DEBUG flag in tcp_ip.c,
uip6.c, uip-nd6-io.c and uip-nd6.c I gets multiple messages about adding
and removing neighbor. Pinging node has address
fe80:0000:0000:0000:1112:fe67:5735:1430, second node:
fe80:0000:0000:0000:1112:fe67:5735:1429. As MAC layer I use 6lowmac.
Below I attached part of ping messages. How can I fix this problem?Any
advice would be helpful.

Thank you in advance,
Krzysztof Wiencek

######################### system start #########################

Contiki 2.4 started. Rime started with address 19.18.254.103.87.53.20.48

MAC 13:12:fe:67:57:35:14:30 sicslowmac channel 26

Tentative link-local IPv6 address fe80:0000:0000:0000:1112:fe67:5735:1430

Starting 'PING6v2 process'

In Process PING6

Wait for DAD

Sendin RS to ff02:0000:0000:0000:0000:0000:0000:0002 from fe80:0000:0000:0000:1112:fe67:5735:1430

Sending NS to ff02:0000:0000:0000:0000:0001:ff35:1430 from 0000:0000:0000:0000:0000:0000:0000:0000 with target address fe80:0000:0000:0000:1112:fe67:5735:1430

Ping address fe80:0000:0000:0000:1112:fe67:5735:1429:0000:0000:003c:0000:0021:296e:0000:0000:0

Sending Echo Request to fe80:0000:0000:0000:1112:fe67:5735:1429 from fe80:0000:0000:0000:1112:fe67:5735:1430

Adding neighbor with ip addr fe80:0000:0000:0000:1112:fe67:5735:1429 link addr 00:00:00:00:00:00 state 0

Sending NS to ff02:0000:0000:0000:0000:0001:ff35:1429 from fe80:0000:0000:0000:1112:fe67:5735:1430 with target address fe80:0000:0000:0000:1112:fe67:5735:1429

Sendin RS to ff02:0000:0000:0000:0000:0000:0000:0002 from fe80:0000:0000:0000:1112:fe67:5735:1430

INCOMPLETE: NS 2

Sending NS to ff02:0000:0000:0000:0000:0001:ff35:1429 from fe80:0000:0000:0000:1112:fe67:5735:1430 with target address fe80:0000:0000:0000:1112:fe67:5735:1429

Sending Echo Request to fe80:0000:0000:0000:1112:fe67:5735:1429 from fe80:0000:0000:0000:1112:fe67:5735:1430

tcpip_ipv6_output: neighbor cache entry incomplete

INCOMPLETE: NS 3

Sending NS to ff02:0000:0000:0000:0000:0001:ff35:1429 from fe80:0000:0000:0000:1112:fe67:5735:1430 with target address fe80:0000:0000:0000:1112:fe67:5735:1429

Sendin RS to ff02:0000:0000:0000:0000:0000:0000:0002 from fe80:0000:0000:0000:1112:fe67:5735:1430

Sending Echo Request to fe80:0000:0000:0000:1112:fe67:5735:1429 from fe80:0000:0000:0000:1112:fe67:5735:1430

Adding neighbor with ip addr fe80:0000:0000:0000:1112:fe67:5735:1429 link addr 00:00:00:00:00:00 state 0

Sending NS to ff02:0000:0000:0000:0000:0001:ff35:1429 from fe80:0000:0000:0000:1112:fe67:5735:1430 with target address fe80:0000:0000:0000:1112:fe67:5735:1429

INCOMPLETE: NS 2

Sending NS to ff02:0000:0000:0000:0000:0001:ff35:1429 from fe80:0000:0000:0000:1112:fe67:5735:1430 with target address fe80:0000:0000:0000:1112:fe67:5735:1429

END PING6

INCOMPLETE: NS 3

Sending NS to ff02:0000:0000:0000:0000:0001:ff35:1429 from fe80:0000:0000:0000:1112:fe67:5735:1430 with target address fe80:0000:0000:0000:1112:fe67:5735:1429

IPv6 packet received from fe80:0000:0000:0000:1112:fe67:5735:1429 to fe80:0000:0000:0000:1112:fe67:5735:1430

icmp6_input: length 80

Received NA from fe80:0000:0000:0000:1112:fe67:5735:1429 to fe80:0000:0000:0000:1112:fe67:5735:1430 with target address fe80:0000:0000:0000:1112:fe67:5735:1429

IPv6 packet received from fe80:0000:0000:0000:1112:fe67:5735:1429 to fe80:0000:0000:0000:1112:fe67:5735:1430

icmp6_input: length 80

Received NS from fe80:0000:0000:0000:1112:fe67:5735:1429 to fe80:0000:0000:0000:1112:fe67:5735:1430 with target address fe80:0000:0000:0000:1112:fe67:5735:1430

Adding neighbor with ip addr fe80:0000:0000:0000:1112:fe67:5735:1429 link addr 13:12:fe:67:57:35 state 2

Sending NA to fe80:0000:0000:0000:1112:fe67:5735:1429 from fe80:0000:0000:0000:1112:fe67:5735:1430 with target address fe80:0000:0000:0000:1112:fe67:5735:1430

Sending packet with length 80 (40)

tcpip_ipv6_output: neighbor cache entry stale moving to delay

DELAY: moving to PROBE + NS 1

Sending NS to fe80:0000:0000:0000:1112:fe67:5735:1429 from fe80:0000:0000:0000:1112:fe67:5735:1430 with target address fe80:0000:0000:0000:1112:fe67:5735:1429

PROBE: NS 2

Sending NS to fe80:0000:0000:0000:1112:fe67:5735:1429 from fe80:0000:0000:0000:1112:fe67:5735:1430 with target address fe80:0000:0000:0000:1112:fe67:5735:1429

PROBE: NS 3

Sending NS to fe80:0000:0000:0000:1112:fe67:5735:1429 from fe80:0000:0000:0000:1112:fe67:5735:1430 with target address fe80:0000:0000:0000:1112:fe67:5735:1429

PROBE END

Removing neighbor with ip addr fe80:0000:0000:0000:1112:fe67:5735:1429

IPv6 packet received from fe80:0000:0000:0000:1112:fe67:5735:1429 to fe80:0000:0000:0000:1112:fe67:5735:1430

icmp6_input: length 80

Received NA from fe80:0000:0000:0000:1112:fe67:5735:1429 to fe80:0000:0000:0000:1112:fe67:5735:1430 with target address fe80:0000:0000:0000:1112:fe67:5735:1429

IPv6 packet received from fe80:0000:0000:0000:1112:fe67:5735:1429 to fe80:0000:0000:0000:1112:fe67:5735:1430

icmp6_input: length 80

Received NS from fe80:0000:0000:0000:1112:fe67:5735:1429 to fe80:0000:0000:0000:1112:fe67:5735:1430 with target address fe80:0000:0000:0000:1112:fe67:5735:1430

Adding neighbor with ip addr fe80:0000:0000:0000:1112:fe67:5735:1429 link addr 13:12:fe:67:57:35 state 2

Sending NA to fe80:0000:0000:0000:1112:fe67:5735:1429 from fe80:0000:0000:0000:1112:fe67:5735:1430 with target address fe80:0000:0000:0000:1112:fe67:5735:1430

Sending packet with length 80 (40)

tcpip_ipv6_output: neighbor cache entry stale moving to delay

DELAY: moving to PROBE + NS 1

#####################################
those messages are frequently repeated

------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Contiki-developers mailing list
Contiki-d...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/contiki-developers

[David Kopf]

Hi,
It appears the neighbor advertisements contain a null link layer address.
Wireshark is a good way to investigate that; you can easily printf packets
from the radio driver before sending and after receiving, then convert to a
pcap with ethtype 0x809a. See how the rf230bb driver does it:

#if DEBUG>1
/* Output format is suitable for text2pcap to convert to wireshark pcap
file.
* Use $text2pcap -e 0x809a (these_outputs) capture.pcap
* Since the hardware calculates and appends the two byte checksum to Tx
packets,
* we just add two zero bytes to the packet dump. Don't forget to enable
wireshark
* 802.15.4 dissection even when the checksum is wrong!
*/
...
PRINTF("rf230_transmit:\n");
#if DEBUG>1
/* Note the dumped packet will have a zero checksum unless compiled with
RF230_CONF_CHECKSUM
* since we don't know what it will be if calculated by the hardware.
*/
{
uint8_t i;
PRINTF("0000"); //Start a new wireshark packet
for (i=0;i<total_len;i++) PRINTF(" %02x",buffer[i]);
PRINTF("\n");
}
#endif

Contiki 2.4 is quite old; there was a major change in the radio/mac/rdc
driver interfaces after that. You probably want to switch to the current
code, see
http://www.sics.se/contiki/wiki/index.php/Get_the_Contiki_source_code

-----Original Message-----
From: zeak.inc
Sent: Thursday, August 18, 2011 7:24 AM
To: contiki-d...@lists.sourceforge.net
Subject: [Contiki-developers] Neighbor discovery problem

Hi everyone,

I am new to developing Contiki and I am working on simply Contiki port
for TI CC2520DK. It uses MSP430F2618 MCU and cc2520 radio chip. The port
is mostly based on timote sky port. For debugging I use UART. To test
my cc2520 driver I use two nodes where one of them ping another one.
Both nodes can see each other but when I enabled DEBUG flag in tcp_ip.c,
uip6.c, uip-nd6-io.c and uip-nd6.c I gets multiple messages about adding
and removing neighbor. Pinging node has address
fe80:0000:0000:0000:1112:fe67:5735:1430, second node:
fe80:0000:0000:0000:1112:fe67:5735:1429. As MAC layer I use 6lowmac.
Below I attached part of ping messages. How can I fix this problem?Any
advice would be helpful.

[zeak.inc]

Hi,

thanks for your advice. I increased UIP_CONF_ND6_RETRANS_TIMER and
UIP_ND6_REACHABLE_TIME, after that nodes stared sending correct frames.
I don't really see connection between wrong link layer address and
timing increasing, but it works.

Unfortunately, I can't switch to newest Contiki version. I downloaded
from git Contiki source, ported my platform and while compiling simple
program I get messages:

/opt/msp430-gcc-4.4.5/lib/gcc/msp430/4.4.5/../../../../msp430/bin/ld:
example-ping6.ccmsp-em430 section `.bss' will not fit in region `data'
/opt/msp430-gcc-4.4.5/lib/gcc/msp430/4.4.5/../../../../msp430/bin/ld:
region `data' overflowed by 1252 bytes

It seems that code is too big, so I have to stay with Contiki 2.4.
While compiling on Contiki 2.4 program I noticed that I get multiple
messages:

warning: dereferencing type-punned pointer will break strict-aliasing rules

for example here:

../../core/net/uip6.c: In function ‘upper_layer_chksum’:
../../core/net/uip6.c:365: warning: dereferencing type-punned pointer
will break strict-aliasing rules

Warnings appear while compiling files uip6.c, tcpip.c, uip-split.c,
uip-ecmp6.c, uip-nd6-io.c, sicslowpan.c and pin6board.c(my ping version).

I use msp430-gcc-4.4.5 under Ubuntu 10.10. My platform use as MCU
MSP430f2618 .

Is these warnings can cause my problem with neighbor discovery? Problem
started again after I had implemented encryption( I encrypt only data
payload filed). Decryption works well and packet is correctly decrypted.

Cheers,
Krzysztof Wiencek.

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev

[David Kopf]

Those warnings can be eliminated by adding -fno-strict-aliasing to the
CFLAGS. The newer gccs don't like casting a dereferenced pointer to a
structure to an arbitrary place in memory which can lead to alignment
problems:
http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html

In your case everything can be byte-aligned so you can probably safely turn
the warning off. However, who knows if it is now doing some word alignments
by default, so adding -fpack-struct would also be a good idea.

You might get the image to fit by reducing some buffer sizes, but yes the
size has grown by around 1200 bytes since 2.4. Contikimac is using around
8K of that and is now the default. Were you using it in 2.4?

[Krzysztof Wiencek]

I added -fno-strict-aliasing, it remove warning but I still have problem with neigbor discovery when encryption is on. Node properly decode received frame but after that I get messages like "IPv6 packet received" form X to Y, where address X and Y are different to address received in frame.

When I was upgrading my port to newest Contiki I was using tmote sky port as example and simply copy contiki-conf.h and change to use my cc2520_driver. Network initialization is identical in both port (sky and mine).

Is there possibility to turn off neighbor discovery? At this moment I just need to make simply peer-to-peer connection between two nodes. I need to use 6lowpan but ND is not necessary now.

Krzysztof Wiencek

[Georg von Zengen]

Hi,

with the jackdaw_conf_raven.patch in the attachment ravens will be able
to use the eeprom configuration functions defined in cpu/avr/settings.c.

The second patch introduces the node_id to the raven platform.
This makes the raven more compatible with the tmote sky platform.

Regards,

Georg

[David Kopf]

Hi Georg,

I take it that with that settings patch all you had to do was then add
#define JACKDAW_CONF_USE_SETTINGS 1 to the raven contiki-conf.h?
If so cool, I'll maybe change those to AVR_CONF_USE_SETTINGS and put them on
a conditional so as not to change the default build.

Hi,

Regards,

Georg

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev

_______________________________________________

Contiki-developers mailing list
Contiki-d...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/contiki-developers

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev

[Georg von Zengen]

Thats right just add #define JACKDAW_CONF_USE_SETTINGS 1 and the
settings will be loaded form eeprom.

The problem with the eeprom config is, how to get it into the eeprom.
Do you have a good idea how to get it there without flashing a programm
with hardcoded values?

[David Kopf]

Well I think the program should have a hard coded address as a fallback if eeprom gets corrupted. The jackdaw writes all the
defaults to eeprom if the channel xor comparison fails, but that is not really necessary although it does help if you are trying to
locate it for overwriting with a hardware programmer. I program with the .elf file which loads eeprom all the time; setting the
eesave fuse would keep the old values.

The econotag generates a random mac like 00:50:C2:FF:FE:A8:CD:1A and writes it to rom, then uses that unless it gets erased. Not a
bad way to do it, the browser caches the corresponding url so you don't have to type it all the time. Getting a random number on the
raven is harder; I've tried a fast ADC conversion that only gets a range of ~5 values. The rf231/atmega128rfa1 have two random bits
that can be read out of the rssi register.

Probably it would be good to stick with 11:22:33:44:55 for the raven since it is used in existing documentation. The webserver
builds can get another through the makefsdata.h file which gets included in the httpd-fsdata.c file when /tools/makefsdata is run:
uint8_t mac_address[8] EEMEM = {0x02, 0x11, 0x22, 0xff, 0xfe, 0x33, 0x44, 0x55};

You *could* send a new mac using e.g http://[current::address]/changemac?001122334456, decode that in the handle_input routine and
write the new mac to eeprom, optionally overwriting the current link layer address. Or you could insert an icmp6 callback process
as in raven-lcd.c and send a magic packet like
ping6 -p deadbeef001122334456 for that purpose. But you can't specify a pattern on my cygwin ping.

[David Kopf]

Hi Georg,

Is node_id tied in to the panid, if not I could add a get_nodeid_from_eeprom.

I am puzzled how to use it in ipv6, what changes would you suggest:

rimeaddr_t addr;
get_eui64_from_eeprom(addr.u8);

#if UIP_CONF_IPV6
memcpy(&uip_lladdr.addr, &addr.u8, 8);
#else
node_id=get_panaddr_from_eeprom();
addr.u8[1]=node_id&0xff;
addr.u8[0]=(node_id&0xff00)>>8;
PRINTA("FROM EEPROM %X\n",node_id);
#endif
rimeaddr_set_node_addr(&addr);

I've refactored the eeprom management and will push the change soon.

-----Original Message-----
From: Georg von Zengen
Sent: Friday, August 26, 2011 2:04 PM
To: Contiki developer mailing list
Subject: [Contiki-developers] jackdaw config for raven

Hi,

Regards,

Georg

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev

_______________________________________________

Contiki-developers mailing list
Contiki-d...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/contiki-developers

------------------------------------------------------------------------------

EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev

[Georg von Zengen]

Hi David,

at the tmote sky the node_id is two byte long and used as the address
inside a PAN.
So it is not tied with the panid but with the PAN_ADDR.
I never used ipv6 with contiki, so I do not know which way is the best.
But in the code you sent the frist two byte of the mac will be
overwritten every time.
I think we should introduce a WITH_NODE_ID define like this:

rimeaddr_t addr;

#if UIP_CONF_IPV6
get_eui64_from_eeprom(addr.u8);
memcpy(&uip_lladdr.addr, &addr.u8, 8);
#else
#if WITH_NODE_ID

node_id=get_panaddr_from_eeprom();
addr.u8[1]=node_id&0xff;
addr.u8[0]=(node_id&0xff00)>>8;
PRINTA("FROM EEPROM %X\n",node_id);

#else
get_eui64_from_eeprom(addr.u8);
#endif
#endif
rimeaddr_set_node_addr(&addr);

In this way people who do not need a node_id could simply ignore it but
those who need it can use it easily.

Regards,

Georg

[Maciej Wasilak]

Hey Krzysztof,

there is no single flag, that can turn off Neighbor Discovery, so I think it's not possible to achieve it without modifying Contiki core files. To stop sending ND packets I would try commenting calls to uip_nd6_ns_output() and uip_nd6_ns_output() - it should be fairly safe - these functions only create packets to send, so commenting them shouldn't damage any system functionality.

Second thing to do is to hardcode MAC address of your packets (with no ND you have no MAC address resolution) - I think the best place to do that is tcpip_ipv6_output() function in contiki/net/tcpip.c .

Cheers
Maciek

2011/8/26 Krzysztof Wiencek <zeak...@gmail.com>