MAC address duplicate for GL-AR300M #397
Comments
|
Could you post the support tool data for the node? |
|
I can confirm this behavior on a pair of AR300M16-Ext nodes. When booting the manufacturer's latest firmware on one of them, I get addresses of the form:
If I then load 1510-ba55aed and check immediately after first boot, before any configuration has been done, I get:
Both nodes have 00:03:7f:11:23:c6 as the eth1 address. Because the 00:03:7f OUI belongs to Qualcomm Atheros, I suspect it's a default value programmed into the chipset, and we're failing to override it at boot time. The 94:83:c4:xx:xx:xc address appears in the "art" partition (/dev/mtd6), but the "...d" address does not, so I assume that the manufacturer's firmware is just adding 1 to the eth0 address to get the eth1 address. |
Workaround:(fiddly, but it works)
|
|
So there's a file /etc/init.d/local which runs on each boot, but specifically on first boot it creates the /etc/aredn_include/ethmacfixup file based on a few rules. Is this file empty on this hardware? Unfortunately it's not included in the supportdata. Maybe we need to add some new rules here for this device. |
|
I just bought one of these on Amazon so hopefully can get to a solution this weekend. |
|
That file exists, but it doesn't handle this case because the eth1 MAC address is valid and differs by more than 10 from the WiFi MAC address. As an experiment, I changed the test on line 24: ...quoting the fixed eth0 MAC address both of my units share. Now eth1 gets a valid MAC address and all is well. Note that if OpenWRT had initialized the eth1 interface in the same way that the manufacturer's firmware does (setting the eth1 MAC to the eth0 MAC + 1), the existing code in /etc/init.d/local would have been triggered because the MAC addresses differ numerically by less than 10. So, I think that, strictly speaking, this issue is really an upstream problem. As a practical matter, we'll have to deal with it for now. Can you think of a less fragile test we could use? I thought about testing just the OUI part, but I don't want to mess up other devices that might use Qualcomm Atheros MAC addresses. We could also compare the OUIs of the WAN and LAN—or WiFi and LAN—interfaces, or check the hardware type, or something like that. Ideas? |
|
One of the reason I bought a new device from Amazon was to see if the mac was the same as you see on your two devices. If so, and I assume you devices aren't brand new, we might be okay assuming this value is the "magic" key here. I'm reluctant to over-generalizing as you also are. |
|
If the upstream root cause is the device from the OEM has reused the MAC on multiple devices, and the vendor's firmware resolves this, this suggests we need to put in a random MAC generator to address. Something like this (probably mangled by github): NEWMAC=$(echo 00:11:22:$(dd if=/dev/urandom bs=1024 count=1 2>/dev/null | md5sum | sed 's/^(..)(..)(..)(..)(..)(..).*$/\1:\2:\3'/)) |
|
@aanon4 Sadly, my devices are also new; I ordered them from Amazon on July 11th. Sorry! Did you get them with or without the external antennae? Mine are with. @ae6xe My guess is that the cause is slightly different from what you are saying. I don't think GL.iNet manufactured the devices with duplicate MAC addresses and is patching the problem in software; I think the devices are working as intended and the eth1 MAC address was always intended to be derived from the eth0 MAC address. If you scan /dev/mtd6 (the "art" partition), you can find one MAC address in the 96:83:c4 OUI, which belongs to GL.iNet. There are no other nearby byte sequences that look like MAC addresses, and the specific duplicate MAC address we see appears nowhere in any MTD partition. The MAC address in /dev/mtd6 is assigned to both eth0 (WAN) and wlan0, which I guess is OK because those two interfaces could never appear on the same network. When you run GL.iNet's firmware, the eth1 interface also gets the same MAC address, except that the sixth byte is incremented by 1. When you run our firmware, eth0 gets the same address as before, but eth1 always gets 00:03:7F:11:23:C6. Because the 00:03:7F OUI belongs to Qualcomm Atheros and not GL.iNet, I think that the 00:03:7F:11:23:C6 address is just a default value compiled into the bitstream used to initialize the chipset. It is expected to be overridden by the firmware, which GL.iNet's firmware does but OpenWRT does not. So I think it's an OpenWRT bug. Nevertheless, even if OpenWRT implemented the same algorithm as the GL.iNet firmware, /etc/init.d/local would still rewrite the eth1 address at first boot to avoid assigning the interfaces sequential IPv4 addresses, which as I understand it causes a problem in OLSR. The approach /etc/init.d/local uses is to increment the fourth (rather than the sixth) byte. Whether this approach is more or less likely to cause a collision than choosing a random MAC address is one of those statistics problems I always hated... :-) |
No worries. I ordered one of each .. which might be informative |
|
I have a GL-AR300M, when I original ported AREDN to the model. It has the following: eth0 MAC: E4:95:6E:43:A8:79 The ART /dev/mtd6 partition has both MAC #s: Is your ART partition the same? There is no handling for this model in the ./openwrt/target/linux/ar71xx/base-files/etc/board.d/02_network: ar71xx_setup_macs() -- this would pass through the setting as openwrt runs this script on firstboot to create this detail in /etc/board.json. 2nd option is to make the patch in /etc/init.d/local . It appears that this 0003 7f11 23c6 MAC is the same on all the devices, and the firmware needs to do something to ensure uniqueness across devices. I put in the -le 10 check and the code to handle tplink, mikrotik, and resolve an olsr failure I saw at the time. the '10' was just enough to not trigger the failure, but I don't recall the specific failure, it's been too long. |
|
On 7/22/2022 8:08 PM, Joe AE6XE wrote:
The ART /dev/mtd6 partition has both MAC #s:
0000000 e495 6e43 a879 *0003 7f11 23c6* ffff ffff
0001000 0202 *e495 6e43 a879* 0000 0000 0000 0000
Is your ART partition the same?
Oops! You're right; mine looks just like that. I was confused because,
just as in your example above, the eth0 MAC occurs twice in the file,
once at offset 0 and again at offset 4098. Because of the way I did the
search, it was the second one I saw, and that second occurrence isn't
followed by the eth1 MAC.
But the first one is, and as you say, it looks like they're all
identical. I don't know why my search didn't turn it up; perhaps I
mistyped (or mis-pasted) it. Sorry!
There is no handling for this model in the
./openwrt/target/linux/ar71xx/base-files/etc/board.d/02_network:
ar71xx_setup_macs() -- this would pass through the setting as openwrt
runs this script on firstboot to create this detail in /etc/board.json.
Aha, thanks! And of the models that /are /handled by that function, a
fair percentage contain exactly the add-1-to-the-other-MAC-address logic
that the stock GL.iNet firmware seems to be using.
So, my first impulse would be to add a handler that does the same thing
(which would not be AREDN-specific), and then send the OpenWRT project a
patch to that effect.
Your existing code in /etc/init.d/local would then trigger to turn the
"add-1" into an "add-65536" to circumvent whatever the OLSR problem was.
2nd option is to make the patch in /etc/init.d/local .
That approach would also work, but I'm less enamored of it because the
former approach fixes the problem for everyone and appears to be what
the manufacturer intended. The existing code in /etc/init.d/local fixes
an AREDN-specific problem, which seems more appropriate to do there.
It appears that this 0003 7f11 23c6 MAC is the same on all the
devices, and the firmware needs to do something to ensure uniqueness
across devices.
Agreed. Do you think a randomly generated address or the deterministic
approach above gives a lower probability of collision? Should we create
a Locally Administered address, which will never overlap one that the
manufacturer produced?
- Paul
- PaulMessage ID: ***@***.***>
|
|
'turn the "add-1" into an "add-65536"' "randomly generated address or the deterministic This 3rd octet + 1 technique is what Ubiquiti uses on their MAC address assignments, and I had repeated this pattern here. I've not done the math on this, but one reason to continue to use this technique, is that it makes it easier when troubleshooting network issues. It is easier to remember the IP addresses for a node when dtdlink and RF addresses are similar with this increment: 10.1.2.1 becomes 10.1.3.1, and easy to spot that both belong to the same node. We've not seen any collisions with this approach to day -- knock on wood -- so I believe it is good or low risk enough to continue using. It narrows down the collision to this assigned OUI MAC range of the vendor. "a Locally Administered address" Also, after looking into a random technique, and would also apply to manually setting, I realized a negative of this approach. The use case for this is evasive behavior to circumvent MAC blocks to join networks -- hooked in to randomize at each boot. ...not really the spirit to enable or support in our community. We're motivated to not lower the hurdle to modify the MAC addresses. But maybe there are other use cases to consider? |
|
Brand new AR300M (no external antennas) and the relevant MAC is also 00:03:7f:11:23:c6. I'm okay with using the mac as the explicit key to solve this problem. I'm uncomfortable generalizing it as we don't know what that might do. Worse case is it doesn't fix older devices, but they're not fixed now anyway. I'm also okay with reusing the current mac generation code as we know that's in use and hasn't cause any problems. |
I was trying to move me Tunnel Server and Tunnel Client to separate GL-AR300M devices to separate them from my active RF routers.
I found that the two delvices had the same MAC address on the br-lan and eth1 lan configs therefore causing problems with my switch.
Software 3.22.6.0 loaded but it also did not work on 3.22.1.0
The text was updated successfully, but these errors were encountered: