Dexter ethernet adapters all have the same MAC address

[JamesNewton]

The zedboard which is Dexters controller implements the ethernet interface hardware in the FPGA chip. Since the FPGA is loaded from the bit file on the sd card image, they all have the same hardware MAC address. ^ Technically, the MAC is loaded from the EEPROM, but that is loaded from the bit file, so...

This is not an issue if a USB WiFi dongle is used because the external dongle will have it's own MAC address. As #51 is resolve, that is the better option for multi-robot networking.

This is not an issue if a single Dexter is being connected directly to a PC as there is no other address to conflict.

This only becomes an issue when multiple Dexters are connected via CAT 5 to a single router. Although routers should be able to manage the rare case of duplicate MAC addresses, they do not. ^ ^

If you need multiple Dexters on one CAT5 ethernet, you will need to edit the interfaces file anyway to change the default fixed IP address, or edit for DHCP access so the MAC address can be edited at the same time.

To change the address, edit the /etc/network/interfaces file and add a line:

hwaddress ether 00:5D:03:01:02:03

substituting different values for the last few numbers. To avoid accidentally crashing with another ventors MAC address, one should probably start the address with one of the Xilinx assigned MAC ranges:
http://www.adminsub.net/mac-address-finder/xilinx

[JamesNewton]

See also

http://zedboard.org/content/mac-address

http://zedboard.org/content/passing-mac-address-kernel-device-tree-blob

It might be possible to generate a better MAC address from the serial number on the Zynq chip
https://www.xilinx.com/support/answers/40856.html

[JamesNewton]

The problem with AR# 40856 linked above is that it requires the development system to work. Instead, we should start assigning our own serial numbers to Dexters as they are built and then add a script that uses that serial number to set the MAC. If the serial # is set in the Defaults.make_ins file, RunDexRun script can read it out and set the MAC before it starts DexRun

[JamesNewton]

Commit 48867f3a0da662c892e8c28c46151c0dce3b4d23 attempts to resolve this issue by getting a serial number from the Defaults.make_ins file and converting it to a mac address, then editing the mac addresses in the /etc/network/interfaces file to update those for the next restart.

https://github.com/HaddingtonDynamics/Dexter/commit/48867f3a0da662c892e8c28c46151c0dce3b4d23

Please note all the requirements for that to work.

[JamesNewton]

The best way to resolve this is just to use a WiFi adapter as they all have their own mac addresses AND you can get as many Dexters as you like on your local network AND they all have internet connections for e.g. ntp time, remote operation, etc... See: https://github.com/HaddingtonDynamics/Dexter/wiki/Dexter-Networking#wifi

[JamesNewton]

Scratch that... for some strange reason, the WiFi adapter ALSO has the hwaddress set for the CAT5 adapter! (???)

[JamesNewton]

The existing RunDexRun is using the BASH printf to convert the serial number to a hexadecimal MAC address. Unfortunately, the BASH printf, unlike real printf, interprets any number starting with a 0 as being an octal number (rather than decimal) and so any serial number with an 8 or a 9 in any digit results in an error and the MAC is not made unique. e.g. DEX-000038 or 39 or 18 or 19 or 28 or 29 will all have the same MAC.

The problem, and solution are documented here: https://stackoverflow.com/a/11804275/663416

This wasn't noticed because only 2 out of 10 robots made so far would have the problem, and we weren't checking the mac address on every robot, and none of the test values I put in happened to have an 8 or 9 /and/ also leading zeros. Great catch @kgallspark ! And also, "really bash? really?"

To fix, edit RunDexRun and change line 32 from: mac=$(printf "%06x\n" $dexserial ) to mac=$(printf "%06x\n" $(( 10#$dexserial )) )

[JamesNewton]

Closed via https://github.com/HaddingtonDynamics/Dexter/commit/eb35d50ae94b744fc3401cad0da61355331b2004

[JamesNewton]

Kamino cloned this issue to HaddingtonDynamics/OCADO