[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

[SuperFly74]

If you dropped back to an older version, then yes, you should be able to update via the webgui to Johns latest build. Just make sure to factory reset in between each flash.

EDIT: wait a minute....... if you are flashing in the recovery webserver, then just flash directly to Johns fork. No need to do a middle flash.

You mean just power it OFF and on again ?


Sent from my iPhone using Tapatalk

 

[cybrnook]

Stop, wait a minute....


EDIT: I am confused, what are you doing? 3.0.0.4.380.7744 is damn near the latest build for your router from Asus, no you cannot flash to Johns fork from this build as it is WAY too new.

Just get to the recovery web server, or the recovery tool and flash John's build from there. That's it.

 

[SuperFly74]

Stop, wait a minute....


EDIT: I am confused, what are you doing? 3.0.0.4.380.7744 is damn near the latest build for your router from Asus, no you cannot flash to Johns fork from this build as it is WAY too new.

Just get to the recovery web server, or the recovery tool and flash John's build from there. That's it.

[emoji33] done nothing yet!!! Yes have the new FW from Asus and i want the Fork again. But dont quit get it do you mean flash it trough safari webbrowser or Asus FW restoraton tool

Sent from my iPhone using Tapatalk

 

[ColinTaylor]

@SuperFly74
Look here for an example: https://www.snbforums.com/threads/rt-n66u-stuck-in-recovery-mode.33312/#post-268007

 

[Pierino]

These last few posts.....

 

[SuperFly74]

These last few posts.....

Year ..[emoji849]


Sent from my iPhone using Tapatalk

 

[john9527]

Would like some feedback from the user community...

Based on some feedback, I am considering making a separate code release to support the new rev AC68's and it's brothers and returning the returning the base fork to what it was originally. Fix and function content would remain the same for both. This would do a couple of things....

- Users of the original fork on older AC68's would not be forced to do a factory reset or reformat JFFS to upgrade (although they still could move to the later release with the newer drivers if they so desired).
- Some users have also reported better performance with older client hardware on the older drivers of the original fork. This would keep an upgrade path for them.
- Users that already updated to the new SDK on older hardware, would just continue to use the NewSDK release without the need for another factory reset or JFFS reformat.

Is it worth my effort? Would it make things too confusing?

 

[followmsi]

Would like some feedback from the user community...

Based on some feedback, I am considering making a separate code release to support the new rev AC68's and it's brothers and returning the returning the base fork to what it was originally. Fix and function content would remain the same for both. This would do a couple of things....

- Users of the original fork on older AC68's would not be forced to do a factory reset or reformat JFFS to upgrade (although they still could move to the later release with the newer drivers if they so desired).
- Some users have also reported better performance with older client hardware on the older drivers of the original fork. This would keep an upgrade path for them.
- Users that already updated to the new SDK on older hardware, would just continue to use the NewSDK release without the need for another factory reset or JFFS reformat.

Is it worth my effort? Would it make things too confusing?

Pls do it this way .. pls maintain the 26.x firmware versions too.

Thanks for all your work !

 

[atkinsom]

Hi John,

IMHO I would keep it the way it is right now. I've found the new fork to work quite well with older N and newer AC devices. Of course the definition of older hardware is subjective as my oldest devices are DLINK routers running in bridge mode to connect some older sat boxes. The units are about 8-9 years old. Thanks for all your dedication to this project.

 

[scaramonga]

As above. New fork works extremely well on my AC68U (Rev A1), and better than previous iterations, I would say.

 

[cybrnook]

Year ..[emoji849]


Sent from my iPhone using Tapatalk

Did you ever follow the guide that @ColinTaylor posted? That was even more straight forward than mine.

 

[SuperFly74]

Did you ever follow the guide that @ColinTaylor posted? That was even more straight forward than mine.

Still on Asus org. FW havnet Got the balls 2 do yet.... im gonna frack it up[emoji23]


Sent from my iPhone using Tapatalk

 

[Uncle_Gadget]

Is it worth my effort? Would it make things too confusing?

Actually, it'd probably be my preference to do things this way. The entire point of my using this fork is to have the older more reliable functionality, yet still have the latest security patches and features. As there has been some question of the value (or possibly negative value) in using the new drivers, I've decided to hold off a bit. Were you to make this change, I'd update immediately.

That said, this will likely create more work for you in the long run and I would certainly be respectful of your decision should you decide not to make the change. No matter what you decide, I'll continue to remain a user of your fork. Thanks, again, for all you do for us!

 

[ColinTaylor]

Would like some feedback from the user community...

If it were a simple matter of just having another model of router incorporated into the existing source code with minimal effort I'd say "yes, why not". However, it sounds like you'll have to maintain an entire "parallel" build environment and source code, applying all changes to both. Personally, I would be very reluctant to do such a thing unless I was really certain that there were issues with the new drivers.

I can only comment on my specific setup where I have not noticed any negative effects to the new build. I think only you are in a position to judge whether there has been a noticeable increase in the number of problems reported with the new drivers. Of course you have to balance that against a possible nocebo effect because you have highlighted the use of the new drivers.

Too confusing? Probably not if the instructions are clear. Existing users are probably savvy enough to understand the upgrade/downgrade paths. New users will have just have to choose between "forkV1" or "forkV2".

Perhaps give the new build a little more time before deciding?

 

[jrmwvu04]

Been using v27 on original AC68 with no issues.
I’d just maintain one version if it was me.

 

[RMerlin]

Would like some feedback from the user community...

Based on some feedback, I am considering making a separate code release to support the new rev AC68's and it's brothers and returning the returning the base fork to what it was originally. Fix and function content would remain the same for both. This would do a couple of things....

- Users of the original fork on older AC68's would not be forced to do a factory reset or reformat JFFS to upgrade (although they still could move to the later release with the newer drivers if they so desired).
- Some users have also reported better performance with older client hardware on the older drivers of the original fork. This would keep an upgrade path for them.
- Users that already updated to the new SDK on older hardware, would just continue to use the NewSDK release without the need for another factory reset or JFFS reformat.

Is it worth my effort? Would it make things too confusing?

I haven't looked at how you have things setup, but have you considered keeping one single repo, but creating separate target.mak entries that would use the newer SDK as if it was a different router model? This way, you keep working on only one single repo - at build time the build profile simply chooses which binary blobs to use. Same way we currently have RT-AC66U (SDK6.34), AC68U (SDK6.37), etc...


Just an idea.

 

[john9527]

I haven't looked at how you have things setup, but have you considered keeping one single repo, but creating separate target.mak entries that would use the newer SDK as if it was a different router model? This way, you keep working on only one single repo - at build time the build profile simply chooses which binary blobs to use. Same way we currently have RT-AC66U (SDK6.34), AC68U (SDK6.37), etc...


Just an idea.

Hmmm.....interesting thought. But there are some 'common' modules that I'd need to touch up (init-broadcom.c being the one that immediately comes to mind)

Right now I have things separated into two different branches. It isn't too much trouble to "git format-patch" the common stuff from one branch then apply it to the other. And it kept the original fork branch 'pure' so to speak.

 

[mobileman88]

As above. New fork works extremely well on my AC68U (Rev A1), and better than previous iterations, I would say.

How can I tell which revision I am on? Sorry I am off topic here.

 

[ColinTaylor]

How can I tell which revision I am on? Sorry I am off topic here.

Look on the box label or the back of the router.

 

[mobileman88]

Look on the box label or the back of the router.

Doh! Thanks!