What's new

Release Asuswrt-Merlin 386.12 is now available for AC models

  • 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!

Status
Not open for further replies.
That's what I always observed when I would test stock vs. RMerlin firmware (many, many years ago).

No reason to continue testing for that anymore.
 
Any ideas on when the next GPL from Asus, and consequently, major upgrade of AsusWRT-Merlin is likely to be released?

The other major AC routers, AC68 and AC66_B1, has gotten recent AsusWRT-Official releases, but not AC86U.

I'm not terribly comfortable with the current release. Although not glaringly unstable, I see small signs of instability here and there - with aimesh wireless connections, with lags and unresponsiveness, and so forth, and I'm wondering if it's one time off's, other factors or what.

That's why I'm really hoping for a new release soon so we can reassess the current state of stability and what people might be experiencing or not.
 
Manual DHCP assignment is handled by recognizing the MAC address of the device that you want to have a custom IP address. Many new devices now have a feature that sends a random MAC addrress to the wifi router to limit tracking. This feature is typically enabled by default. Your Apple TV is probably set to provide a random MAC address to the router. The setting can be found in the network settings section of your Apple TV.
Except that it’s the same Apple TV I’ve had for years. And there was no firmware update on that device during the time when the problem began. AND if I reboot my ROUTER (not the Apple TV), then the router will assign it the correct IP. (ALSO, When I simply manually enter the correct IP on the Apple TV — instead of rebooting the router — it doesn’t fix anything.)

ALSO, my router normally assigns private IPs in the 192.168… range, whereas the incorrect IP address being assigned to the Apple TV when it comes out of standby is in the 169.254… range AND it has a diff subnet mask.
 
@heywire, seems like they're trickling them out as they can for stock users and for RMerlin too. But there won't be a 'mass rollout' until all the new/supported routers are on the 3.0.0.6.xxx level firmware base.

And then there are these points too for that now long in the tooth model:



Have you posted about your concerns and/or started a new thread? It may be something RMerlin can fix for 386.12_5... if that is in the works, of course.
 
View attachment 54679

Definitely WiFi issues caused by 386.12_2 and 386.12_4. As you can see rolled back 386.12 has 0 problems.
1702302102367.png

386.12 still going strong, maybe 386.12_2/4 needs full reset in order not to have wifi issues?!?
 
ALSO, my router normally assigns private IPs in the 192.168… range, whereas the incorrect IP address being assigned to the Apple TV when it comes out of standby is in the 169.254… range AND it has a diff subnet mask.
This is slightly different than what was implied in your previous post. You said the Apple TV was getting a "random IP address" which we assumed was in your LAN's 192.168.x.y range. However 169.254.x.y is not a random address. It is a self assigned address that the device gives to itself when it cannot get a reply from a DHCP server. This usually means that the device has no connection to the network (e.g. a cable fault) or the DHCP server is offline.
 
Any ideas on when the next GPL from Asus, and consequently, major upgrade of AsusWRT-Merlin is likely to be released?
Months away. My current focus will be on 388.6.
 
@heywire, seems like they're trickling them out as they can for stock users and for RMerlin too. But there won't be a 'mass rollout' until all the new/supported routers are on the 3.0.0.6.xxx level firmware base.

And then there are these points too for that now long in the tooth model:



Have you posted about your concerns and/or started a new thread? It may be something RMerlin can fix for 386.12_5... if that is in the works, of course.
I'm on a shared Aimesh network with multiple apartments sharing a fibre connection, so I don't have enough control over the devices on the network to do the kind of rigorous testing that would be required to pin down such intermittent issues.

But I have a feeling it could be caused by bittorrent traffic (by other tenants, I don't use bt on this network) overloading the router, thus causing small crashes, just like the thread you linked explained. (but the person in that thread said that putting back his AC86U helped his situation, while I'm on AC86U and have the problem).

I have considered rolling back to 386.11 or something. But that would bring back the Trend Microsystems crashes that 386.12_4 fixed. And there is no new official firmware with the TM fix that I can try out to see if that helps the situation. So I feel I'm kind of cornered here.

So tired of constantly having to worry about this setup, I'm wondering if a solution could be to put the whole Aimesh setup behind a pfsense router (or similar router software) would fix the problem, allowing me to find a stable Asus firmware that could take care of the wifi and leave it at that, not having to constantly worry about various f*ups in every new firmware release, one fix breaking the other. I will do some research.

Dreaming of one day having a stable, worry-free setup without having to fork out hundreds of dollars for a new setup to replace my AC86U w/2 wireless AC68U and 1 wired AC66_B1 setup.
 
Dreaming of one day having a stable, worry-free setup
multiple apartments sharing a fibre connection

There are better hardware choices for your application. You have to replace the AC routers anyway if you want further support. All are facing EoL soon.
 
I'm on a shared Aimesh network with multiple apartments sharing a fibre connection, so I don't have enough control over the devices on the network to do the kind of rigorous testing that would be required to pin down such intermittent issues.

But I have a feeling it could be caused by bittorrent traffic (by other tenants, I don't use bt on this network) overloading the router, thus causing small crashes, just like the thread you linked explained. (but the person in that thread said that putting back his AC86U helped his situation, while I'm on AC86U and have the problem).

