What's new

[384.18_Alpha Builds] Testing all variants

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

Search for RMerlin post where he explains the status of GPL releases and the headaches it is causing.

RT-AC88U will be released when it is released. :)
 
Also my vacuum refuses to connect on 2.4G on the latest but reverting fixes the issue
Danged snooty vacuums!
I'm sorry, but when I read this, I almost spewed coffee through my nose. I've been here for a while and have never seen a vacuum complaint before.
 
Danged snooty vacuums!
I'm sorry, but when I read this, I almost spewed coffee through my nose. I've been here for a while and have never seen a vacuum complaint before.
Yea that really sucks I imagine. :D (Ok i'll see my way out now....)
 
Just to make sure it's clear: these are not the problem. The code availability situation is.



Asus isn't going to change their business-driven workflow just to accommodate one single third party developer. The current situation isn't because they are doing something wrong, it's just because the way they are working doesn't align with my own workflow (with a fixed development cycle, followed by a single release covering all models at once). This has caused me to extend my dev cycle from 1 month to 2 months, and now I would have to either extend it even further, or completely change my workflow. Such a revised workflow could be to do like them, and move into a more continuous development cycle, where I release a handful of models whenever these models are available regardless of which models can't be updated at that time. This carries however a few issues:

- Critical security updates would be a nightmare to handle, as not all models would be on the same codebase, being staggered all over my code history
- Currently a release requires roughly an entire evening of my time:
o Build and package all firmware images
o Upload to both download sites
o Update the manifest on the update server
o Update my website
o Write and publish release notes to SNBForums
o Announce the release to Twitter
o Monitor for any major breakage being reported in the first 1-2 hours


That release process would have to be somehow greatly simplified for it to be realistically doable more frequently than just every 1-2 months, as it's time consuming, and not something I'd be willing to repeat every few weeks.

This sounds to me as if @RMerlin needs help. May I make a suggestion for group/community consideration?
Sir- if your workflow doesn't align with the presumed Asus workflows, is it possibly time for team efforts on the firmwares? There are enough people around from what I can tell who have the coding chops, so why not fight workgroups with workgroups? Team ac86-Merlin AND Team axYY-Merlin, for instance? I'd like to see compensation for devs in these teams with patreon subscriptions required of downloaders, more for vision and support than coding. This way each team is focused on it's own dev/release cycle. Everyone can still go back to their own scripts/projects as necessary or when time permits, but focus on the firmware...then adjust the bonus features...or maybe get ahead of them because you're aware of what's happening at the firmware level? maybe it's just me, but I sense a critical mass or quantum leap event in the offing...something big is going to change somehow, and my suspicion is lone wolves will have to form packs. since there is already an informal one here, why not figure out the codification of a formal one? I'd rather not have this project come to a complete halt because of death by a thousand updates...and that's possibly what might be happening on Asus' end. They can cope because they have teams and income. we have potential here - it's time to unify it all
My point - this has grown. These are growing pains. things must be done differently as a result. my suggestions are worth the paper they're circulated on, but maybe some neurons this passes through might agree and get some group clarity happening so the work can continue to progress and get done.
 
Just noticed a watchdog reset in my log:
Code:
May 30 04:22:50 kernel: wl0: PSM microcode watchdog fired at 66822 (seconds). Resetting.
May 30 04:22:50 kernel: wl0: reason = psm watchdog at 66822 seconds. corerev 130.1 ucode revision 1518.123 features 0xaaaa
 
Maybe it's time for u to draw a line in the sand and stop development on the troubling models.

Today, the problematic models are the RT-AX56U, RT-AX58U and RT-AX88U as the latest AX88U code is not compatible with the two others... So, that's not going to help. The RT-AC87U and RT-AC3200 are already parked on the sideline, so they currently are not a problem.

The latest plan for these two is, once I can get an updated wireless driver for the RT-AC3200 that fixes Kr00k to issue one last release for these two models, and drop them. The RT-AC87U is already taken care, because unlike the RT-AC3200, its GPL has been released...
 
@RMerlin thanks for giving us a glimpse into your development nightmare. I knew you were at the mercy of Asus releasing gpl, but didn’t know it was such a moving target. Not wanting to poke the bear here but the 9107 gpl for the 88u, is that something you have tentatively planned for .19? Or would the lowest common denominator between your 3 supported ax models dictate which gets pushed during your release cycle? I don’t really care about all the ofdma/qos/fluff just more interested in any cve’s they patch and “enhanced connection stability” whatever those mean. Thanks for all your hard work.
 
I hadn't seen that script.

Probably will be useful but I'm not sure if I would use a VM or not yet, in time yes, but not initially.

Ian

FYI I created a Ubuntu VM in Windows 10 using Oracle VM VirtualBox and installed the amcfwm script. Works beautifully.
 
RT-AC88U, RT-AC3100 and RT-AC5300 started encrypting the httpd password with recent Asus releases. 384.18 incorporates this code, so reverting any of these three models to a previous version will require either logging in using a SSH key (if you had one set) to reset your password, or doing a factory default reset.

The notice was written for the Changelog, but it got lost in branch merges. As I said, the changelog itself is also "under development".
how do i get the 5300 to factory default ? Sorry but i forgot how to do it without being ale to log into thr router.
thank you
forget it holding wps and turning on does not work going to buy a new router , don't have the mental capacity after 2 strokes and 3 siezures , i give up , at least i'm keeing asus in business
 
Last edited:
how do i get the 5300 to factory default ? Sorry but i forgot how to do it without being ale to log into thr router.
thank you
forget it holding wps and turning on does not work going to buy a new router , don't have the mental capacity after 2 strokes and 3 siezures , i give up , at least i'm keeing asus in business
Hold the WPS button and turn on the router and hold until the lights give you an indication something has changed usually a reboot happens.
 
Noob question: I'm on 384.16 beta 2 right now. If I wanna update do I need to do it manually or can I do it from the web interface like with regular firmware?
 
Hold the WPS button and turn on the router and hold until the lights give you an indication something has changed usually a reboot happens.
tried it nothing happens
 
Has anyone intimate with the code taken a look at the GPL of ASUS RT-AX88U for firmware 3.0.0.4.384.9107 release? I'm wondering if it has the newer QOS category enhancements....
 
Has anyone intimate with the code taken a look at the GPL of ASUS RT-AX88U for firmware 3.0.0.4.384.9107 release? I'm wondering if it has the newer QOS category enhancements....
Those are usually in the signature updates.
 
I imagine that they would need to make changes to the engine to support additional categories. No?
 
Try reading this post.
thanks tried it still the same does not reboot just turns on , everthing works , just cannot log into router . tried recovery tool tatwas a no go as well. think i'll buy the rt92u at least it is tri band , but no merlin, oh well can't have it all
 
is that something you have tentatively planned for .19?

I haven't planned that far ahead yet. I don't know what will be available by the time I begin working on 384.19.

forget it holding wps and turning on does not work going to buy a new router , don't have the mental capacity after 2 strokes and 3 siezures , i give up , at least i'm keeing asus in business

No need to buy a new router. Just let the router boot, and once it's booted and you can reach the login page, press the reset button for about 5 seconds, then release it.

I imagine that they would need to make changes to the engine to support additional categories. No?

They're not even new categories at the engine level. One is just the VoIP category that got renamed, the other contains two traffic classes that already existed as part of other (more appropriate) categories.
 
Thanks for the clarification. I guess ASUS oversold it a bit two releases ago (Version 3.0.0.4.384.8018). Thanks again.
 

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