State of the project (August 2016)

[Kanuki]

Yep, I bought into this model less than a year ago. I've been plagued with horrible 2.4G performance and limited 5G range - played with Shibby and DDWRT and Merlin firmware and since Merlin's .59 and .61 updates - it really makes this router shine. It finally performs like it should. But I buy my routers for longevity and hope firmware updates and improvements will continue to be available for years to come. Guess I should have stayed with the AC68 for the time being. That being said, I'll keep the 3200 as long as 380.61+ continue to provide the great performance/features it does today. Thanks Merlin!

True..

I had exactly the same problem when I used TomatoUSB with AC3200.

 

[WeirdG]

Phew, dodged a bullet! Bought the AC3200 back in September, but never opened the box. Ended up buying the AC3100 a couple of months ago, and sold the AC3200 BNIB for about the same amount I paid. The AC3100 is great, and works well with Merlin's FW.

Thanks for all the work you do Merlin! It's much appreciated.

 

[sfx2000]

After reviewing my options, I have come to the following conclusions:

1) From now on, Asuswrt-Merlin releases will never be guaranteed to support all models. Support will always depend on what GPL releases are available from Asus.

2) The amount of original development (meaning new features or major changes) on this project will continue to decrease. The current code is diverting too much from Asus's original code, and that code is becoming increasingly complex. Merging new GPL releases is increasingly difficult. Rather than completely fork away from Asus's development, I decided for the time being to stand my ground at the current code state, and focus primarily on just keeping up-to-date with new releases from Asus.

3) Release frequency will continue to be more erratic, as they have been for the past year, unlike in the past where I would typically push out a new release every month. Once again, this will be tied to Asus's own release schedule for the specific models I'm supporting.

4) I might need to drop support for some models earlier than originally anticipated, as I have become too dependent on Asus issuing updates for all of these models at the same time. Less popular models such as the RT-AC56U or the RT-AC3200U might be the first potential victims (especially the latter, as it's the only model running on its own unique SDK version)

I've put some thought into your post - and here's some considerations...

1) A Project usually has a start (need) - a middle (develop iterations for a while) - and an end - which is a deliverable - it doesn't go on forever...

2) Maybe limit the scope of the project moving forward - cut off the older models, not support the newer ones, and focus on the change requests within the popular cohort of devices that support the current branch - mash bugs, consider change requests if possible, but stop running after the upstream bus, esp. one that is ever more restrictive going forward.

Since the RT-AC68U variants are the most common perhaps (poll the community, I'm reasonably sure of that statement) - maybe the approach is lock to a specific release that supports the variants, and make it even better by mashing bugs, selectively adding features - yes, this makes it a fork perhaps, but a fork that has strong roots... and let's one person work on it, refining it, and making a good contribution while still having time for the day-job and real-life stuff...

Trying to keep abreast of 4 SDK's across as many models that RMerlin-AsusWRT is a huge effort, much more than one should expect from one person, even with the occasional contribution of code from others...

I would support a selective reduction of the number of models, and a code-freeze, and increased collaboration there...

 

[RMerlin]

Forking away from Asus was considered, and the idea was dropped, as it would be a major paradigm shift in this project's raison d'être. A fork would make it just yet another third party firmware - the market is already well filled there with DD-WRT, OpenWRT and Tomato. Asuswrt-Merlin fills a totally different niche, which is to keep the benefits of the OEM's improvements, focusing on finetuning rather than on providing a different experience.

Beside, there's already such a fork out there (John's fork), so there's little point in having a second one. People who don't need to take advantage of the latest features from Asus can already move to his fork.

I don't believe there's ever an end to software development, unless the developer quits without anyone taking over for him. It's more like a software project eventually reaches a mature state, where it moves into maintenance mode rather than active development mode. This is why you still see new versions of projects that have existed for many years, like Apache httpd or the Linux kernel.

 

[sfx2000]

Forking away from Asus was considered, and the idea was dropped, as it would be a major paradigm shift in this project's raison d'être. A fork would make it just yet another third party firmware - the market is already well filled there with DD-WRT, OpenWRT and Tomato. Asuswrt-Merlin fills a totally different niche, which is to keep the benefits of the OEM's improvements, focusing on finetuning rather than on providing a different experience.

In many ways - your build, along with John's and HGG's (and a couple of others) are forks already - running in parallel in some cases... you folks have done amazing work, and built communities around it...

Perhaps the path forward is to freeze now - and your contributions (along with those I mention above) would be better put to use with those other builds - DDWRT/OpenWRT would be good targets, and the collective insight would be appreciated there.

And take the community and the collective knowledge you folks have built to these projects that seem to have a longer lifespan moving forward...

I don't believe there's ever an end to software development, unless the developer quits without anyone taking over for him. It's more like a software project eventually reaches a mature state, where it moves into maintenance mode rather than active development mode. This is why you still see new versions of projects that have existed for many years, like Apache httpd or the Linux kernel.

