State of the project - 2016 in review

[Agrajag]

Any ideas on getting to the bottom of it?

 

[DaveMishSr]

Any ideas on getting to the bottom of it?

Restoring the factory defaults will clear your nvram.

 

[ASadani]

With all honesty and sincerity
If there was not the Merlin firmware, I would have never bought an Asus router.
I bought an Asus router just because there is Merlin firmware.
Thank You.

Totally well said. The ASUS router only made sense because merlin's fork exists. Some functionalities are critically required specially for the ones that need VPN's running correctly.

Merlin. We really appreciate your work and in my friend purview I have at least 12 of us for who I've configured all AC5300's and everyone just loves it. Can't comment on actual usage but everyone who is in a restrictive unit and who requires vpn's will be looking out for your version of the firmware.

Clearly ddwrt can also achieve the same but looses the native experience and not to mention, the endless list of bugs ranging from dhcp loss, wan loss, hangup's, lack of vlan's. It does not come close to the combined solution you have built.

Now the only negative thing I can say is that if you compare the aesthetics of Asus vs. Netgear, Netgear wins hands down vs. the clawed scorpio.

 

[thelonelycoder]

Reading this comment by RMerlin in which he states:

(...)
I'm getting fed up with this closed source non-sense. Two new features appeared in a recent 382 GPL, and both of these are also closed source now.

Quick listing of stuff that is now closed source in 382 (beside the obvious BWDPI/Tuxera/Broadcom stuff):

- Networkmap
- OpenVPN
- JFFS backup
- Let's Encrypt
- httpd's MIME handler
- rc notification functions
- Notification Center
- AiCloud sync clients (FTP/dropbox/etc...)
- Printer server
- Protection Service

This is going to ultimately kill this project.

With that it's becoming increasingly clear ASUSWRT-Merlin is coming to an end at a point in the near future.

I can't express how sad this makes me and likely all the other script writers and members that contribute to this project in any way.
One would think that ASUS is at least interested in releasing the source to a select few to drive development into the future and profit from the open source community as they have in the past.
But no, closing this very mutually beneficial avenue in the 382 branch will leave them with fewer and fewer enthusiasts and silent promoters in the future.

I guess, an LTS version of the 380 branch is out of the question in the long run for you @RMerlin?

 

[RMerlin]

I guess, an LTS version of the 380 branch is out of the question in the long run for you @RMerlin?

I haven't taken any decision yet. It will depend a lot on Asus' own move. If they keep the currently supported models on the 380 branch, then I can keep going as it is right now, with the added burden of dealing with missing/incompatible binary blobs. If they move some models to 382, then I will have to see at that time at what stability level the final 380 code is. Right now, I'm not happy with a few things in 380 (broken Traditional QoS, still unreliable Dual WAN). Those are beyond my ability to fix myself, so if Asus doesn't fix these before they abandon 380. then I'll have to take that into consideration.

And Asus might still surprise me. I've been getting mixed signals from them this last year, so I'm not sure where they stand. One moment they seem to ignore my emails, and out of the blue I would get an Email from them where they do mention looking into finding ways to better cooperate with the third party development base (among other things).

Bottom line, if I end up having to go down a LTS route, that would mean a different project. Remember that the original goal of this project was to enhance the stock firmware, and staying in-sync with it. If I go out of sync, it becomes a different project.

 

[thelonelycoder]

As it happens @RMerlin , I'm working on the Dual WAN feature script and have it at a 99% reliability now, I think.

 

[Naftali Oziel]

I haven't taken any decision yet. It will depend a lot on Asus' own move. If they keep the currently supported models on the 380 branch, then I can keep going as it is right now, with the added burden of dealing with missing/incompatible binary blobs. If they move some models to 382, then I will have to see at that time at what stability level the final 380 code is. Right now, I'm not happy with a few things in 380 (broken Traditional QoS, still unreliable Dual WAN). Those are beyond my ability to fix myself, so if Asus doesn't fix these before they abandon 380. then I'll have to take that into consideration.

And Asus might still surprise me. I've been getting mixed signals from them this last year, so I'm not sure where they stand. One moment they seem to ignore my emails, and out of the blue I would get an Email from them where they do mention looking into finding ways to better cooperate with the third party development base (among other things).

Bottom line, if I end up having to go down a LTS route, that would mean a different project. Remember that the original goal of this project was to enhance the stock firmware, and staying in-sync with it. If I go out of sync, it becomes a different project.

I guess the day you retire is the day I switch to Synology WiFi

 

[ASadani]

I believe ASUS would not close out all the doors specially for a few such as Merlin. It would not be in their best interest. If the source would get closed, then there would be absolutely no reason to buy the asus over say Netgear. All my life I've been an Avid netgear user and have never purchased anything besides netgears. i have the x10 in my closet sitting gathering dust primarily because the asus works perfectly with all my needs thanks to merlin. the vpn is perfect. the signals are perfect. (thanks to someone else though here)

If the code were to get closed, it would still be better if a branch with the opened binaries continue to live its life. ddwrt is a total mess. Too much of un-stability and lack of support.

The main issue I have with ddwrt is the speed of VPN's. When connected, the speed would start off very well but over time say a few hours, it would dwindle down to 4-5 mbps at most and would require a restart. With merlin/asus. that is not the case. it stays right where it started.

@rmelin. there are lots who won't compliment but depend on your work. Wish you all the best my friend.

 

[ASadani]

Any chance to see the GT-AC5300 supported soon? The stock firmware has an interface that may appeal to gamers but that is difficult on the eyes, and buggy (updates to manual DHCP list do not get saved half of the time, plus are limited to 64). If not for the 8 ports and possibility to get Merlin later, it would go back to the shop asap...

Currently what benefit do you see with the GT vs the regular AC5300. Do the ports really matter, you could get a switch if additional slots are needed. I was on the fence of buying the GT-AC5300 when a friend of mine took my regular AC 5300 away as he needed the same setup. I saw an opportunity to upgrade to the GT version then and realized the lack of support of merlin and the bugs, I decided to get the regular AC5300 back again. The UI is fine. the stability is perfect. If I were you, I'd return the GT vs. waiting for merlin to support it. because its not sure he would do it anytime soon.

Moreover if there aren't any features of merlin you like besides cosmetics then there is no harm waiting. but for me and a few of us, we need the vpn and few modifications.

 

[sfx2000]

Bottom line, if I end up having to go down a LTS route, that would mean a different project. Remember that the original goal of this project was to enhance the stock firmware, and staying in-sync with it. If I go out of sync, it becomes a different project.

Then maybe it should...

Food for thought - as many know, I had a project over the fall/winter of 2016 - even with GPL, we contributed back upstream for issues/bugs/performance enhancements. Working directly with the SoC vendor, many might have filtered downstream - Some did, some did not - dependent on the SoC vendor.

With AsusWRT - it's even a bigger problem - as Asus is in the middle - they have to balance upstream across many SoC vendors and still deliver a product for production.

It might be time to consider locking down a version as LTS - limiting scope to a few devices, and then just make them the best they can be for the community - bug fixes, security, some feature enhancements within the scope of the release from Asus.

Just saying...

 

[OGroteKoning]

I am very late to the party, but want to thank Merlin for this firmware. I am a novice user and have to find my info through Google more often than not since I just don't have the ability like most people on here. When solutions pop up, Merlin has taken care of it in his firmware as opposed to the stock Asus firmware. I still rock a RT-N66u and thank you from the bottom of my bit that you still support it with your firmware.

 

[RMerlin]

See https://www.snbforums.com/threads/asuswrt-merlin-project-update.41065/ for an update. Unsticking this thread now.