espressobin all boards and all nics have the same mac address


Recommended Posts

as per title...

 

i have 2 boards running armbian (Debian version). Even if the mac addresses on  /boot/armbianEnv.txt are set differently,  all nic cards of both boards, have the same exact mac address, specifically f0:ad:4e:03:64:7f   this of course creates a lot of problems because i cannot connect my 2 boards in the same network

 

here is armbianmonitor from the 1st board - https://pastebin.com/N9AuwV2h

 here is the same for the 2nd board -  https://pastebin.com/QcTq3BaD

 

apparently i am not the only one http://espressobin.net/forums/topic/each-network-interface-has-the-same-mac-address/

Link to post
Share on other sites
Armbian is a community driven open source project. Do you like to contribute your code?

These boards are using MAC addresses defined in u-boot environment. They are usually not updated by the manufacturer of the evaluation platform.

You can replace them by defining the following variables and issuing "saveenv" afterwards:

ethaddr=00:51:82:11:22:00
eth1addr=00:51:82:11:22:01
eth2addr=00:51:82:11:22:02
eth3addr=00:51:82:11:22:03

...etc.

Link to post
Share on other sites
On 5/21/2019 at 3:44 PM, kostap said:

ethaddr=00:51:82:11:22:00

eth1addr=00:51:82:11:22:01
eth2addr=00:51:82:11:22:02
eth3addr=00:51:82:11:22:03

...etc.

This didn't work for me.

And I also changed them in boot.cmd and armbianEnv.txt, still didn't work; I still get the same annoying MAC -address.

Further detail: I have connection to the first board until the second board reaches the systemd-networkd startup, then the connection to my first board freezes.

Thus it's Network Manager that causes the problems.

It would be real nice if part of the MAC address could be generated by some unique ID from the CPU or another IC on the board.

Link to post
Share on other sites
On 5/6/2019 at 9:55 PM, ManoftheSea said:

In them, apply a declaration to set the MAC address in the [link] section

I did that, but still no dice. Same problem as described in my post above.

When I boot board number 2, the connection to board number 1 breaks.

I have unique MAC addresses in all the 10-*.network files.

In addition, I have unique MAC addresses in boot.cmd and armbianEnv.txt

Still I can only have one EspressoBIN on the same network.

Link to post
Share on other sites

@Jens Bauer @ManoftheSea @anubisg1

The MAC address of the bridge can be specified in 10-br0.netdev. This works without any issues in Stretch and in Buster (at least on a V5_0_1 EspressoBin). If you have problems with Ubuntu Bionic, then their implementation of systemd-networkd may be the reason.

 

# cat 10-br0.netdev
[NetDev]
Name=br0
Kind=bridge
MACAddress=XX:XX:XX:XX:XX:XX

# networkctl
IDX LINK             TYPE               OPERATIONAL SETUP     
  1 lo               loopback           carrier     unmanaged 
  2 eth0             ether              degraded    configured
  3 wan              dsa                degraded    configured
  4 lan0             dsa                no-carrier  configuring
  5 lan1             dsa                no-carrier  configuring
  6 br0              bridge             routable    configured

 _____                                   _     _       
| ____|___ _ __  _ __ ___  ___ ___  ___ | |__ (_)_ __  
|  _| / __| '_ \| '__/ _ \/ __/ __|/ _ \| '_ \| | '_ \ 
| |___\__ \ |_) | | |  __/\__ \__ \ (_) | |_) | | | | |
|_____|___/ .__/|_|  \___||___/___/\___/|_.__/|_|_| |_|
          |_|                                          
Welcome to Debian Buster with Armbian Linux 4.19.57-mvebu64
System load:   0.15 0.13 0.11  	Up time:       17:54 hours		
Memory usage:  37 % of 990MB  	Zram usage:    36 % of 495Mb 
Usage of /:    18% of 908G  

 

Link to post
Share on other sites
On 5/4/2019 at 10:47 PM, anubisg1 said:
i have 2 boards running armbian (Debian version). Even if the mac addresses on  /boot/armbianEnv.txt are set differently,  all nic cards of both boards, have the same exact mac address, specifically f0:ad:4e:03:64:7f   this of course creates a lot of problems because i cannot connect my 2 boards in the same network

This is due to broken and insane armbian uboot boot script: https://dl.armbian.com/espressobin/u-boot/bootscript/boot.cmd

 

This armbian boot script overwrites mac address to F0:AD:4E:03:64:7F for all espressobin boards. Normally espressobin boards have stored in this variable its original mac address assigned at manufacturing, but somebody in armbian must have been drunk when decided to erase original mac address and replace it by static value for all espressobin boards.

 

Last version of mainline linux kernel (+upcoming stable kernel releases) are able to read mac address from uboot env (as passed via FDT; kernel patch), so the best is to restore espressobin's original mac address into uboot (espressobin boards had stick with printed mac address) and stop using that insane uboot armbian script which erases original unique mac address.

Edited by Pali
Link to post
Share on other sites
2 hours ago, Pali said:

Normally espressobin boards


There is nothing normal about those board which is why we used insane approaches. Welcome to submit a diff, that this gets correct. Thanks.

I am glad that TODAY we don't need to poke Linux anymore to get this board up and running. Its insane how much time we wasted for it.

Link to post
Share on other sites
On 8/23/2020 at 4:46 PM, Igor said:

There is nothing normal about those board which is why we used insane approaches. Welcome to submit a diff, that this gets correct. Thanks.

 

As I wrote mac address is normally stored in env variable at location stored in manufactured uboot. If you had compiled your own uboot version, you may set different location for env in SPI which would lead to not loading env variables.

 

But in any case, erasing existing mac address or permanently removing it, by changing it by static hardcoded value is the worst what could have been done. Even abnormal behavior does not excuse permanent removal of existing manufactur mac address.

 

I have already sent README update patch.

Link to post
Share on other sites
1 hour ago, Pali said:

is the worst what could have been done.


:P It can be much worse. 

Try early official builds and you will see how worse can it be. This hack is because at that time there was no other method to read MAC ... its a left-over workaround. Also we build u-boot from sources since the day one because official builds were behind and because we were trying to standardise boot process as much as possible ...

Tnx, we'll fix this when possible.

Link to post
Share on other sites
On 8/23/2020 at 8:31 AM, Pali said:

This is due to broken and insane armbian uboot boot script: https://dl.armbian.com/espressobin/u-boot/bootscript/boot.cmd

 

This armbian boot script overwrites mac address to F0:AD:4E:03:64:7F for all espressobin boards. Normally espressobin boards have stored in this variable its original mac address assigned at manufacturing, but somebody in armbian must have been drunk when decided to erase original mac address and replace it by static value for all espressobin boards.

 

Hi, Sorry that was me 3 years ago.  I wasn't drunk.  If I recall, I ended up doing that because for whatever reason the vars from on-board u-boot weren't being parsed.

I remember the macs in the firmware being wrong too, but I just set by hand with the MAC addresses sticker on the board.   That was a v4 board so who knows.

Anyway I'll take a look.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...