It's a personal choice - but consider what's going on in the upstream - running along side the bus, or finding a cab to take you to another destination.

There is never an end to software - but there is a reasonable end to realizing when a project is pretty much done and there's not much else left to do within one's own control - seems to me that Asus is locking things down and limiting where/when you can contribute directly...

 

[tokyo_networking]

Over the last year, Asus has been moving an increasing amount of code into closed-source binary files, as they seek to prevent end-users (and third party developers) from bypassing existing radio regulations, most particularly those recently put in place by the FCC. While this does allow third party developers to continue their work, it creates a couple of problems, and make my work on this project increasingly difficult.

Eric, thank you very much for all your effort. Your build has been the reason I have bought Asus and recommended it to my friends. Thanks again.

 

[martinr]

Eric, thank you very much for all your effort. Your build has been the reason I have bought Asus and recommended it to my friends. Thanks again.

Wholeheartedly agree.

 

[Deleted member 27741]

The FCC can go pound sand for their useless heavy handed crack down on home router firmware. Another solution looking for a problem. It is funny, they are forcing companies (tp link) to allow third party firmware while at the same time over regulating these tiny little radios.

The FCC needs to drop their regulation of the little guy and force real competition on cable hardware. Internet in the USA is a joke.

Rmerlin is the best thing to happen to Asus in years and I wish they could make life easier for him. But since the FCC insists on wasting time and effort over regulating routers while totally ignoring the big issues with the internet in the USA that does not seem likely.

Do something useful, FCC.

 

[HallStevenson]

If they still officially sell it, they should still officially support it for a while. In the case of the N66U, they still officially sell it even though it's more than four years old but many of us bought it later.

Count me in that group - I just bought an N66, refurbished at that, less than a year ago. Not everyone wants to or can afford to buy the latest and greatest router. I'll bet money, the most popular (not saying "best") routers are the $50 models available at Walmart, Best Buy, etc.

 

[jeff288]

Count me in that group - I just bought an N66, refurbished at that, less than a year ago. Not everyone wants to or can afford to buy the latest and greatest router. I'll bet money, the most popular (not saying "best") routers are the $50 models available at Walmart, Best Buy, etc.

It's not just money for me, it's the rampant consumerism and throwing away of still useful hardware. We have so much e-waste these days and limited resources, I try to use my hardware as long as I can. I praise software projects that can give old hardware a new life.

 

[HallStevenson]

My first wireless router was a Linksys WRT54G. I didn't replace it until I realized it wasn't capable of handling multiple connections (wired or wireless) without freezing/locking up. So, I swapped it for a low-cost Netgear that someone gave me. That router sucked so we went back to the Linksys. Then Time Warner bumped our speed from 10 Mb/s to 15 Mb/s and I noticed we couldn't break 11-12 Mb/s (at least over WiFi). Hooked up the previous Netgear and the first speed test hit 16-17 Mb/s (TW overprovisions by 15-20% by default - my current 50 Mb/s service is provisioned at 64.5 Mb/s) so I knew the Linksys was a bottleneck. I then bought another Netgear, grabbed it on sale for ~$45, and used it for a while before it started acting flaky. It was at that point that I decided I'm done with the 'budget' routers but I also wasn't going to spend $150-200 either. That lead me to the N66 and I'm very pleased with it, no matter how "old" it is.

FWIW, I still have the other (3) routers. Hehe, I still have my Linksys BEFSR41 (wired router) that I bought in October 2000 !

 

[thiggins]

000111: Please stay on topic. This is about RMerlin's project.

 

[Deleted member 27741]

000111: Please stay on topic. This is about RMerlin's project.

I of course mean no offense thiggins- but the FCC is the reason the state of the project has changed. Their new rules threaten Rmerlin and third party router firmware everywhere. How can discussing how the FCC is making life difficult for all firmware engineers, both corporate and third party- be off topic?

 

[thiggins]

I of course mean no offense thiggins- but the FCC is the reason the state of the project has changed. Their new rules threaten Rmerlin and third party router firmware everywhere. How can discussing how the FCC is making life difficult for all firmware engineers, both corporate and third party- be off topic?

By the recent agreement with TP-LINK, the FCC has shown exactly the opposite, even perhaps overstepping their bounds as the regulator of U.S. RF space. They forced TP-LINK to adopt practices that support the installation of third party firmware.

 

[Chrysalis]

John's idea was right which is to stick to specific build and maintain it from there, its been successful.

However I also see the merits of what you did merlin in that you want to make the latest asus features available in your firmware.

So I suggest a compromise. Every 3-6 months you update the GPL your firmware is based on, but you stop following every single asus release, just update every few months instead.

