Development musings

[guitargeek]

I wish I knew how to read the firmware and help out I sure would, really have appreciated your Firmware over the years. You're the reason I own a Asus router, best firmware for what I need. When I purchase a new Asus router, the first thing I do is update it to Merlin!!!

If there is anything a newb can do to help more let me know. I do want to help you help us.

Thanks,

Joe

A couple of things I've been thinking about these past few months, and which could (potentially) help:

Having someone take over support & development for the two MIPS routers (RT-N66U and RT-AC66U). These models (especially the N66U) are far too popular to completely drop support for, however having someone take care of maintaining the MIPS side of things would free up some of my time. No more hunts for MIPS-specific GPLs (for the MIPS binary blobs), two less routers to test.

Extending development cycles. I've already started on this, extending from the former one month cycle (where I was generally alternating between feature releases and bugfix releases) into a longer 2-3 months cycle, with occasional beta (and even alpha) builds. This did help in getting some issues spotted earlier during development, thanks to a few users willing to run even alpha level code, and providing really good feedback. I will most likely continue in this direction.

Re-enabling the issue tracker on Github. I disabled it a few years ago because the vast majority of new issues were really support requests rather than genuine bug reports, and it was becoming a good amount of work sorting through my mailbox notifications. I might be considering re-opening it once again.

Getting a more reliable access to new GPLs. That one isn't under my control unfortunately, but issues like the 2695/2697 corrupted and/or missing GPL drops do cost me a lot of time and efforts.

Enforcing a strict "if you don't mention your router model then your bug report will be ignored" policy. This isn't about being a jerk to people, just that I often waste a lot of time trying to reproduce an issue, only to learn later on that it only happens on a very specific model. Take the RT-AC87U for instance, which accounts for a lot of "My 5 GHz no longer works" reports. Maybe setup (at least informally) some type of template of info that MUST be included whenever reporting any issue. Router model and whether or not it can be reproduce on the stock firmware would be good starting points.

More eyeballs on the code on the debugging front. So far, I've noticed that most people actively contributing are more interested in feature addition/improvements than actual debugging of existing issues. Once again, not something I have any control over. The learning curve isn't necessarily easy for anyone's first attempt at diving into this jungle. There are large parts of the code where I simply don't step foot myself, like the Dual WAN code, or any of the non-router operation modes...


Once again, just thinking out loud here.

 

[dvohwinkel]

Sorry for derailing the original thread anyway, I was just thinking out loud last night, after spending a lot of time trying to merge the newest OpenVPN release (Asus's status/error report code wasn't compatible with it, and had to be re-engineered).

I'm glad you decided to do some "thinking out loud". It's interesting to hear what goes on behind the scenes and some of what burns you out. I bought my RT-68U partly because of your awesome firmware.. so many thanks.

 

[jrmwvu04]

Enforcing a strict "if you don't mention your router model then your bug report will be ignored" policy.

I would do that, like, yesterday. People would adjust quickly.

 

[tsunami2311]

I never even used Asus original fw on my router I went straight to RMerlin FW, I still say this the best router I have is I had in long time, even if it showing minor it limitations at this point, It been more stable and better performing then any router i had.

And when I get new router which will still be ASUS I will probably still be using RMelin FW

 

[RMerlin]

There's one thing some of you might be able to help me with.

It's been on my ToDo list for a few months already, and no programming knowledge is necessary I'd like to move all the README-merlin.txt documentation into the Wiki (as separate pages for each section). Some of it is already there (such as the custom script stuff), but I was thinking about the rest of the documentation, such as the policy-based routing, IPTraffic, etc...

Any volunteers? All you need to get started is a Github account - the wiki is editable to anyone with an account. Wiki editing/formatting is fairly easy to learn.

If more than one of you is doing it, just make sure to coordinate yourselves so you don't do the same work separately.

 

[jeff288]

There's one thing some of you might be able to help me with.

It's been on my ToDo list for a few months already, and no programming knowledge is necessary I'd like to move all the README-merlin.txt documentation into the Wiki (as separate pages for each section). Some of it is already there (such as the custom script stuff), but I was thinking about the rest of the documentation, such as the policy-based routing, IPTraffic, etc...

Any volunteers? All you need to get started is a Github account - the wiki is editable to anyone with an account. Wiki editing/formatting is fairly easy to learn.

If more than one of you is doing it, just make sure to coordinate yourselves so you don't do the same work separately.

I'll be busy for the next few days but if there's no volunteers after that, I'd be glad.

 

[sfx2000]

Not in the short term, but I will need to find a way to change some things. Right now, this has gone from a fun hobby into a chore.

I think you've done much - enabling the community effort with the GitHub repo... I've jumped into it more than a couple of times to dig into the gubbins of AsusWRT to sort issues.

That, by itself, is a fair amount of work - more than some are willing to do.

 

[sfx2000]

Increasingly complex: Yes
Increasingly buggy: no...

Modern day "Buggy" perception is coming from people, who weren't there 30 years ago, where code was simpler, but still had more bugs per line of code than it has today. Who wants "quality" of Win95, where you had to boot your PC several times every day? My 80-year old mother was not there at the time (no PC). Today she complains "all software is buggy" when it takes a little too long to connect something.

Modern day users just won't put up with yesterday's "quality" any more ...

Any code base will get more and more complicated as time goes on - and as more contribute to it - even in the localized context if it's based on upstream code.

