Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dexter ethernet adapters all have the same MAC address #57

Closed
JamesNewton opened this issue Feb 11, 2019 · 8 comments
Closed

Dexter ethernet adapters all have the same MAC address #57

JamesNewton opened this issue Feb 11, 2019 · 8 comments
Assignees

Comments

@JamesNewton
Copy link
Collaborator

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

Commit 48867f3 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.

48867f3

Please note all the requirements for that to work.

@JamesNewton
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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

@JamesNewton
Copy link
Collaborator Author

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 JamesNewton reopened this Jul 29, 2020
JamesNewton added a commit that referenced this issue Jul 29, 2020
Correct a bug in the correction provided to correct #57
@JamesNewton
Copy link
Collaborator Author

Closed via
eb35d50

@JamesNewton
Copy link
Collaborator Author

Kamino cloned this issue to HaddingtonDynamics/OCADO

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants