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!

reset button was broken , forgot that it's been years since i last used it opened the router and reset it , now it is working i got the mini web server reset and it works , sory for the trouble , the doctors are surprisedi stillknow my name so many brain injuries through the years , i forget things often , like the broken reset button .
thanks guys all is working again . still might buy that ax92u

No problem. Some of us are aware of your health condition, and will do our best to be patient when trying to help you, no need to apologize. You will just have to excuse those who aren't aware of.

In my professional life, I deal with people with various disabilities. One of my customer is an organization that support people with physical disabilities - wheelchairs, motor/speach issues, and so on. Another one is an organism who helps support blind people. So, I am well aware that if someone is struggling with something, it's not necessarily because they are stupid or incompetent. Potential physical and mental limitations have to be considered.

I can't see any evidence that the fourth category is really the new Default.

It was confirmed to me when I asked Vanic about some of the recent QoS changes to make sure I was getting things right when adapting the QOS Stats page. I might need to re-check that I am picking the correct one on the stats page (it's tricky due to how I access and provide the information to the web page itself).

I think some of that info can be seen from the /tmp/bwdpi/qos.conf config file.
 
ASUS IS STill the best keeping old models updated , i've had other brands that stop getting updated after 6 months .

Yes, but it does come at a cost: it means a lot more work is required whenever releasing updates.

I remember when the Heartbleed issue occurred, Asus had to update and release firmwares for a bit over 20 models at the same time.
 
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...

I guess then this is the end (RT-AC87U)! Thanks for supporting it all this time and thanks for the last firmware to fix Kr00k.
 
Because there's no updated GPL available yet, and the last GPL release for it is not compatible with the code used for all other models.



No, 384_81846 is accurate. It's the most up to date GPL I received from Asus for that model.

View attachment 23784



Game Boost is totally useless.



Show me the 81902 source code.

Does this mean AC68U includes the CVE-2019-15126 (Kr00k) vulnerability fix in Version 3.0.0.4.385.20253 ?
 
Using the last alpha I have a message (every 30 seconds) refer to the CUSTOM DDNS in the log:
Jun 1 23:14:14 watchdog: start ddns.
Jun 1 23:14:14 rc_service: watchdog 1270:notify_rc start_ddns
Jun 1 23:14:14 custom_script: Running /jffs/scripts/service-event (args: start ddns)
Jun 1 23:14:14 start_ddns: update CUSTOM , wan_unit 0

@RMerlin I'm quite sure was not present in previous alpha
 
Does this mean AC68U includes the CVE-2019-15126 (Kr00k) vulnerability fix in Version 3.0.0.4.385.20253 ?

Yep! As far as CVE's are concerned, the firmware releases are cumulative. So 385.20490 will contain the CVE vulnerability fixes of previous releases (while hopefully not introducing new ones ;))..
 
So does problematic translate into a potentiality shorter or quicker chance of support being dropped for the ax88u? The only reason I ask or am concerned is because I just bought an ax88u and would like to have support for it as long as the ac3200 i had before it. Obviously I am referring to Merlin software support not Asus. I hope I didnt make a bad decision on buying a ax88u - so far i love it but if Merlin support dies it will be disappointing.
 
So does problematic translate into a potentiality shorter or quicker chance of support being dropped for the ax88u? The only reason I ask or am concerned is because I just bought an ax88u and would like to have support for it as long as the ac3200 i had before it. Obviously I am referring to Merlin software support not Asus. I hope I didnt make a bad decision on buying a ax88u - so far i love it but if Merlin support dies it will be disappointing.
Merlin support is dependent on Asus support, it will be around for a long time yet since the unit is quite recent.
 
An Asus router minus Merlin is unthinkable now.

If Merlin was no longer available, I would have to become conversant with pihole I guess, to get the adblocking, Unbound +++o_O

(Would give a wider choice of router suppliers though?)
 
Does this mean AC68U includes the CVE-2019-15126 (Kr00k) vulnerability fix in Version 3.0.0.4.385.20253 ?

Yes, because I merged the binary blobs from 385_20490.

@RMerlin I'm quite sure was not present in previous alpha

There was no change to the watchdog code. This indicates whatever frequency you had set for DDNS automatic updates has been reached.

So does problematic translate into a potentiality shorter or quicker chance of support being dropped for the ax88u?

Dropping RT-AX88U support is out of the question at this time, as it's one of the newest models. Simply that, right now, I can't compile the firmware for both the RT-AX88U and the two other models. Once I merge the newer RT-AX88U code, if I don't have updated code for the other two models, then that release will be missing these two models.

This is the problem I was referring to in my posts - I am currently unable to compile all models off the same code base, and I need to figure out how to deal with that.
 
Dropping RT-AX88U support is out of the question at this time, as it's one of the newest models. Simply that, right now, I can't compile the firmware for both the RT-AX88U and the two other models. Once I merge the newer RT-AX88U code, if I don't have updated code for the other two models, then that release will be missing these two models.

This is the problem I was referring to in my posts - I am currently unable to compile all models off the same code base, and I need to figure out how to deal with that.

Right, and I suspect the lack of newer code is causing what I'm seeing with the alpha (and previous release), tried again last night.
My AX88U can't sync on 5GHz to ZenWifi XT8 AiMesh nodes, they drop to 2.4GHz and sometimes flip back and forth between the two bands.

But I didn't check the stock AX88U firmware, I guess I need to do that first ...

I wonder, how could I check out the diffs, IOW what's your process there and where do ASUS post the GPL code (sorry I'm a bit lazy)?
And didn't you say you found there were still some missing binary shared objects (or kernel modules) from the ASUS GPL code posted?

Ian
 
This is the problem I was referring to in my posts - I am currently unable to compile all models off the same code base, and I need to figure out how to deal with that.

That's a bit of a big problem.

It seems the only way around it (right now) would be a separate branch for a specific model or models.
But you say it won't build anyway and even if you could get it to build in a separate branch that would lead to lots more work too.
Difficult problem to be sure.
 
...

I wonder, how could I check out the diffs, IOW what's your process there and where do ASUS post the GPL code (sorry I'm a bit lazy)?

...

I normally don't give people a hard time, but without researching these questions yourself first you're seriously asking these questions to the person who puts an unimaginable amount of hours into these custom firmware? I know its hard to search this site effectively because of the minimum four letter word limit in searches, but the answer to your third question is actually answered already in this thread.
 
I wonder, how could I check out the diffs, IOW what's your process there and where do ASUS post the GPL code (sorry I'm a bit lazy)?

GPLs are publicly posted on their support site under the Others OS category. They also upload them on my personal FTP server, so sometimes I get different releases from the website.

Diffing the release won't help you in your case, AiMesh is closed source, so all there is are binary objects.
 
I know its hard to search this site effectively because of the minimum four letter word limit in searches, but the answer to your third question is actually answered already in this thread.

You can use Google to search the forums, it will be far more useful than the built-in search feature.

Code:
site:snbforums.com keywords to search
 
...
The situation is currently a complete mess, and a major headache for me. Here's how it's currently looking, as of today:

https://docs.google.com/spreadsheet...Xq4I0i6lQo-RN48SGFSkKNKq8/edit#gid=2007755387
....
Quite frankly, I can't keep going on like this. .... Some GPLs take 1-3 months to be available. And by the time they come out, the code available for other models is no longer compatible, meaning it's impossible to have one single release covering all models, unless I wait 2+ months to have everything compatible for all models at hands. Meaning my code would always be months behind Asus's.
....
I need to figure out a way to adjust my development workflow, or this is going to end up in a wall.
...

In my book - you gave the answer to your production workflow problem - highlighted above!
You have FAR exceeded our expectations of you. Since I joined the Merlin journey [some 30 months ago] you have produced no fewer than 27 firmware releases. There were 10 in 2018 / 10 in 2019 and 7 so far this year in 2020 [in 5 months!!!].
In case anyone is puzzled by the stats - check out the linked PDF listing all the releases I am referring to.
https://onedrive.live.com/?cid=56ABA0E3B79458E5&id=56ABA0E3B79458E5!38939&parId=56ABA0E3B79458E5!131&o=OneUp

So - my best tips for you are: -
  1. Set your sights on no more than 4 firmware releases per annum;
  2. Don't push Alpha's into a thread on this forum - rather build a list of volunteer Alpha testers across the model range to assist in early development - and provide test code to them only;
  3. Start forum thread for BETA testing once ready to release a beta test across the covered model range;
  4. Use some of the donated cash to invest in Chill Pills - or Fine Wine ... :D
There really is little need to constantly feed us "update junkies" ;). Rather encourage us to enjoy long periods between reboots on your incredibly stable and add-on feature-enabled firmware!
 
Thanks RMerlin for the clarification. I look forward to a long life for my AX88U now I just hope its hardware dosn't limit its life... ;-)
 
So - my best tips for you are: -
  1. Set your sights on no more than 4 firmware releases per annum;
There really is little need to constantly feed us "update junkies" ;). Rather encourage us to enjoy long periods between reboots on your incredibly stable and add-on feature-enabled firmware!

spacing it out, may make merges harder?
 
ASUS IS STill the best keeping old models updated , i've had other brands that stop getting updated after 6 months .
And this is why I ditched my TP-Link Archer C8 two years ago and bought a refurb 66U-B1 from Newegg. The TP-Link firmware was 2 years old and I perceived the chances of an update were slim to none. The 66U-B1 is the same vintage and I've lost track of how many updates it's had in 2 years. And even though it was a refurb, it hasn't given me a bit of trouble since the day I set it up.
 

Sign Up For SNBForums Daily Digest

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