ASUS Merlin based 3.0.0.4.374.979 When ?

[pepeEL]

When will be released soft ASUSWRT Merlin based on the original firmware ASUS 3.0.0.4.374.979? This version show on 9 october ... and it is in download on asus page.

 

[thexile]

When it is ready.

 

[DaveMishSr]

When will be released soft ASUSWRT Merlin based on the original firmware ASUS 3.0.0.4.374.979? This version show on 9 october ... and it is in download on asus page.

I thought that Merlin said the changes from 374.726 and 374.979 were not major. Not really sure if he intends to use 374.979 as a basis for one of his builds. He must be mega-busy with the recent release of the AC68U. I hope he supports it soon. Oh yea, hit him up with a donation if you haven't already.

 

[Sky1111]

I am just guessing here:

- ASUS is working hard to get AC68 major issues resolved so they can release a decent firmware.
- quite possibly it makes sense for Merlin to skip .979 and focus on the upcoming version
- maybe - just maybe - the older routers will benefit from the upcoming version too

It seems to me that ASUS moved to unified firmware for its recent routers (just like graphics cards have unified drivers for different GPUs) - Merlin, am I right?

Or different routers have different firmware packages: same base build + router specific wifi drivers?

P.S. I realized that I am wrong. Different CPU architectures require differently compiled firmware; so perhabs all single core routers use one type of firmware, and all dual core use different version - again, Merlin to comment please

 

[RMerlin]

I am just guessing here:

- ASUS is working hard to get AC68 major issues resolved so they can release a decent firmware.
- quite possibly it makes sense for Merlin to skip .979 and focus on the upcoming version
- maybe - just maybe - the older routers will benefit from the upcoming version too

It seems to me that ASUS moved to unified firmware for its recent routers (just like graphics cards have unified drivers for different GPUs) - Merlin, am I right?

Or different routers have different firmware packages: same base build + router specific wifi drivers?

P.S. I realized that I am wrong. Different CPU architectures require differently compiled firmware; so perhabs all single core routers use one type of firmware, and all dual core use different version - again, Merlin to comment please

Asuswrt is the common codebase used by all their modern routers (and it was also backported to a few older routers, like N16, N56, newer N12D revision, etc...). Within Asuswrt you have different "environment":

src-ra: Ralink-based routers, like RT-N56
src-rt: SDK5-based routers (N16, older N66)
src-rt-6.x: SDK6.30 based routers (N66, AC66)
src-rt-6.x.4708: BCM4708-based routers (AC56, AC68)

While the main code (dnsmasq, web server, etc...) is identical, the differences in these build environment will be wireless driver, which options are enabled, different Linux kernel, etc... When you compile it from within the correct environment directory, the build flags will determine for which router you are compiling. So yes, I have to compile it separately for every router that I support (and I used to have to do it twice, as I also had to recompile with DualWAN/Repeater enabled).


Things are a bit more confuse with BCM4708-based ARM devices since Asus hasn't fully merged it with the other MIPS-based devices. They develop from a parallel code branch (different rp-pppoe version, different build files, different pre-compiled binary blobs not always in parallel to the MIPS ones, etc...). This makes my job quite difficult at this time, since I have on my end successfully merged both branches into one. So I can no longer just merge new GPL releases on top of mine - I have to do it component by component, so not to downgrade some of the components that were upgraded with the parallel branch. I must also move binary blobs to different locations (I separate mips and arm precompiled files, Asus doesn't always do so yet).

