iotlab-m3: long HW address is in reversed order #13358
Description
Description
The computed hardware address returned on the iotlab-m3 is in reversed order. They all finished with 11:15 but they should start with 15:11. It is not possible to send unicast packets with the txtsnd shell command of examples/default.
Steps to reproduce the issue
- Start an experiment on IoT-LAB with a couple of M3 devices (but you can also use more):
$ iotlab-experiment submit -m buggy_m3 -d 42 -l saclay,m3,1-2
$ iotlab-experiment wait
- Buid
examples/defaultfor theiotlab-m3:
$ make BOARD=iotlab-m3 -C examples/default
- Flash the firmware on the boards:
$ iotlab-node --update examples/default/bin/iotlab-m3/default.elf
- Use the iotlab websocket serial tool and run
ifconfig:
$ iotlab-ws
Connected to m3-1.saclay
Connected to m3-2.saclay
ifconfig
m3-1.saclay: ifconfig
m3-1.saclay: Iface 4 HWaddr: 11:15 Channel: 26 Page: 0 NID: 0x23
m3-2.saclay: ifconfig
m3-1.saclay: Long HWaddr: 32:8F:F7:65:10:6B:11:15
m3-1.saclay: TX-Power: 0dBm State: IDLE max. Retrans.: 3 CSMA Retries: 4
m3-2.saclay: Iface 4 HWaddr: 11:15 Channel: 26 Page: 0 NID: 0x23
m3-2.saclay: Long HWaddr: 36:BD:FD:65:10:6B:11:15
m3-2.saclay: TX-Power: 0dBm State: IDLE max. Retrans.: 3 CSMA Retries: 4
m3-1.saclay: AUTOACK ACK_REQ CSMA L2-PDU:102 Source address length: 2
m3-1.saclay:
m3-2.saclay: AUTOACK ACK_REQ CSMA L2-PDU:102 Source address length: 2
m3-2.saclay:
>
As you can see in the output, both HWaddr are in reversed order and end with 11:15.
in 2019.10, the 2 last bytes in the HW address are different and both HW address start with 15:11. Sending unicast packets works.
I'm wondering if this is affecting all at86rf2xx radios (haven't tried on samr21-xpro) or maybe this is more low level ?
git bitsect found that the culprit commit is f0317c5 from PR #12606.
cc'ing @maribu, @benpicco and @miri64 who were involved in #12606.
I think the bug is quite serious and I would also propose to backport it to 2020.01. @fjmolinas, what do you think ?
Expected results
The HW addr is in the right order.
Actual results
The HW addr is in reversed order
Versions
Operating System Environment
-----------------------------
Operating System: "Ubuntu" "19.10 (Eoan Ermine)"
Kernel: Linux 5.3.0-29-generic x86_64 x86_64
System shell: /usr/bin/dash (probably dash)
make's shell: /usr/bin/dash (probably dash)
Installed compiler toolchains
-----------------------------
native gcc: gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008
arm-none-eabi-gcc: arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 8-2019-q3-update) 8.3.1 20190703 (release) [gcc-8-branch revision 273027]
avr-gcc: avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.2_1759) 5.4.0
mips-mti-elf-gcc: mips-mti-elf-gcc (Codescape GNU Tools 2016.05-03 for MIPS MTI Bare Metal) 4.9.2
msp430-gcc: missing
riscv-none-embed-gcc: riscv-none-embed-gcc (GNU MCU Eclipse RISC-V Embedded GCC, 64-bit) 8.2.0
xtensa-esp32-elf-gcc: missing
xtensa-esp8266-elf-gcc: missing
clang: clang version 9.0.0-2 (tags/RELEASE_900/final)
Installed compiler libs
-----------------------
arm-none-eabi-newlib: "3.1.0"
mips-mti-elf-newlib: "2.1.0"
riscv-none-embed-newlib: "3.0.0"
xtensa-esp32-elf-newlib: missing
xtensa-esp8266-elf-newlib: missing
avr-libc: "2.0.0" ("20150208")
Installed development tools
---------------------------
ccache: ccache version 3.7.3
cmake: cmake version 3.13.4
cppcheck: Cppcheck 1.88
doxygen: 1.8.13
git: git version 2.20.1
make: GNU Make 4.2.1
openocd: Open On-Chip Debugger 0.10.0+dev-01047-g09ac9ab1 (2020-02-05-08:53)
python: Python 2.7.17
python2: Python 2.7.17
python3: Python 3.7.5
flake8: 3.7.7 (mccabe: 0.6.1, pycodestyle: 2.5.0, pyflakes: 2.1.1) CPython 3.7.5 on Linux
coccinelle: spatch version 1.0.4 with Python support and with PCRE support