Long addresses are transferred in reverse order.

[jfischer-no]

During my adventure "Communication between RIOT and Linux host," I have discovered that the long addresses are transferred in reverse order.
If I replace it like:

-         uint64_t target_h = NTOHLL(target->uint64);
-         memcpy(p.frame.dest_addr, &target_h, 8);

+        memcpy(p.frame.dest_addr, &(target->uint8), 8);

(see https://github.com/RIOT-OS/RIOT/blob/master/sys/net/link_layer/net_if/net_if.c#L379)
then the addresse will be transmitted correctly.

In which order are the addresses in net_if_eui64_t?

[cgundogan]

@BytesGalore did you also encounter this behavior?
@jfischer-phytec-iot can you briefly explain your setup?

[BytesGalore]

@cgundogan I only used short addresses, due to always running into "the old way" of transmitting a packet.
I will test long addresses tomorrow morning without and with the fix proposed by @jfischer-phytec-iot, then I will report.

[jfischer-no]

@cgundogan

• Phytec Wega SBC + Linux Kernel 3.19 + IEEE 802.15.4. Transceiver CC2520 connected over SPI
• Phytec phyWAVE Board (RIOT port for the MKW22D512 SiP and Phytec PBA-D-01 PhyWave Evaluations-Board #2059 and driver: RIOT port for the Freescale kw2x radio #2329)

[BytesGalore]

@cgundogan @jfischer-phytec-iot unfortunately I cannot test/reproduce neither using (forcing) long address usage :(
The R-IDGE Linux USB border router seems to drop the packets internally (the R-IDGE firmware has no promiscuous mode yet). Only multicast addresses are successfully processed by now.

But still the proposition seems to be valid as we take the RPL parent address directly form a provided DIO [1] and do not convert the byteorder [2] when assigning the address of this parent.

For instance sending (trying to send) a packet to:
fe80::12:4bff:fee4:a83 results in:
p.frame.dest_addr == {0x83, 0x0a, 0xe4, 0xfe, 0xff, 0x4b, 0x12 0x00} using the byteorder conversion [3].

[1] https://github.com/RIOT-OS/RIOT/blob/master/sys/net/routing/rpl/rpl_control_messages.c#L685
[2] https://github.com/RIOT-OS/RIOT/blob/master/sys/net/routing/rpl/rpl_dodag.c#L180
[3] https://github.com/RIOT-OS/RIOT/blob/master/sys/net/link_layer/net_if/net_if.c#L379

[jfischer-no]

"Fields that are longer than a single octet are sent to the PHY in the order from the octet containing the lowest numbered bits to the octet containing the highest numbered bits." <- (IEEE Std 802.15.4TM‐2011"
As I understand, ntohll is correct here?

[jnohlgard]

@jfischer-phytec-iot What is described there is little-endian, i.e. not Network Byte Order (Big endian)

[jfischer-no]

Currently I'm not sure where it goes wrong. The target is the link layer addresse from the neighbor cache and it is always an array of uint8_t.
The function sixlowpan_mac_send_data (mac.c) casts it to a (net_if_eui64_t *).
I'll dig a little further tomorrow.

@authmillenon Do you have any idea?

[miri64]

No, not without digging myself :/

[jnohlgard]

the byte swap at https://github.com/RIOT-OS/RIOT/blob/master/sys/net/link_layer/net_if/net_if.c#L379 seem out of place, but I have not done any tests or debugging...

[jfischer-no]

@gebart I also thought so, but then type casting to (net_if_eui64_t *) is also not right.

[jnohlgard]

Which radio are you using when seeing? I plan on testing this on an at86rf212b during the weekend.

[jnohlgard]

I have noticed the same issue as you describe here using the at86rf212b.

[OlegHahm]

That was related to the old network stack only, right? Can we close then?

[BytesGalore]

@jfischer-phytec-iot is this still relevant? I'm asking since the gnrc stack is armed, so any objections to close this issue from your side?

[cgundogan]

@jfischer-phytec-iot ping

[OlegHahm]

I take this as a no. ;)

[DipSwitch]

Linux <-> RIOT works just fine if I use at86rf212b :)