I already merged the 979 code on Github days ago. Developers are free to clone the repo and compile firmwares themselves (if they don't mind compiling a work-in-progress). However there is no point in making a new release right now, so I'm waiting for the next FW release from Asus.

Since merging GPL is becoming such a chore, I might no longer update every time a new GPL is released either, and skip some of them. Like I skipped the BCM4708 374_205, but went with the MIPS 374_979 which was only slightly newer. And I'm waiting for the next 374_2xx before making a new release.

GPL 979 brought different challenges too, which were only overcome last night:

- Part of AiCloud is closed source, and they are making major changes to AiCloud. That means I need updated versions for both MIPS and ARM devices - I had to manually extract newer ARM binary blobs from the 374_217 FW to get AiCloud to work with the 979 GPL.

- AiCloud build files in the GPL archive are different from those used by Asus (since part of their code is closed source). In 979 they forgot to update the GPL versions, so AiCloud modules weren't compiling properly. I had to manually fix the build files to make them link against new requirements (curl and lightsql).

In closing: I get the same question asked every time a new GPL is out (when will you release a new version?). I no longer answer these, because it's always the same answer:

- I have no ETA - whenever I'm satisfied with its state
- It depends on when I have the time, since this is a one-man show, done on my spare time beside my day job
- It depends if the new code is stable enough, and what new bugs I must fix
- It depends if the new code is worth the trouble, or if I should wait for the next release
- It depends if the GPL includes ALL the required binary blobs, if the missing blobs can be reused from older firmwares or not


I answered to this one just to clarify the current GPL situation (the presence of the two parallel branches making my work more difficult than it was before).

 

[RMerlin]

For reference: previously, merging a new GPL release was around 2 hours of work. Now, count around 4-5 hours of work, and there is no guarantee it will work if I end up missing some bits.

 

[Sky1111]

thanks for clarification Merlin - and OMG, this is a lot more work than I could image.

How about someone joins you to help? I am not a developer to offer my services, but maybe someone on this forum is qualified enough and can help in a way - for example, you can breakdown the work into tasks and delegate certain task to certain people, but you maintain the leading role and interface ASUS when you need to?

Folks - what do you think?

 

[atkinsom]

Always appreciate your efforts Merlin. Solid firmware and great additional features like entware and transmission.

 

[KAD]

thanks for clarification Merlin - and OMG, this is a lot more work than I could image.

How about someone joins you to help? I am not a developer to offer my services, but maybe someone on this forum is qualified enough and can help in a way - for example, you can breakdown the work into tasks and delegate certain task to certain people, but you maintain the leading role and interface ASUS when you need to?

Folks - what do you think?

it's a good idea for sure, but unfortunately hard to accomplish
I've seen first hand on the irc channels the work the goes on behind the scenes and it really is an amazing amount of work to make this all happen

the difficult part unfortunately, is not finding volunteers, it's finding qualified volunteers

myself included, I help with what I can, but it's barely even a drop in the bucket

Cross compiling firmware is a lot of work, that many developers don't like to get into
and RMerlin does it brilliantly

 

[OGroteKoning]

Always appreciate your efforts Merlin. Solid firmware and great additional features like entware and transmission.

^This

Thanks Merlin for all the hard work!

 

[DaveMishSr]

Asuswrt is the common codebase used by all their modern routers (and it was also backported to a few older routers, like N16, N56, newer N12D revision, etc...). Within Asuswrt you have different "environment":

src-ra: Ralink-based routers, like RT-N56
src-rt: SDK5-based routers (N16, older N66)
src-rt-6.x: SDK6.30 based routers (N66, AC66)
src-rt-6.x.4708: BCM4708-based routers (AC56, AC68)

While the main code (dnsmasq, web server, etc...) is identical, the differences in these build environment will be wireless driver, which options are enabled, different Linux kernel, etc... When you compile it from within the correct environment directory, the build flags will determine for which router you are compiling. So yes, I have to compile it separately for every router that I support (and I used to have to do it twice, as I also had to recompile with DualWAN/Repeater enabled).


Things are a bit more confuse with BCM4708-based ARM devices since Asus hasn't fully merged it with the other MIPS-based devices. They develop from a parallel code branch (different rp-pppoe version, different build files, different pre-compiled binary blobs not always in parallel to the MIPS ones, etc...). This makes my job quite difficult at this time, since I have on my end successfully merged both branches into one. So I can no longer just merge new GPL releases on top of mine - I have to do it component by component, so not to downgrade some of the components that were upgraded with the parallel branch. I must also move binary blobs to different locations (I separate mips and arm precompiled files, Asus doesn't always do so yet).

