#88 New MAC not showing after reboot, or setting it

Open
opened 4 months ago by iheartlibrecmc · 4 comments

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!

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!
RISCI_ATOM commented 4 months ago
Collaborator

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.
iheartlibrecmc commented 4 months ago
Poster

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!

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!
RISCI_ATOM commented 4 months ago
Collaborator

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?
iheartlibrecmc commented 4 months ago
Poster

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.
Sign in to join this conversation.
Loading...
Cancel
Save
There is no content yet.