What's new

Malware damaging ASUS routers?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I did, I've never seen previously in my router channels 149 upwards, I won't use them and call it a day
Sounds good, you might want to also check to see if your regulations have changed so you won't be limiting yourself unnecessarily going forward, if you're now able to legally use them.
 
No they're different slightly now.


You previously stated that you only have those additional channels because you've modified the nvram variables to get them.
That totally slipped my mind. You remember that?
No, this is a different router. Messing with nvram totally screwed the router up.
*edit* I've been back and edited.
 
Well, I don't what Asus did, but my router is now illegal in europe:

View attachment 62747

149 Band is forbidden in UE

Interesting first report! :) Given ASUS firmware, maybe their fix overlooked something. Or maybe your particular router was/is not in its proper market, thanks to globalization or stressed/crossed/corrupt supply chains.

OE
 
Last edited:

Тех9

The problem is solved by 50%
Wi-Fi works
The router is restored from the template in the firmware
A fake MAC address is generated
PIN code 12345670
Region of a non-existent country YY/20
Debug mode is disabled, this is important

I would suggest that all damaged devices be set to the territorial region AA/02 - mainland China, but there is a menu for selecting regions and among them are the USA, Europe and Asia

MAC address should be looked for here
Code:
cat /proc/nvram/BaseMacAddr
cat /proc/environment/ethaddr
cat /sys/class/net/eth*/address
 
Last edited:
At least the routers are in working order now, not e-waste.
Yes, this is a good step towards solving the issue

There are problems, these routers will not work correctly in AiMesh
 
Yes, this is a good step towards solving the issue

There are problems, these routers will not work correctly in AiMesh
I'm not sure if my RT-AX86U ever worked correctly as an AIMesh node. Even though I don't think it ever experienced this issue, it kept going between an AIMesh node and AP based on how it showed up in the main router. Usually in AIMesh, it doesn't show up in the clients list, but as an AP, it does. That's how I knew something was going on. Anyway, I updated it's firmware to the patched release from Nov 28, hard factory reset it with the WPS button, and put it away for a backup in case the BE92U gives me issues, I can set up the RT-AX86U fresh.
 
Was thinking about this - what if the RFCal values were nuked...

How to recover devices in the field?

As you know, the factory records everything, so the median and mean averages for RFCal are known, so one could generate a ballpark set of values to rewrite the RF cal values in the field...

From an FCC and EU-RED perspective - over in unlicensed space, once the radio is certified, there's a fair amount of latitude... obviously if we change something in the radio on a design view, we have to submit a permissive change request (which is usually approved)...
Not sure, but that data should be stored in the WiFi chips no? Most chips can have an OTP, I presumed this data was stored there, so it can't be wiped.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top