I already merged the 979 code on Github days ago. Developers are free to clone the repo and compile firmwares themselves (if they don't mind compiling a work-in-progress). However there is no point in making a new release right now, so I'm waiting for the next FW release from Asus.

Since merging GPL is becoming such a chore, I might no longer update every time a new GPL is released either, and skip some of them. Like I skipped the BCM4708 374_205, but went with the MIPS 374_979 which was only slightly newer. And I'm waiting for the next 374_2xx before making a new release.

GPL 979 brought different challenges too, which were only overcome last night:

- Part of AiCloud is closed source, and they are making major changes to AiCloud. That means I need updated versions for both MIPS and ARM devices - I had to manually extract newer ARM binary blobs from the 374_217 FW to get AiCloud to work with the 979 GPL.

- AiCloud build files in the GPL archive are different from those used by Asus (since part of their code is closed source). In 979 they forgot to update the GPL versions, so AiCloud modules weren't compiling properly. I had to manually fix the build files to make them link against new requirements (curl and lightsql).

In closing: I get the same question asked every time a new GPL is out (when will you release a new version?). I no longer answer these, because it's always the same answer:

- I have no ETA - whenever I'm satisfied with its state
- It depends on when I have the time, since this is a one-man show, done on my spare time beside my day job
- It depends if the new code is stable enough, and what new bugs I must fix
- It depends if the new code is worth the trouble, or if I should wait for the next release
- It depends if the GPL includes ALL the required binary blobs, if the missing blobs can be reused from older firmwares or not


I answered to this one just to clarify the current GPL situation (the presence of the two parallel branches making my work more difficult than it was before).

It sounds like the project is starting to outstrip your free time. I am in no way qualified to help but there must be others in this forum who are. Otherwise, feel free to take it easy. Issue a monthly update perhaps or go over to a six week publishing schedule if that helps. People will get over it.

 

[RMerlin]

It sounds like the project is starting to outstrip your free time. I am in no way qualified to help but there must be others in this forum who are. Otherwise, feel free to take it easy. Issue a monthly update perhaps or go over to a six week publishing schedule if that helps. People will get over it.

That's why I no longer try to answer everyone like I used to do, and point a lot of email authors to ask on these forums instead. Thankfully we've built a little community together here where others can take over for generic support questions. This is already a hugely useful contribution from those of you taking the time to answer forum posts - thank you!

I've received a few code contributions recently from other folks on Github. The biggest problem is the steep learning curve involved in understanding the firmware code (just how the webui works isn't really intuitive at all, so even webui level work is a bit difficult).

People interested in contributing should start by keeping an eye on the issue tracker on Github. If they can tackle one of the reported issues there, this is the best place to start. But otherwise, this is the same issue that Tomato devs are facing: finding developers with both the skills and interest in getting involved is difficult.

 

[RMerlin]

great additional features like entware and transmission.

I deserve no credit for these. Entware is pretty much ryzhov_al's project, with TeHashX providing with very detailed guides for Transmission. Even the Entware setup script was actually written by ryzhov_al, after I gave him a rough map of what I'd like such a script to do.

 

[Kobold]

RMerlin

For reference: previously, merging a new GPL release was around 2 hours of work. Now, count around 4-5 hours of work.

OFFTOPIC:
How do you do that? When I try to be in sync with a current ASUS firmware, it usually takes several days or even more to make the merge. Luckily, the 979 has much less altered files than usual

 

[panhead20]

RMerlinHow do you do that? :? When I try to be in sync with a current ASUS firmware, it usually takes several days or even more to make the merge.

WinMerge is your friend
http://winmerge.org/

 

[Sky1111]

