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!

Just donated, and if you need any testings or support whatsoever, we’re here to help.

Thank you. I don't want however for people to think this is a request for money. It's not a matter of getting extra financial motivation, it's just a matter of how much work the project is currently requiring versus what I am able or willing to put into.

Just donated, and if you need any testings or support whatsoever, we’re here to help.

This is basically why I occasionally upload these early alpha builds. I don't devote any extra time into preparing/uploading these, I merely upload my own internal test builds when I have them at hand, without spending time into preparing release notes or actively providing support for them. Which is why not all models are available. Compiling all of them takes a bit under two hours now, so I never do it during development, only building specific models that I have made changes to, and therefore require testing.

These early smoke tests allow me to reach the eventual beta stage with builds that are in a more solid state, reducing the amount of work/support that I have to do during that beta cycle.
 
Dirty Flash on RT-AX58u:

-QoS bandwidth limit still dont work: In theory (according to Asus) the 8563 base code solved the QoS limit problem. It still does not work, it does not matter the value that is established in both the download or upload (at least in fq_codel)
-For me, AiProtection is still totally broken, no modules work, is not about logging, simply, dont work
Try a factory reset.
 
I have this strange feeling that Asus is in the process of transitioning form AC units to Ax ones, and they are slowly phasing out the AC devices, this is just my theory in regards to firmware release cycle.

Probably not a precise divide between AC and AX, just the natural evolution based on the age of a model - the older the model is, the less frequent updates it receives. The RT-AC68U is probably the anomaly in there due to the large number of devices they sold (and still do - no newer models is available in the same price range AFAIK).

Asus has an insane number of new models being released in 2019 and 2020. That's a lot of development/support involved. Just off the top of my head:

RT-AX88U
GT-AX11000
GT-AC2900
RT-AX56U
RT-AX58U
RT-AX82U
RT-AX86U
RT-AX89X
Zenfi CT8
Zenfi XT8

And add to that the various non-BCM models which we don't really hear about, but also seem to have been released these past 12 months: newer RT-AC1200 variants, RT-AC85U, RT-AX55, Lyra Voice...

So, I can understand models from 2016-2018 not receiving as frequent or grouped releases any longer.
 
You’re most welcome and its totally understandable and only a stupid would think you’re...in a way asking for donations...

I think this is what you should earn for all your dedication and efforts..goes without saying man.

Yea I understand its about the efforts done with your work, somethings that helped me in such situations is to document fully the process with all its tips & tricks for others to follow when I need, maybe call it the dummy work part? And assign it to people? Maybe others can do you the change log documentations? And be responsible for it? To give you time to focus on the real issues..

Also, i own a WebHosting business, id really like to give you some free space to use whenever/whichever you need, just let me know your needs and I’ll be glad to help.

Thank you. I don't want however for people to think this is a request for money. It's not a matter of getting extra financial motivation, it's just a matter of how much work the project is currently requiring versus what I am able or willing to put into.



This is basically why I occasionally upload these early alpha builds. I don't devote any extra time into preparing/uploading these, I merely upload my own internal test builds when I have them at hand, without spending time into preparing release notes or actively providing support for them. Which is why not all models are available. Compiling all of them takes a bit under two hours now, so I never do it during development, only building specific models that I have made changes to, and therefore require testing.

These early smoke tests allow me to reach the eventual beta stage with builds that are in a more solid state, reducing the amount of work/support that I have to do during that beta cycle.




Sent from my iPhone using Tapatalk Pro
 
Probably not a precise divide between AC and AX, just the natural evolution based on the age of a model - the older the model is, the less frequent updates it receives. The RT-AC68U is probably the anomaly in there due to the large number of devices they sold (and still do - no newer models is available in the same price range AFAIK).

Asus has an insane number of new models being released in 2019 and 2020. That's a lot of development/support involved. Just off the top of my head:

RT-AX88U
GT-AX11000
GT-AC2900
RT-AX56U
RT-AX58U
RT-AX82U
RT-AX86U
RT-AX89X
Zenfi CT8
Zenfi XT8

And add to that the various non-BCM models which we don't really hear about, but also seem to have been released these past 12 months: newer RT-AC1200 variants, RT-AC85U, RT-AX55, Lyra Voice...

So, I can understand models from 2016-2018 not receiving as frequent or grouped releases any longer.
I wonder how new WiFi 6e units are going to affect the GPL release situation, I wonder if Asus is going to start dropping support for more devices?
 
