Mac clone random assignment not working Beryl AX

Hi there, I’m getting this error when trying to assign a random MAC address into the Beryl AX (firmware 4.1.3):
“Response error, please check your network”

Screenshot from the Android app, but it’s the same error in the browser interface.

Are you accessing the browser interface from your phone? Can other operations be executed properly on the phone (browser and app)?
If other actions do not work either, please check your connection. Some Android phones automatically use the cellular network when there is no network on WiFi, making it impossible to send commands. Please turn off cellular and try again.

No, it’s the same error from my computer, see attachment. Everything else I’ve tried so far working fine.
ps: I’ve already tried rebooting, no luck.

Can you try to firmware 4.2.0?

Appreciate your fast reply, with this suggestion, thanks.

Before I go ahead, could you confirm it’s possible to follow the same procedure to downgrade back to 4.1.3?

And do you happen to have the change log for this build?

Yes, you can download 4.1.3 firmware file to downgrade back. But downgrading can’t keep your settings. If you need it, please backup settings in LuCI.

You can view release note after you upload firmware file, before you confirm install it.

Sadly the error persists with 4.2.0.

But now I’m confused with the updated UI: What I really want to do is to set a random MAC address on the Repeater interface, so the “hotel” I’m using as Wireless WAN is not aware of my device’s address.

However now the UI only gives me the option to change MAC for Ethernet, which I suspect isn’t what I want to change, right? Nevertheless, trying to change that one triggers the crash.

What do you think?

Is it something to do with the 1st octet in the MAC address, similar to this post? And does a known good MAC address cause the same errors? It looked like the errors went from bad to worse, so its just a suggestion.

I used Browserling's MAC address generator, which can break the rule that the 1st octet of any valid MAC address should be an even number. E.g., 59:0b:25:9b:0c:da was not a valid MAC address.

Some progress: I’ve disconnected the two Lan clients (removed the cable) and did a factory reset (I’m still on v4.2.0).

When it was up and running I went straight to MAC settings and this time it’s allowed me to set a random one!

So I went on and enabled all my settings (not necessarily in this exact order): changed hostname, enabled Adguard , changed wan port to Lan, reconnected Lan cables, connected to WiFi wan host (repeater), changed 2g/5g WiFi name.

Then I’ve tried again to set A MAC ADDRESS and got the error again. At least it seems that the device is now configured with the random address (ps: I’m still unsure the difference between ethernet and repeater addresses).

So it looks like one or more of these settings cause the Mac change feature to break. Perhaps it’s just bad error message, i.e. it should say: “disconnect Lan cable before…” Or “do xyz before…”?

Hope this helps the Gl.inet team trying to replicate and fix the bug.

It provides MAC modifications for Ethernet and repeater, and repeater will follow the Ethernet settings.

Thanks for your feedback. We will check it. I guess it because WAN port to LAN. In this case, it should only modify the MAC of Repeater.

Hi Yuxin, wondering if this is on track to be solved on a future release?

Also, I’d like to suggest 2 feature enhancements connected to this:

  1. Add support for Randomized MAC address for the WWAN repeater port on every connection (i.e. just like Android/iOS, we should be able to e.g. reboot the router every night and get a new address upon wifi reconnection).

  2. Allow change of Repeater MAC address always, even when the WAN port is set to operate as LAN (which is the original issue that triggered this thread).

I do believe they are both crucial for anyone who really has the need for the Randomized MAC use case.

Would you be keen to consider putting these features in the roadmap?

There are plans to redesign MAC address management, and we will discuss this at that time.

We are already working on fixing this bug.