Guest Posted May 4, 2019 Share Posted May 4, 2019 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 comment Share on other sites More sharing options...
ManoftheSea Posted May 6, 2019 Share Posted May 6, 2019 I would suggest you look in /etc/systemd/network, at the 10-lan[01].network and 10-wan.network files In them, apply a declaration to set the MAC address in the [link] section [Match] Name=lan0 [Link] MACAddress=0011.2233.4455 Link to comment Share on other sites More sharing options...
kostap Posted May 21, 2019 Share Posted May 21, 2019 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 comment Share on other sites More sharing options...
Jens Bauer Posted July 4, 2019 Share Posted July 4, 2019 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 comment Share on other sites More sharing options...
Jens Bauer Posted July 4, 2019 Share Posted July 4, 2019 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 comment Share on other sites More sharing options...
ebin-dev Posted July 11, 2019 Share Posted July 11, 2019 @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 1 Link to comment Share on other sites More sharing options...
Jens Bauer Posted July 12, 2019 Share Posted July 12, 2019 20 hours ago, ebin-dev said: The MAC address of the bridge can be specified in 10-br0.netdev And that was exactly what I was missing! Now it seems my worst problem has passed. Thank you very much, @ebin-dev! Link to comment Share on other sites More sharing options...
Pali Posted August 23, 2020 Share Posted August 23, 2020 (edited) 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 August 23, 2020 by Pali Link to comment Share on other sites More sharing options...
Igor Posted August 23, 2020 Share Posted August 23, 2020 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 comment Share on other sites More sharing options...
Pali Posted August 25, 2020 Share Posted August 25, 2020 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 comment Share on other sites More sharing options...
Igor Posted August 25, 2020 Share Posted August 25, 2020 1 hour ago, Pali said: is the worst what could have been done. 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. 1 Link to comment Share on other sites More sharing options...
Igor Posted September 4, 2020 Share Posted September 4, 2020 This problem was fixed & images were updated to 5.8.y Link to comment Share on other sites More sharing options...
lanefu Posted September 5, 2020 Share Posted September 5, 2020 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. 1 Link to comment Share on other sites More sharing options...
Pali Posted October 11, 2020 Share Posted October 11, 2020 Seems that another source of problems is bootenv where is hardcoded another set of mac addresses... https://github.com/armbian/build/blob/master/config/bootenv/mvebu64.txt Link to comment Share on other sites More sharing options...
Recommended Posts