I wonder how new WiFi 6e units are going to affect the GPL release situation, I wonder if Asus is going to start dropping support for more devices?

Based on Tim's assumption (and also hints at a first Wifi 6e model which I saw appear in newer GPL code), looks like there won't be a lot of new Wifi 6E models. It will mostly be limited at the beginning at least to tri-band models (and that one new model that I spotted is indeed an ROG, tri-band SKU).
 
Also, i own a WebHosting business, id really like to give you some free space to use whenever/whichever you need, just let me know your needs and I’ll be glad to help.

Thank you, but I'm good on that front. My hosting costs are minimal, and easily covered by user donations so far. Even my Office 365 account (which provides the Onedrive mirror) is at a deep discount, thanks to a Microsoft employee adding me to his Family And Friend account. And SmallNetBuilder provide what would probably be the most expensive (and time-consuming) service, with these forums.
 
That’s great..keep it in your mind just in case at anytime you’d need it.

Thank you, but I'm good on that front. My hosting costs are minimal, and easily covered by user donations so far. Even my Office 365 account (which provides the Onedrive mirror) is at a deep discount, thanks to a Microsoft employee adding me to his Family And Friend account. And SmallNetBuilder provide what would probably be the most expensive (and time-consuming) service, with these forums.




Sent from my iPhone using Tapatalk Pro
 
Over the years I have asked for people willing to take over maintaining older models like the abandoned models, or the AC87/AC3200 models currently parked on a separate code branch. No one stepped forward.

That is common, yes.

It is very hard to grow a developer base and, given I had similar problems when Linux autofs was under heavy development, I understand how hard it is. In fact I'm still alone in that development so I'm not too good at growing a developer base either.

But also, I understand how difficult it can be coming from the other direction, for example I was thinking I would like to get familiar with wireless device drivers so tried to work on adding support for the Netgear R8000 to OpenWRT (quite a long time ago now). Not only did that not lead to improved familiarity with wireless drivers but I quickly became unsatisfied with the way things worked, or in fact didn't work IMO, in terms of review and merging. Without going into detail, I abandoned that with thoughts along the lines of "I have to put up with this sort of thing for work, I can do without it for things I do with the little spare time I have".

There's also a time issue, if you step up your committed and that can lead to a commitment of time that you may only have some of the time.
I guess this touches on difficulties you have and not only difficulties that others have, familiar with what it really means to step up.

Not only that but even building from the Merlin repo. is difficult when you start out.

I recently set out to try and build Merlin from the repo. and quickly found that it wasn't obvious how to do that given the existing documentation is a bit out of date (and that's not a criticism, more a fact of life) and it wasn't obvious from the repo. source I looked at either.

Personally I would like to help out, but as I say above, unavoidably the time thing is difficult for me and that needs to be understood and respected.
So, count me in if you have things that I could do given my constraints.
I'm no stranger to development, or git, or merging but there's a steep leaning curve with any reasonably sized project.

They don't. They do have multiple branches, however they simply release models off these branches as they are ready. For instance, the RT-AC88U/AC3100/AC5300 are all from the same branch, but they don't release updates them at the same time, hence the different versions as seen in my published spreadsheet.

Yes, I think that model is quite common, I see a similar model in the upstream kernel, Fedora, and RHEL, all work from a single repo. with branches for releases.
Things get forward or backward ported as the need arises.

And I suspect my current separate branches are very similar to their own: 382 (which is currently my 384.13_x branch in terms of models), 384 "main", and 384 "ax". They also appear to have a 385 branch for some models, but from what I've seen the code is identical to 384, just with a different version numbering. And they have the 386 branch, which is their most up-to-date, but so far only used for very few models, like the Zenfi. The DSL-AC68U was the first existing model that I have seen getting moved to it.

Which will eventually be a new headache of its own. I had to go through that in the 380 -> 382 switch, and it was painful. To the point that, at the time, I decided to scrap my code, get a fresh GPL code, and re-implement all of my changes on top of that new GPL.

I don't think there's any way to avoid the pain that this brings but still some division of labor is going to be needed possibly along the lines of how ASUS releases from branches (as do the other large projects I mentioned) rather than the all at once we have with Merlin now.

LOL, I don't see any other way for you to retain you sanity!

As I say, I'm willing to help if you see a place for me to fit in, and I accept that, at least initially, it won't be smooth running, certainly not for me and probably not for you either.

Ian
 