In between you just do bug fixes and feature enhancements. We all know there is never going to be super duper features added, it has to be kept closed to the core asus code, but in the last year or so we have seen some nice micro feature enhancements added such as the vpn routing stuff, enhanced logging, enhanced QoS, and more. I dont know if all these you even added to your firmare or some were just john's but john has said you helped him so even if not in your firmware, you have contributed to those things.

We all know also that you put a lot of care into this, other firmware's I have used like ddwrt and even tomato have bugs that you would think would be noticed by the developer, whilst I dont tend to see anything of that nature in your firmware's, bugs are usually niche hard to spot things if they exist or are asus fault.

So yes I thank you for what you have done, this project is great, and it is perhaps the sole reason why a fair few people brought asus routers in the first place.

I will respect whichever way you go and hopefully you and john continue things for time to come.

 

[RMerlin]

So I suggest a compromise. Every 3-6 months you update the GPL your firmware is based on, but you stop following every single asus release, just update every few months instead.

That would make such merges nearly impossible to do. Smaller incremental merges are much more easier to do and debug than merging 6 months of changes in one single pass. In fact, if it were possible for me to get a monthly new GPL from Asus, it would help.

We all know also that you put a lot of care into this, other firmware's I have used like ddwrt and even tomato have bugs that you would think would be noticed by the developer, whilst I dont tend to see anything of that nature in your firmware's, bugs are usually niche hard to spot things if they exist or are asus fault.

This is actually part of the problem: there's still a lot of bugs and quirks present that I can't fix due to lack of resources, and it's seriously bothering me. Releasing software, and having to frequently answer "Have to wait for Asus to fix this" because the code in question is too complex, closed, or would require a LOT of work just to track down and reproduce. And at the end of the day, since I'm the one releasing the firmware with those known (or soon-to-be-found) issues in there, it's not up to my usual standards of quality when it comes to software.

 

[Deleted member 27741]

By the recent agreement with TP-LINK, the FCC has shown exactly the opposite, even perhaps overstepping their bounds as the regulator of U.S. RF space. They forced TP-LINK to adopt practices that support the installation of third party firmware.

Yes, the FCC is making the creation of router firmware more difficult (and hamstringing its capabilities) both for manufacturers and hobbyists, while also bullying them to include features they themselves have made it hard to support. It is nuts. But you were right, thiggins, my comment and this one are not properly based on the topic at hand (Rmerlin firmware). Although the FCC is partly the cause, discussing their schizophrenic rules is of no help to the topic at hand.

It is serendipitous to a degree that the firmware has mostly matured before things became too difficult for Rmerlin. A maintenance mode at this point will probably be more than satisfactory to most users. Thank you Rmerlin for making ASUS routers worth buying with your fabulous firmware. We are all in debt to you.

 

[sfx2000]

This is actually part of the problem: there's still a lot of bugs and quirks present that I can't fix due to lack of resources, and it's seriously bothering me.

Reduce the scope of the project - can't support 4 different versions of the upstream SDK across so many models...

Perhaps pick a single SDK that is common... or not... support model X, model Y, model Z, based on a common code base... and this turns into rinse/lather/repeat - over and over...

Or walk away - seriously - this is an option - a lot of good lessons learned across many things - SW development, Project Management - and then go do something really, really good...

Software never sleeps - that's a given, but sometimes it best to move on to do better things...

 

[tcool93]

Reduce the scope of the project - can't support 4 different versions of the upstream SDK across so many models...

Perhaps pick a single SDK that is common... or not... support model X, model Y, model Z, based on a common code base... and this turns into rinse/lather/repeat - over and over...

Or walk away - seriously - this is an option - a lot of good lessons learned across many things - SW development, Project Management - and then go do something really, really good...

Software never sleeps - that's a given, but sometimes it best to move on to do better things...

So you telling him to just quit making firmware??? I'm sure many would disagree here. Many here including myself would never have purchased Asus or Netgear had it not been for RMerlins firmware.

As for the other comment in this thread about the FCC forcing TP-Link to accept 3rd party firmware, I see nothing wrong with that at all. In fact I always thought they were required to in the first place due to the open source type firmware. They lose nothing by allowing it.

 

[ColH]

Reduce the scope of the project - can't support 4 different versions of the upstream SDK across so many models...

Perhaps pick a single SDK that is common... or not... support model X, model Y, model Z, based on a common code base... and this turns into rinse/lather/repeat - over and over...

Or walk away - seriously - this is an option - a lot of good lessons learned across many things - SW development, Project Management - and then go do something really, really good...

Software never sleeps - that's a given, but sometimes it best to move on to do better things...

I must say, as a grateful user for quite a number of years, I'm appreciative of the effort that must have been expended getting to this point. Whatever you decide is the future, I'm sure the majority here would support your decision - even if that meant you withdrawing from this software and pursuing other interests.
Thank you for your dedication and support.