What's new

Beta Asuswrt-Merlin 386.1 Beta (stage 2) is now available

  • 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.
@RMerlin -- looking around sources for various routers to check on temp issues many are discussing. One thing I note is relatively recent alterations to kernel configs:

CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SLAB_LEAK=y

That makes mem allocs pretty busy. Not saying it's all of it, but for beta release I can see that -- RC or final release I'd think those are off.

Maybe something to look at -- I'd build things immediately but haven't dug into the build process for the routers yet. Probably will since I've let off the kernel/rom dev for Android devices.
 
Bite the B4 build on my AC86U ... so far working fine, no big difference from stock-ASUS 386 firmware.:D

Too bad ASUS change the "Time Schedule" GUI which I am so disappointed. :mad:
 
Holy Smokeronies!

So here's what the attached capture shows for my Comcast 200/5 connection (usually provisioned a bit above that):

15:58 - test with beta3
18:04 - test with beta4 (Yikes!)
18:16 - test with beta4 (after powering-off router, rebooting modem, powering-on router)

View attachment 29289
I had the same result on my AX88U, rebooting it solved the speed issue, but after a little while the slow WiFi client transfer problem returned again. Withdrawing from all Trend Micro services solved it for me. Running the router now for 4h without Trend stuff and it still 185Mbit with Cake-QoS and all other scripts as per my sig.
 
I had the same result on my AX88U, rebooting it solved the speed issue, but after a little while the slow WiFi client transfer problem returned again. Withdrawing from all Trend Micro services solved it for me. Running the router now for 4h without Trend stuff and it still 185Mbit with Cake-QoS and all other scripts as per my sig.
Thanks. I'm not running any Trend Micro stuff. I'll see if any dramatic changes to my speeds occur over the next few days.
 
i have no throughput issues on my ax88 with b4 and trend micro off / no qos
i have symmetric 1Gbps and on my PC i get about 800Mbps wireless
 
Not worried about the temps -- not earth shattering temps and they're quite stable.

As for Traffic Analyzer -- works fine. The scale is dynamic and the chart faithfully scales to the maximum bandwidth currently within the time frame of the chart. When larger values pass off the left of the chart (out of time scope), it faithfully re-scales properly. So if you have a large spike and generally otherwise low, flat bandwidth utilization, it will scale to that large spike and make the low values seemingly uselessly displayed. That's the nature of the beast, imho. I'd suggest refreshing the page if spikes or the like are making things less than visually optimal -- to me the system is doing precisely what is intended (and correctly so).

As for QoS -- I don't do QoS via the interface at all. All traffic shaping (when I do that) is via tc/filters and ip(6)tables rate limiting. That always works. To date, I've never used the UI for such configurations.

Hi tdhite,
about temps, 15/20 degrees higher could be a problem for me because now is winter here and i have 80 degrees and the temp will surely rise next summer, going dangerously near to the CPU shutdown temp. Moreover I really don't understand the reason of this difference, now I'm on stock 386.40451 and the router is up and running since twelve hours (very intense usage) and the temperature has never rised above 64 degrees.

For Traffic Analyzer, in my case the scale goes up to 2100 Mbps, it seems a bit too much, the nominal speed of my connection is 1 Gbps (1024 Mbps), so it's definitely a bug, not a question of auto-scaling.

For QoS, I understand your choice, that is certainly reliable. However I don't understand why the QoS bandwidth monitor is perfectly working in stock 386.40451 and doesn't work at all in the beta GPLs.

Maybe Asus will fix all these issues in the next GPLs or stock releases, we'll see. I hope they will do it to switch to Merlin's firmware again.

Thank you.

Bye.
 
Upgrade to RT-AC86U beta 4 - perfect - all working - had to manually enable cpu wait states.
1. Was able to get rid of
Code:
protocol 0800 is buggy, dev eth5
log spam by using Guest Network 2 instead of Guest Network 1.

2. Was able to get rid of
Code:
kernel: tntfs error (device sdb2, pid 31314): ntfs_prepare_pages_for_non_resident_write(): Failed (error 5).
log spam by using health scanner on the USB Drive and running this twice to get rid of errors.

Upgrade to AC5300 Beta 4 AIMesh node - perfect
 
Last edited:
AX86U - dirty upgrade from beta2 to beta4.
OpenVPN client and server (site 2 site), SMB/NAS, Diversion, Skynet.
Uneventful upgrade a couple of hours ago and everything runs smoothly so far
Thanks!
 
@RMerlin I can't seem to locate mtd-write2, do you have a handy way to flash back to beta3 from ssh for RT-AX88U users to bypass gui restrictions?

The only way is through firmware recovery or a tftp client.
 
I'll remove the RT-AX88U beta 4 image. I can't even flash an updated build on top of it right now, it fails some more validation that I can't determine. More shenanigan from Asus in their model/version validation possibly. Getting so tired of dealing with this...
RMerlin,
The problem existed in RC2-10 Firmware 9.0.0.4_386_41535-g1caa24a that I have reported in the other thread. The workaround is to use Asus Firmware Restoration Tool to upload the desired Firmware. I am quite please with the RT-AX88U 386.1_beta4; as I turn OFF AiProtection and no Guest Network 1 Wifi.

 
@RMerlin -- looking around sources for various routers to check on temp issues many are discussing. One thing I note is relatively recent alterations to kernel configs:

CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SLAB_LEAK=y

That makes mem allocs pretty busy. Not saying it's all of it, but for beta release I can see that -- RC or final release I'd think those are off.

Maybe something to look at -- I'd build things immediately but haven't dug into the build process for the routers yet. Probably will since I've let off the kernel/rom dev for Android devices.

I generally cannot change these kernel options, as it would conflict with the other pre-compiled bits provided by Asus.
 
RMerlin,
The problem existed in RC2-10 Firmware 9.0.0.4_386_41535-g1caa24a that I have reported in the other thread. The workaround is to use Asus Firmware Restoration Tool to upload the desired Firmware. I am quite please with the RT-AX88U 386.1_beta4; as I turn OFF AiProtection and no Guest Network 1 Wifi.


I am sure he is already aware as it's been discussed here and on that ASUS thread a few times already. ;)
He still made the right call to remove it, as you shouldn't need to use special utilities to upgrade/downgrade the firmware. Especially for someone without prior knowledge.
 
The problem existed in RC2-10 Firmware 9.0.0.4_386_41535-g1caa24a that I have reported in the other thread.

So that means Asus broke the firmware validation code, and it's not a merge error on my end. I know it's not an image header issue since previous firmware images or the same image will fail to flash. Flashing through the webui fails reporting a CRC mismatch between the file and the image, and flashing through the command line fails because it reports a mismatched OTP configuration. Which makes it even weirder, two totally different error messages when flashing from two different tools. Even weirder is that little has changed in the AX88U SDK, beside the wifi SoC firmware itself (which had finally resolved video streaming issues here).

I guess we're looking at a few more weeks of debugging until I can finally get 386.1 finalized. At this point maybe I should just pull a Brainslayer, and give up on pushing out "final" releases, and just push a constant stream of betas...
 
I have just rolled back to Beta 3 on the AX88U no problem but keeping all the QoS & trend micro stuff off until we get a update on this
 
C
- USB HID problem
lsmod:
usbhid 28470 0
hid 103941 1 usbhid
usbcore 166604 22 sbhid,uas,usb_storage,cdc_mbim,qmi_wwan,cdc_wdm,cdc_ncm,rndis_host,cdc_ether,ax88179_178a,asix,cdc_acm,usbnet,
ohci_pci,ohci_platform,ohci_hcd,ehci_pci,ehci_platform,ehci_hcd,xhci_pci,xhci_plat_hcd,xhci_hcd
usb_common 2813 1 usbcore

dmesg:
usb 4-1: new low-speed USB device number 2 using ohci-platform
lsusb:
Bus 004 Device 002: ID 051d:0002

The apcupsd do not see my ups.
/proc/bus/usb does not exist

Not wanting to hi-jack this thread. I use the AC86U and never had any luck with getting apcupsd to communicate with my UPS. I think it had more to do with the UPS than Merlin (Cyber Power - have read that they don't talk apcupsd by business choice). I switched to NUT and have had no problems with NUT.

One thing, I also had to load the input-core.ko module to get NUT to work. On the AC86U, that module was hiding at /lib/modules/4.1.27/kernel/drivers/input/input-core.ko.

We can always take this to another thread if you want to give NUT for a spin.
 
Flashing Asus's official release (Version 3.0.0.4.384.9579) from Oct last year and reflashing with Beta 3 also works.

That is really... weird. Validation bug that only affects 386.xx firmware images maybe? I'd have to test flashing 384.19... Still doesn't explain why two different flashing methods fail, unless somewhere they share some of the code.
 
Status
Not open for further replies.

Sign Up For SNBForums Daily Digest

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