I deserve no credit for these. Entware is pretty much ryzhov_al's project, with TeHashX providing with very detailed guides for Transmission. Even the Entware setup script was actually written by ryzhov_al, after I gave him a rough map of what I'd like such a script to do.

AHA! Maybe we convince Ryzhov to engage and work together with Merlin on ASUS firmware?

 

[RMerlin]

AHA! Maybe we convince Ryzhov to engage and work together with Merlin on ASUS firmware?

Have you seen the number of packages he has to maintain in Entware? Doubt he has much time left LOL

 

[RMerlin]

RMerlin


OFFTOPIC:
How do you do that? When I try to be in sync with a current ASUS firmware, it usually takes several days or even more to make the merge. Luckily, the 979 has much less altered files than usual

I do all my development over SSH. I typically have four SSH session open for new GPL merges.

- First session is a

 colordiff -r asuswrt.old.gpl asuswrt.new.gpl

to see where there are changes, as I walk through all the diffs between the old and new GPL.

- Second session, I sit inside my asuswrt-merlin folder, where I can manually issue:

diff -Naur ../asuswrt.old.gpl/release/src/router/folder_I_work_on ../asuswrt.new.gpl/release/src/router/folder_I_work_on | patch -p2 --dry-run

If a dry-run works fine, I do it without the dry-run flag.

- Third and fourth are for conflict management. I open the .rej files in the third one, and manually edit the file in the fourth one

So basically I generate a patch from the diffs between the two GPL, and apply them on top of my own code. There's quite a few manual merges I have to make caused by my own changes (which is one of the reasons why I try to avoid making not totally necessary changes to the Asus code, like dictionnary changes or just code cleanups - they only make merging more difficult).

 

[DaveMishSr]

That's why I no longer try to answer everyone like I used to do, and point a lot of email authors to ask on these forums instead. Thankfully we've built a little community together here where others can take over for generic support questions. This is already a hugely useful contribution from those of you taking the time to answer forum posts - thank you!

I've received a few code contributions recently from other folks on Github. The biggest problem is the steep learning curve involved in understanding the firmware code (just how the webui works isn't really intuitive at all, so even webui level work is a bit difficult).

People interested in contributing should start by keeping an eye on the issue tracker on Github. If they can tackle one of the reported issues there, this is the best place to start. But otherwise, this is the same issue that Tomato devs are facing: finding developers with both the skills and interest in getting involved is difficult.

People have gotten spoiled by the unbelievable level of support that you have provided. That is why I suggested a set publishing schedule. This way you can set up realistically-achievable goals and we get what we have become accustomed to, your fantastic firmware. Shibby and Toastman sometimes go a couple of months between updates. There's no reason you can't back off and work at a sustainable pace going forward. Another suggestion, which will be unpopular for sure, is to drop support for the RT-N16. That router is functioning way over what it was intended to do and is now so old as to not be worth it, time-wise. With the release of the RT-AC68U your time will be better-served supporting that instead. Just sayin'.

 

[RMerlin]

People have gotten spoiled by the unbelievable level of support that you have provided. That is why I suggested a set publishing schedule. This way you can set up realistically-achievable goals and we get what we have become accustomed to, your fantastic firmware. Shibby and Toastman sometimes go a couple of months between updates. There's no reason you can't back off and work at a sustainable pace going forward. Another suggestion, which will be unpopular for sure, is to drop support for the RT-N16. That router is functioning way over what it was intended to do and is now so old as to not be worth it, time-wise. With the release of the RT-AC68U your time will be better-served supporting that instead. Just sayin'.

A set schedule isn't really doable, as I am dependent on Asus's own release schedule.

Supporting the RT-N16 isn't difficult at this stage, since this is mostly an RT-N66U with just 2.4 GHz. It's just one extra "make rt-n16" to issue while building firmwares. I usually dig out the RT-N16 from my drawer only once every few months when someone mentions something specific to the RT-N16, which is fairly rare these days.

The only thing that would have required a lot of work would be to implement OpenVPN support for it despite its limited nvram size - which I opted not to do.