A) If I set an overwrite MAC address in the advanced settings of Interfaces (e.g. lan), save and apply, then back in Overview I first need to click (re-)connect for it to show (and probably take effect?), and
B) Every time rebooting the router it shows the old MAC again, even if the new one is still saved. (And I have to click (re-)connect again.)
also:
C) Wireless has no similar option: I have to add a new Interfaces device as wireless, and then in advanced settings there set overwrite MAC address?
Reddit users seem to have a similar problem (apparently solved A) and B) with ssh, but it should work as expected/advertised.)
D) Is there a way to permanently flash the new MAC as a workaround?
libreCMC is amazing! Thank you!
A) If I set an _overwrite MAC address_ in the advanced settings of Interfaces (e.g. lan), save and apply, then back in _Overview_ I first need to click (re-)_connect_ for it to show (and probably take effect?), and
B) Every time rebooting the router it shows the old MAC again, even if the new one is still saved. (And I have to click (re-)_connect_ again.)
also:
C) _Wireless_ has no similar option: I have to add a new Interfaces device as wireless, and then in advanced settings there set _overwrite MAC address_?
(All after flashing latest (2019-Apr-01) https://librecmc.org/librecmc/downloads/snapshots/current/main/ar71xx/generic/librecmc-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin (from https://downloads.openwrt.org/releases/18.06.2/targets/ar71xx/generic/openwrt-18.06.2-ar71xx-generic-wndr3800-squashfs-factory.img LuCI) (in case this matters)
[Reddit users](https://old.reddit.com/r/openwrt/comments/9q0ezo/mac_address_spoofing_with_openwrt/) seem to have a similar problem (apparently solved A) and B) with ssh, but it should work as expected/advertised.)
D) Is there a way to permanently flash the new MAC as a workaround?
libreCMC is amazing! Thank you!
I have not been able to replicate the issue in the luci interface. Are you sure a valid replacement mac address was entered and "Save & Apply" was clicked? Was Javascript enabled in your browser? Luci requires Javascript. I have been able to set new mac addresses from the luci web-ui with the changes being immediate and persistent across reboots. My testing was done with a different router and I would need more time to test with a WNDR3800.
I have not been able to replicate the issue in the luci interface. Are you sure a valid replacement mac address was entered and "Save & Apply" was clicked? Was Javascript enabled in your browser? Luci requires Javascript. I have been able to set new mac addresses from the luci web-ui with the changes being immediate and persistent across reboots. My testing was done with a different router and I would need more time to test with a WNDR3800.
The MACs were standard ones (6x2 0-9/A-F, e.g. 01:23:45:67:89:AB), get "Save & Apply"'ed, accepted and displayed in LuCI without complaint, but as described only after clicking (re-)connect. Javascript is enabled, Firefox on Xubuntu.
It would be nice if you (or someone of libreCMC who maintains the WNDR3800) could verify it on an actual device, and also check it from a connected client with arping -f -I $(ip route show match 0/0 | awk '{print $5, $3}') or something, as other users (see reddit) seem to have had the same problem.
Could updating from openwrt cause any problems or doesn't this matter?
Thanks much!
Hi RISCI_ATOM!
The MACs were standard ones (6x2 0-9/A-F, e.g. 01:23:45:67:89:AB), get "Save & Apply"'ed, accepted and displayed in LuCI without complaint, but as described only after clicking (re-)_connect_. Javascript is enabled, Firefox on Xubuntu.
It would be nice if you (or someone of libreCMC who maintains the WNDR3800) could verify it on an actual device, and also check it from a connected client with _arping -f -I $(ip route show match 0/0 | awk '{print $5, $3}')_ or something, as other users ([see reddit](https://old.reddit.com/r/openwrt/comments/9q0ezo/mac_address_spoofing_with_openwrt/)) seem to have had the same problem.
Could updating from openwrt cause any problems or doesn't this matter?
Thanks much!
I have not yet been able to replicate this issue. I did not had any issues setting a mac address from the luci web-ui on the WNDR3800. I tested with both libreCMC v1.4.7 and v1.4.8 using the stock configuration, with the change being persistent between boots. Is there something else that I am missing?
I have not yet been able to replicate this issue. I did not had any issues setting a mac address from the luci web-ui on the WNDR3800. I tested with both libreCMC v1.4.7 and v1.4.8 using the stock configuration, with the change being persistent between boots. Is there something else that I am missing?
I think it's a bug in OpenWrt/libreCMC, and I may have found a temporary fix?
After flashing OpenWrt v18.06.2, and libreCMC v1.4.8, and with factory resetting both, all still gave me the above mentioned problems. Then I started playing around with the MAC's:
not working:
01:23:45:67:89:AB
00:00:00:00:00:00
01:00:00:00:00:00
MAC's starting with uneven numbers? like:
15 17 19 21 23 ... (the one's I've tested)
working:
10:00:00:00:00:00
00:00:00:00:00:01
MAC's starting with even numbers?
14 16 18 20 22 ...
Interesting is: LuCI will accept any MAC, but only the one's actually working will be displayed immediately after "Save & Apply", and will also persist with reboots, but all others will need a click to "connect" first to show up in Interfaces. However, they will not persist reboots (even though they are still saved in Advanced Settings), and will not actually work, as
arping -f -I $(ip route show match 0/0 | awk '{print $5, $3}')
from a connected LAN client tells (it will echo the original MAC, despite LuCI's output).
This should be investigated further, I think; LuCI should either refuse/complain about invalid MAC's, or there shouldn't be any, within random 6x2 0-9/A-F?
OpenWrt 18.06.2 has the same issue, from what I could tell.
I think it's a bug in OpenWrt/libreCMC, and I may have found a temporary fix?
After flashing OpenWrt v18.06.2, and libreCMC v1.4.8, and with factory resetting both, all still gave me the above mentioned problems. Then I started playing around with the MAC's:
**not working:**
01:23:45:67:89:AB
00:00:00:00:00:00
01:00:00:00:00:00
MAC's starting with uneven numbers? like:
15 17 19 21 23 ... (the one's I've tested)
**working:**
10:00:00:00:00:00
00:00:00:00:00:01
MAC's starting with even numbers?
14 16 18 20 22 ...
Interesting is: LuCI will accept any MAC, but only the one's actually working will be displayed immediately after "Save & Apply", and will also persist with reboots, but all others will need a click to _"connect"_ first to show up in Interfaces. However, they will not persist reboots (even though they are still saved in Advanced Settings), and will not actually work, as
_arping -f -I $(ip route show match 0/0 | awk '{print $5, $3}')_
from a connected LAN client tells (it will echo the original MAC, despite LuCI's output).
This should be investigated further, I think; LuCI should either refuse/complain about invalid MAC's, or there shouldn't be any, within random 6x2 0-9/A-F?
OpenWrt 18.06.2 has the same issue, from what I could tell.
Even after I flashed OpenWrt version 18.06.2 and libreCMC version 1.4.8 and reset both to factory settings of snow rider, all of the devices continued to give me the difficulties described above.
Even after I flashed OpenWrt version 18.06.2 and libreCMC version 1.4.8 and reset both to factory settings of [snow rider](https://snowrider3d.com), all of the devices continued to give me the difficulties described above.
It seems you're encountering some issues with MAC address settings on your router running libreCMC. To address A and B, try accessing the router via SSH and manually configuring the MAC address. For C, you're correct; in LuCI, you can create a new wireless interface and set the MAC address in advanced settings. Regarding D, flashing the new MAC permanently may require modifying system files, which can be complex. Ensure compatibility and consider seeking assistance on relevant forums. Excitingly, the list of defining games for 2023 showcases remarkable advancements in gaming technology and immersive experiences.
<p>It seems you're encountering some issues with MAC address settings on your router running libreCMC. To address A and B, try accessing the router via SSH and manually configuring the MAC address. For C, you're correct; in LuCI, you can create a new wireless interface and set the MAC address in advanced settings. Regarding D, flashing the new MAC permanently may require modifying system files, which can be complex. Ensure compatibility and consider seeking assistance on relevant forums. Excitingly, <a href="https://playpc.io/editorial/the-10-games-that-defined-2023/">the list of defining games for 2023</a> showcases remarkable advancements in gaming technology and immersive experiences.<br /><br /><a href="https://dollarextras.com/best-international-etfs-to-invest-in-2023/">10 Best International ETFs To Put Your Money In 2023</a></p>
A) If I set an overwrite MAC address in the advanced settings of Interfaces (e.g. lan), save and apply, then back in Overview I first need to click (re-)connect for it to show (and probably take effect?), and
B) Every time rebooting the router it shows the old MAC again, even if the new one is still saved. (And I have to click (re-)connect again.)
also:
C) Wireless has no similar option: I have to add a new Interfaces device as wireless, and then in advanced settings there set overwrite MAC address?
(All after flashing latest (2019-Apr-01) https://librecmc.org/librecmc/downloads/snapshots/current/main/ar71xx/generic/librecmc-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin (from https://downloads.openwrt.org/releases/18.06.2/targets/ar71xx/generic/openwrt-18.06.2-ar71xx-generic-wndr3800-squashfs-factory.img LuCI) (in case this matters)
Reddit users seem to have a similar problem (apparently solved A) and B) with ssh, but it should work as expected/advertised.)
D) Is there a way to permanently flash the new MAC as a workaround?
libreCMC is amazing! Thank you!
I have not been able to replicate the issue in the luci interface. Are you sure a valid replacement mac address was entered and "Save & Apply" was clicked? Was Javascript enabled in your browser? Luci requires Javascript. I have been able to set new mac addresses from the luci web-ui with the changes being immediate and persistent across reboots. My testing was done with a different router and I would need more time to test with a WNDR3800.
Hi RISCI_ATOM!
The MACs were standard ones (6x2 0-9/A-F, e.g. 01:23:45:67:89:AB), get "Save & Apply"'ed, accepted and displayed in LuCI without complaint, but as described only after clicking (re-)connect. Javascript is enabled, Firefox on Xubuntu.
It would be nice if you (or someone of libreCMC who maintains the WNDR3800) could verify it on an actual device, and also check it from a connected client with arping -f -I $(ip route show match 0/0 | awk '{print $5, $3}') or something, as other users (see reddit) seem to have had the same problem.
Could updating from openwrt cause any problems or doesn't this matter?
Thanks much!
I have not yet been able to replicate this issue. I did not had any issues setting a mac address from the luci web-ui on the WNDR3800. I tested with both libreCMC v1.4.7 and v1.4.8 using the stock configuration, with the change being persistent between boots. Is there something else that I am missing?
I think it's a bug in OpenWrt/libreCMC, and I may have found a temporary fix?
After flashing OpenWrt v18.06.2, and libreCMC v1.4.8, and with factory resetting both, all still gave me the above mentioned problems. Then I started playing around with the MAC's:
not working: 01:23:45:67:89:AB 00:00:00:00:00:00 01:00:00:00:00:00 MAC's starting with uneven numbers? like: 15 17 19 21 23 ... (the one's I've tested)
working: 10:00:00:00:00:00 00:00:00:00:00:01 MAC's starting with even numbers? 14 16 18 20 22 ...
Interesting is: LuCI will accept any MAC, but only the one's actually working will be displayed immediately after "Save & Apply", and will also persist with reboots, but all others will need a click to "connect" first to show up in Interfaces. However, they will not persist reboots (even though they are still saved in Advanced Settings), and will not actually work, as arping -f -I $(ip route show match 0/0 | awk '{print $5, $3}') from a connected LAN client tells (it will echo the original MAC, despite LuCI's output).
This should be investigated further, I think; LuCI should either refuse/complain about invalid MAC's, or there shouldn't be any, within random 6x2 0-9/A-F?
OpenWrt 18.06.2 has the same issue, from what I could tell.
Even after I flashed OpenWrt version 18.06.2 and libreCMC version 1.4.8 and reset both to factory settings of snow rider, all of the devices continued to give me the difficulties described above.
It seems you're encountering some issues with MAC address settings on your router running libreCMC. To address A and B, try accessing the router via SSH and manually configuring the MAC address. For C, you're correct; in LuCI, you can create a new wireless interface and set the MAC address in advanced settings. Regarding D, flashing the new MAC permanently may require modifying system files, which can be complex. Ensure compatibility and consider seeking assistance on relevant forums. Excitingly, the list of defining games for 2023 showcases remarkable advancements in gaming technology and immersive experiences.
10 Best International ETFs To Put Your Money In 2023