Over the years I have asked for people willing to take over maintaining older models like the abandoned models, or the AC87/AC3200 models currently parked on a separate code branch. No one stepped forward.

Mmm ... unfortunately I've already discarded my AC87U and AC3200, not enough space in my over crowded house to store old routers, needed to make room for new ones, ;)

Ha, I even had fly leads hanging out of the AC87U for serial adapter connection ...
 
Not only that but even building from the Merlin repo. is difficult when you start out.

Anyone wanting to jump in right now is going to be facing an uphill battle. The code has become insanely complex (there are increasing amounts of it which I don't even try to understand any longer), and the messy build system isn't doing much to help either. I am able to deal with it because I started when Asuswrt had a much simpler code base. Almost everything (aside from wireless and filesystem drivers) was open sourced and could be recompiled regardless of the model. @john9527 started at probably the last period where things were reasonably simple - it was right before the amount of closed source code started to explode, just before the addition of the Trend Micro engine. It was already starting to become more complicated with the recent addition of the ARM platform. @GNUton is probably able to manage with his own DSL-AC68U fork because he almost entirely focuses on taking my code, and merging the DSL-AC68U binary components on top of it, without having to deal with actual code changes.

Building in itself should be fairly easy, as long you have all the necessary pre-requesite packages installed. My recent WSL2 Wiki article has an up-to-date list as of May 2020, for Ubuntu 18.04 LTS. Actual model/branches aren't documented because things change too frequently, any documentation quickly becomes obsolete, and I've given up on maintaining Asus's own readme.txt at the root (I will probably eventually remove that file to prevent confusion). The amcfwm script would probably be the best place to look, as well as paying attention as to which branches are available on Git.

The developer ecosystem developed horizontally instead, with people taking advantage of the script interfaces I implemented and documented, to provide additional features through external scripting.
 
Bug triage would probably have been a good place for a new developer to begin. Unfortunately, despite all my efforts, the Github issue tracker has devolved (once again) into a general pile of support requests rather than a genuine bug tracker. I am increasingly ignoring what is being posted there, as too often it's a huge waste of time having to sort through user requests for supports, or people assuming that if their configuration doesn't work as expected, then it has to be because of a bug, not because what they are trying to do is wrong. So, I am getting close once again to completely disable the issue tracker on Github. For every single genuine bug report, there must be around 9 support requests.

Just see what was posted to it while I was writing this post...

openvpn disconnect every 2 or 3days
reboot the router to reconnect
ax88u 384.17

That's not a bug report, that's a generic, awfully vague at that, support request.

One or two persons tried over the past year or so to do some triage. They gave up after a few weeks.
 
Building in itself should be fairly easy, as long you have all the necessary pre-requesite packages installed. My recent WSL2 Wiki article has an up-to-date list as of May 2020, for Ubuntu 18.04 LTS. Actual model/branches aren't documented because things change too frequently, any documentation quickly becomes obsolete, and I've given up on maintaining Asus's own readme.txt at the root (I will probably eventually remove that file to prevent confusion). The amcfwm script would probably be the best place to look, as well as paying attention as to which branches are available on Git.

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.
Being able to build (to start I'll build for the AX88U) I will probably just translate the needed packages (if any are actually missing) to those needed in Fedora.

I'll give that a go and see how I go, being able to do a build is going to be kind off important, ;)
Can't say when, I might spend some time on that tomorrow but I have to get some Fedora autofs updates (for at least three Fedora releases) out before work on Tuesday (Monday public holiday here).

Ian
 
On a lighter note: the current 384.18 (2nd iteration) alpha 1 for AX88U ‘just works’. :)
Not seeing anything untoward here, in my admittedly simple home setup.
 
Just see what was posted to it while I was writing this post...

Ha, some people have front line support to "extract" useful information out of users before escalating to engineering and still it's hard to get what's needed. Support is such a thankless task ...

I see
Code:
openvpn protocol not supported udp6 or tcp6

and not a thing else ... I don't think I've ever seen anything that, well, blank ...

btw, that build script you referred me to is very useful, I was able to generate the AX88U aphha1 build and it is the same size as your posted one (fortunately there were no updates to the repo. yet).

I'm feeling a little guilty now, hijacking this thread, what to do ...
 
Last edited:
Merlin

Maybe it's time for u to draw a line in the sand and stop development on the troubling models. People will bitch and complain but the AX models are the future. If people want to be on the Merlin firmware, they can make an $ on their end with newest models, updates will come faster and be much easier for you to implement. Untimely it would be a win/win all around
 

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