wrong checksum

Hello,

have simple setup with linux rpi2 + rf233 and RIOT os based node with rf233 on other end. for the moment native linux supports only node so in fact have only 2 nodes in the network.

on the riot side have

My address is ff02::1 My address is fe80::8a77:6655:4433:2212 My address is ff02::1:ff33:2212

the last one is solicited-node multicast - that is what I need.

The problem I’m seeing is that while pinging from linux side I’m getting icmpv6: wrong checksum from _calc_csum in gnrc_icmpv6_demux while trying to receive neighbor solicitation (icmpv6 type 135) from linux. I know that I should get this message, but with correct checksum:)

I have seen this thread in the mailing list https://lists.riot-os.org/pipermail/devel/2016-February/003433.html which seems like is not working for Sebastian.

So the question is, if mentioned setup is supported by the RIOT/linux and should work? I’m just waiting for sniffer but maybe somebody can confirm that seen/have it working.

There may be problem with my riot as well since I have ported RIOT to TI compiler and using Code Composer Studio to build it. Not to mention that im using currently unsupported 20bits msp430 cpu.

thanks in advance wbr

malo

Hi Malo,

First, as you referred to my question on the list: I eventually got my setup working, so your's should work as well. Second, for debugging you should definitely get a 3 third node to work as a sniffer and monitor connection between the other 2.

How did you enable the rf233 transceiver on the rapsi? For starters I would suggest you simply use latest Raspian and activate the device-tree overlay. I wrote some guides that might be helpful, see [1]. NOTE: I had some trouble with the SPI freq, you should set it to 3MHz, default is/was 6MHz. But in my case this was to high and all packets were corrupted -> may be that causes your checksum fail? You should see those corrupted packets on the sniffer ...

On the RIOT side you should use the gnrc_networking example [2] for initial testing. If you have this basic setup running you (remember to match channel and pan_id on both sides), you should be able to send pings on _link local addresses_ from RasPi to RIOT and vice-versa.

Hope this helps to get you started,

Best,   Sebastian

[1]: https://github.com/RIOT-Makers/wpan-raspbian/wiki [2]: https://github.com/RIOT-OS/RIOT/tree/master/examples/gnrc_networking

Hi,

Hi Malo,

First, as you referred to my question on the list: I eventually got my setup working, so your's should work as well. Second, for debugging you should definitely get a 3 third node to work as a sniffer and monitor connection between the other 2.

How did you enable the rf233 transceiver on the rapsi? For starters I would suggest you simply use latest Raspian and activate the device-tree overlay. I wrote some guides that might be helpful, see [1]. NOTE: I had some trouble with the SPI freq, you should set it to 3MHz, default is/was 6MHz. But in my case this was to high and all packets were corrupted -> may be that causes your checksum fail? You should see those corrupted packets on the sniffer ...

I thought you had different experience with RPi Kernel and mainline kernel, see [0].

On mainline kernel it works with 6 Mhz (like in my case), but RPi kernel has issues at 6 Mhz.

The speedup here doesn't matter much, 3 Mhz should be fine in both cases. :slight_smile:

- Alex

[0] problem with device tree overlay at86rf233 · Issue #1294 · raspberrypi/linux · GitHub

Hi Alex, and all,

Hi,

Hi Malo,

First, as you referred to my question on the list: I eventually got my setup working, so your's should work as well. Second, for debugging you should definitely get a 3 third node to work as a sniffer and monitor connection between the other 2.

How did you enable the rf233 transceiver on the rapsi? For starters I would suggest you simply use latest Raspian and activate the device-tree overlay. I wrote some guides that might be helpful, see [1]. NOTE: I had some trouble with the SPI freq, you should set it to 3MHz, default is/was 6MHz. But in my case this was to high and all packets were corrupted -> may be that causes your checksum fail? You should see those corrupted packets on the sniffer ...

I thought you had different experience with RPi Kernel and mainline kernel, see [0].

On mainline kernel it works with 6 Mhz (like in my case), but RPi kernel has issues at 6 Mhz.

The speedup here doesn't matter much, 3 Mhz should be fine in both cases. :slight_smile:

- Alex

Just to clarify:

It wasn't exactly about rpi and mainline Kernel. My experience was that somehow the issue was with the device tree overlays. I first followed this guide [1] modifying the DTS file for the RasPi to support openlabs transceiver and compiled a new Linux Kernel (4.1.y) - this worked with 6MHz. Note: I used the patched rpi Kernel sources[2], not the mainline Kernel.

Later on, I found out about the device-tree overlay support and that there already exists one for the rf233 transceiver. I then tried latest Raspian image enabling the dt overlay which correctly identified and enabled the openlabs transceiver so basically it worked. But I got this problem with corrupted packets, which I solved by lowering SPI freq to 3MHz [0]. I never compiled a mainline Kernel (at least not in this case :), I was always using [2].

Best,   Sebastian

[0] problem with device tree overlay at86rf233 · Issue #1294 · raspberrypi/linux · GitHub

[1]: How to install 6LoWPAN Linux Kernel on Raspberry Pi · RIOT-OS/RIOT Wiki · GitHub [2]: GitHub - raspberrypi/linux: Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/

Hello all,

Thanks for the answer Sebastian, I’m using Linux raspberrypi 4.1.13-v7+ #826 SMP PREEMPT Fri Nov 13 20:19:03 GMT 2015 armv7l GNU/Linux with at86rf233 default overlay running at 3MHz.

got the sniffer and can see that have some general issue with check sums since all packets send from RIOT have bad csums. The error is still the same so I’m not that convinced that is HW issue (even is possible)

The “good news” is that when im ignoring result from _calc_csum called in gnrc_icmpv6_demux then I have the ping working! (luckily linux does not drop packets with bad csums:)

the checksums from wireshark (using CC2531EMK) router solicitation: is 0xD004 should be 0xD000 neighbor advertisement: is 0x36F9 should be 0x36F2 echo reply : is 0x7837 should be 0x782F

I have feeling that _calc_csum is not friend with 16/20 bit platforms (just guessing at the mo) since seems like some overflow somewhere…

I’ll keep digging this direction, but any hints are highly appreciated.

wbr malo

Hey Malo,

there is unittest for checksum calculation[1] in RIOT, try to flash that on your board and see if it fails or succeeds. Maybe it helps, but I have to admit that's just a quick guess ...

cheers,   Sebastian

[1]: https://github.com/RIOT-OS/RIOT/tree/master/tests/unittests/tests-inet_csum

Hi Malo, did you check if everything is coming out right out of 6LoWPAN IPHC and/or fragmentation (check with a sniffer)? Sometimes older 6LoWPAN implementations have wrong datagram sizes and do weird stuff in the IPHC header (don't want to discredit your work though Alexander; up until now it seemed fine ^^").

Cheers, Martine

Hi,

Hi Malo, did you check if everything is coming out right out of 6LoWPAN IPHC and/or fragmentation (check with a sniffer)? Sometimes older 6LoWPAN implementations have wrong datagram sizes and do weird stuff in the IPHC header (don't want to discredit your work though Alexander; up until now it seemed fine ^^").

this wasn't me. The not working parts was copy&pasted from contiki from the old maintainers.

btw: We don't have currently a stable strategy, that means we don't fix things into stable. It's just too difficult, because the most patches are "rework xy".

So please use the lastest greatest kernel, the RPi has meanwhile a good mainline support, so you could use [0] which I recommend.

- Alex

[0] kernel/git/bluetooth/bluetooth-next.git - Bluetooth kernel development tree

Hello,

no need to blame the kernel here, as I wrote in prev post I have had wrong csums on the outgoing packets as well. Thanks for pointing me at unitests for inet_csums - they were failing all on my platform/compiler.

the problem was in inet_csum_slice, where

csum += (*buf << 8) + *(buf + 1);

turned to signed math.

change to

csum += (uint16_t)…

solves the problem.

btw: do you run inet_csums unitest for some 16bits platform? to find out if is platform or compiler specific.

thanks for all the help wbr malo

Hey,