I have considered rolling back to 386.11 or something. But that would bring back the Trend Microsystems crashes that 386.12_4 fixed. And there is no new official firmware with the TM fix that I can try out to see if that helps the situation. So I feel I'm kind of cornered here.

So tired of constantly having to worry about this setup, I'm wondering if a solution could be to put the whole Aimesh setup behind a pfsense router (or similar router software) would fix the problem, allowing me to find a stable Asus firmware that could take care of the wifi and leave it at that, not having to constantly worry about various f*ups in every new firmware release, one fix breaking the other. I will do some research.

Dreaming of one day having a stable, worry-free setup without having to fork out hundreds of dollars for a new setup to replace my AC86U w/2 wireless AC68U and 1 wired AC66_B1 setup.
I honestly don't see the need to keep Trend Micro activated, the protections it adds are negligible, i replaced the adaptive qos with Cake which is excellently integrated into the Rmerlin firmware, i play online and download from torrents and my network latency is always perfect , just put 90-95% of the bandwidth and you're good to go.
If you want some extra protection, activate Skynet in combo with Diversion or Adguard, they all work great on my Ac86u on a USB stick with 2gb buffer!
 
Last edited:
just put 90-95% of the bandwidth and you're good to go

Limited by the CPU though, NAT acceleration incompatible. This means up to about 300Mbps ISP with RT-AC86U.

You are good to go on 100/10 xDSL with perhaps real latency benefits and no much speed impact, but someone else may not be.
 
Yes, you're right, i hadn’t considered the speed of the connection, i’m of the opinion that it's not the speed that matters but never let it saturate, with my 100mb i do everything with a thousand devices and the latency is always at a minimum.
 
@heywire, those 3 RT-AC68Us (and varients) are not doing your network any favors.

You may find that a single, well placed, AX class router is more than sufficient to cover the area, and give you a more stable network too.
 
There are better hardware choices for your application. You have to replace the AC routers anyway if you want further support. All are facing EoL soon.
That was sort of my implicit question: If I put them behind a pfsense router with CakeQOS and use the Asus AC routers w/Aimesh for wifi only, I'd by unfaced by any troubles down the stack and not be in need of those security fixes as the pfsense router would act as the gateway to the internet and the EOL Asus routers' security flaws?
 
@heywire, those 3 RT-AC68Us (and varients) are not doing your network any favors.

You may find that a single, well placed, AX class router is more than sufficient to cover the area, and give you a more stable network too.
Unfortunately I have serious doubts that'll be the case.

The AC86U in particular has been shown to even eclipse the AX routers on non-AX clients or 2.4ghz. And there are lots of (mainly) non-AX units in the network.

I do need a repeater for the AC86U anyways, and the AC68U's do the job signal-wise.

The problem is stability. And I think I'll be able to stabilize the wifi network by finding the right FW versions.
 
Where have you seen that 'eclipse'? I've seen the exact opposite, every time.


The AC class routers is my best guess of the instability.

But they can be used dependably for your far, wired capable client devices, in Media Bridge mode.

 
That was sort of my implicit question: If I put them behind a pfsense router with CakeQOS and use the Asus AC routers w/Aimesh for wifi only

We can discuss this in a separate thread. Similar threads are also already available along with equipment ideas and examples. You are going nowhere with your current 10+ years old hardware.
 
So I just went through this crash now, where AT LEAST the Aimesh nodes' clients lost connection.

The only strange thing I can see in the logs is that the logs all of a sudden switch from current date and time to: May 5 07:05:06
Is this simply because the crash is causing the time server to restart?

I put the relevant part of the log from 22:02 onward into ChatGPT4 and asked for any signs of a crash around 22:07 o'clock, and this is what came out:
CHATGPT:

From the logs you shared, there are several interesting points around 22:07 that may indicate a network-related crash or issue:
  1. Deauthentication and Disconnection of Devices: There are multiple logs of deauthentication and disconnection (disassociation) of devices from the network around this time. This could be symptomatic of a network issue causing devices to lose connection.
  2. Signal Strength Indicators (RSSI): Some of the deauthentications mention low RSSI (e.g., rssi:-90). This indicates weak signal strength, which can cause instability in network connections.
  3. Kernel Error Messages: There is a series of kernel log messages starting around 22:04:24. These messages might indicate a low-level problem or crash in the system. For example, lines like kernel: CPU: 1 PID: 27293 Comm: dcd Tainted: P O 4.1.27 #2 and subsequent stack trace information are typical of kernel crashes or critical errors.
  4. Potential Software Issue: The use of the word "Tainted" in the kernel log might suggest an issue with a driver or another part of the software that is either not fully supported or has known issues.
  5. Network Device Activity: Several network devices (like eth5 and eth6) show activity around this time, which might be related to the issue, especially if these devices were involved in the crash or problem.
To determine the exact cause of the crash, it would be helpful to look more closely at the kernel logs just before and after the specified time. Further diagnostics might include checking for known issues with firmware or drivers, signal strength problems in the network, or potential issues with specific devices on the network.
 
Do you think I wrote that myself, just to pull your leg somehow? Yes, I used ChatGPT. Do you have any comment on its findings?
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

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