the challenge with AsusWRT, and RMerlin has walked a fine line - it's a very complex project, with DNA that goes all the way back to the WRT54G Linux builds - and a lot of private upstream code that isn't documented.

If you count WRT54G, we're looking at 10 plus years of code at least - some of it is over 20 years old... and there are sections inside that nobody knows what it does, or why, but they know enough not to touch it as it might break things in a very unexpected way - that's what happens when you have a build that can cram into 8MB of flash...

The codebase is incredibly brittle at this stage - and we see the results with the 380 branch on the 'legacy' devices - some of that code is easy to work with, but some of it, basically touch it and die - from a dev standpoint is knowing what code just not to fsck with...

 

[sfx2000]

This reminds me of Red Hat and their distros - there's actually more that RHEL and Fedora..

RHEL makes managers easy - stable
Fedora - cutting edge, many sysadmins and enthusiasts run it
Rawhide - developers only need to apply - Rawhide is littered with tattered rainbows, unicorn tears and half-eaten babies - it's the tip of the /development trunk...

Gotta love *nix - it assumes you know what you're doing - blow away a running filesystem - ok, it'll let you...

Live life to the fullest - run as root...

Don't need to ask the wife - sudo make me a sandwich - just make...

 

[kvic]

Don't need to ask the wife - sudo make me a sandwich - just make...

Siri would be your potential affair..lol

 

[Haggster]

I'd say less frequent releases, but the occasional alpha for testers sounds good.

And maybe waiting for an acceptable GPL that could finally be used as the basis for an LTE release might really be a good idea. The question is just what the chances are, if there hasn't been a suitable one over the last two years.

 

[punkinduster]

RMerlin:
I did some cut and paste from one of the read me text files into Wiki. If you think I did it correctly I could find the time to do some more.

 

[jrmwvu04]

Any volunteers? All you need to get started is a Github account - the wiki is editable to anyone with an account. Wiki editing/formatting is fairly easy to learn.

That seems within my means. If I can help, just tell me what to do.

 

[majnu]

IF Merlin stops f/w support for Asus routers then I wont buy another Asus router and will go for Billion. Sort your shirt out Asus!

 

[Deleted member 22229]

Having someone take over support & development for the two MIPS routers (RT-N66U and RT-AC66U). These models (especially the N66U) are far too popular to completely drop support for, however having someone take care of maintaining the MIPS side of things would free up some of my time. No more hunts for MIPS-specific GPLs (for the MIPS binary blobs), two less routers to test.

John is the perfect person for this job. That is if he would except it lot of work involved. Asus,Merlin and John are the only firmwares i trust and have no issues flashing.

 

[RMerlin]

RMerlin:
I did some cut and paste from one of the read me text files into Wiki. If you think I did it correctly I could find the time to do some more.

That's a really good start, thanks! I will do a pass over them once you're done to clean up / update a few things. For instance, the traffic monitoring is now officially called IPTraffic, to distinguish it from all the other monitoring methods available. Pages like the CROND one would also better benefit from a more accurate name (Scheduling tasks through cron), with perhaps basic usage of the cru utility.

The idea is to move the documentation to the Wiki so it can more easily be enhanced and detailed by the rest of the community, versus the current README that is more static and only kept up-to-date by myself.

 

[mstombs]

You have had a great run RMerlin, please don't leave us, would be great if you become the Linus of asuswrt-merlin, only pulling well formed security and upgrade patches into the official merlin git from a team of model specific developers. Perhaps you could focus on just the one you want to use personally? But this team of developers doesn't yet exist - you have done too great a job! How about documenting some of the magic you do - I assume some multi-way diff when Asus drop new GPL (i.e. 3.0.0.4.380.3264), you have to compare what they have changed vs their previous version and your own? There are 1000s of files to review - it will take years for others to catch up! Thinking out loud - could we put Asus GPL in a public git so we can easily see what they change without doing diffs on GB of expanded tarball locally?

Personally I do not know of any bug on N66U with 380.59, but see Asus claim some security updates in their latest, but I'm not touching their new lockdown firmware with a bargepole...

 

[kvic]

@RMerlin

CONFIG_CTF_PPTP_L2TP=y is no longer required in 380.59 and afterwards for RT-AC56/68/87

https://github.com/RMerl/asuswrt-me....4708/linux/linux-2.6.36/config_base.6a#L1921

 

[RMerlin]

@RMerlin

CONFIG_CTF_PPTP_L2TP=y is no longer required in 380.59 and afterwards for RT-AC56/68/87

https://github.com/RMerl/asuswrt-me....4708/linux/linux-2.6.36/config_base.6a#L1921

That's correct. I started removing it but haven't gone through all different kernel trees yet to remove any leftover.

 

[spalife]

That's a really good start, thanks! I will do a pass over them once you're done to clean up / update a few things. For instance, the traffic monitoring is now officially called IPTraffic, to distinguish it from all the other monitoring methods available. Pages like the CROND one would also better benefit from a more accurate name (Scheduling tasks through cron), with perhaps basic usage of the cru utility.

The idea is to move the documentation to the Wiki so it can more easily be enhanced and detailed by the rest of the community, versus the current README that is more static and only kept up-to-date by myself.

Thanks again for your time and effort.

Recently upgraded to 380.59 on N66U without any issues.

Getting ASUS certification of your builds would be nice.

Just a thought, most or some of us have some technical background.

Perhaps if you post trivial activities which take up your time and have not been
able to attend to them as individual jobs, people who have time can take it up
and lighten your burden and also gives us a sense of contribution to the project.