What's new

Request for a menu API in RMerlin firmware?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Bamsefar

Senior Member
I guess this question or request has been up before, so if it has then I am fine with it.

However what I suggest is a very simple hook into RMerlin software that does only one thing and one thing only: Let a user add a custom entry to RMerlin firmware, and that custom entry can only be in one version, a command line interface.

Take the Skynet plugin:
https://www.snbforums.com/threads/s...mic-malware-country-manual-ip-blocking.16798/
It does not have a menu, it has only command line interface like the "firewall import <URL>" command.

Then we have the AdBlock plugin:
https://www.snbforums.com/threads/release-ab-solution-3-8-the-ad-blocking-solution-3-8-1.37511/
It has a menu driven interface, however I guess that developer could easily convert to command line (or it may already be that good?).

Both represent a very nice plugin solution, gives a lot to the user, and only needs like a rather simple wget to download and then install.

It would be great if such "full solution" (yea that might sound wrong) plugins had an option to get "hooked" into the RMerlin firmware by a standard solution so that no extra (after initial development of course) effort during new releases?
 
I can't think of any way to do so without breaking backward compatibility with Asus's own code - it was never designed to be easily extendable unfortunately.
 
As much as I would like to include AB-Solution into the WebUI, it only makes sense if it also can be controlled from it.
What @kvic managed with the NTP daemon is impressive visually but functionally very limited. All you can do is refresh. AFAIK this only refreshes the page with new data from the storage location.
But no other functionality is given.

If I understand correctly, the Asus code restricts certain operations to directly go to the shell. Without it, any attempt at giving AB a GUI is useless in my opinion.
A UI just as eye candy is not worth my time, although offers have reached my inbox to create one in another way (and I thank them for their ideas and efforts).
I have given the kvic method (it was not quick, pardon the pun) a shot and deemed it not worth spending more time on it.
 
I can't think of any way to do so without breaking backward compatibility with Asus's own code - it was never designed to be easily extendable unfortunately.

Sorry to ask this then: How did you manage to extend the WEB GUI for your own extension?
 
Sorry to ask this then: How did you manage to extend the WEB GUI for your own extension?

By modifying the source code. Modifying various arrays, inserting a bunch of Javascript code... It's not something that can be made "pluggable", it requires changing existing code.
 
Or at least the software center same as those Asus-Merlin Chinese mods


Sent from my iPhone using Tapatalk
 
I would gently encourage folks to go and look at the code directly, and you'll find that it's, for lack of a better word, complicated enough... if not scary.

Would be nice to move to a framework like bootstrap (or similar), but that is non-trivial as that would need a lot of backend work as well.

What these frameworks do offer though, might be worth the effort - as theming, language, and responsive layout are the upsides - the pfSense team, as well as OpenWRT, have made the jump, but with a lot of effort to get there.
 
Would be nice to move to a framework like bootstrap (or similar), but that is non-trivial as that would need a lot of backend work as well.

A framework like bootstrap is overkill and bloated for a router webui. Routers don't need a whole framework for that kind of stuff.

Advanced Tomato went that route, and the result is hit-or-miss depending on who you ask about it.
 
A framework like bootstrap is overkill and bloated for a router webui. Routers don't need a whole framework for that kind of stuff.

Advanced Tomato went that route, and the result is hit-or-miss depending on who you ask about it.

I was using bootstrap as an example - not saying that it should be the framework used - there are lighter weight frameworks out there... and most of them are REST/JSON, which not only allows for local config via some local http server, but also from remote in a safe and secure manner.

(FWIW - I've used REST/JSON with node.js on a single core ARMv6 with 512MB of RAM, and it works just fine, even with a light duty httpd, in my case is was nginx)

Anyways - 2007 was a long time ago, and things have progressed quite a bit since then.

In any event, going back to OP's observation - within the current AsusWRT, making changes isn't really at an API level, it's a discrete change/changes within the actual content itself - there's no really easy way to do what's asked here.
 
In 382, Asus is at least moving away from those horrible arrays that are next to impossible to manage, to separate JS "templates" for the menus. It won't make things really more pluggable, but at least it might be easier to manage, and patching one of these files with a custom one would be less likely to cause issues than patching the current mammoth state.js file.

I might backport that change to 380, if only to make things easier for myself.
 
I think I need to modify my approach a bit. I had a bit of thinking, and well sorry english is not my first language, and I might have chosed the wrong words and that might have give you all the wrong idea for what I am after. Anyway I'll give this another go, and then let's see the reaction:

Let's say that we get ONE more tab on the "Tools" part. Let's for this example call this new Tab "Plug-In", and place it after the "Sysinfo" and "Other Settings".
On this page, the "Plug-In" tab, we have two drop downs, a free text input field and a "submit" button.
The first dropdown is the selection of the Plug-In one would like to control, for this example we have "AdBlock" and "Skynet".
The second dropdown is the comman you like to send to the plug-in, say you are after statistics and in for example "Skynet" that is "stats".
In this example the free text field is not needed, but if could be a url for the "Skynet" command "import".
Then one press "submit" (I got to find a better word for this - Execute?).
In a rather large window below the dropdowns/free text input field/"submit" button, one will see the result from the command, and one might scroll or what is needed.

Something like the above might be a better explanation of what I had in my mind when I wrote the OP.
 
The first dropdown is the selection of the Plug-In one would like to control, for this example we have "AdBlock" and "Skynet".
That would mean that the web interface would have to be modified for specific plugins that are not controlled by Merlin. I don't see this as a practical use of Merlin's time from a maintenance perspective and it would also be a security risk IMHO.
 
That would mean that the web interface would have to be modified for specific plugins that are not controlled by Merlin. I don't see this as a practical use of Merlin's time from a maintenance perspective and it would also be a security risk IMHO.
And it would need direct shell access as the admin user. There is a security reason why the built in shell was removed in the WebUI years ago by Asus.
 
That would mean that the web interface would have to be modified for specific plugins that are not controlled by Merlin. I don't see this as a practical use of Merlin's time from a maintenance perspective and it would also be a security risk IMHO.

No to that.
 
And it would need direct shell access as the admin user. There is a security reason why the built in shell was removed in the WebUI years ago by Asus.

And there are ways around that for security reason of course.

I can not think I am the only one who thinks of this kind of solution. Maybe I have to do it myself to verify my idea - however I am not that good on HTML, ASP and JS - well I might give it a go just for the fun of it, to check if I am wrong.
 
And there are ways around that for security reason of course.

I can not think I am the only one who thinks of this kind of solution. Maybe I have to do it myself to verify my idea - however I am not that good on HTML, ASP and JS - well I might give it a go just for the fun of it, to check if I am wrong.
As one of the preferred apps in this list, I would have to code and provide these functions first.
Then Merlin woud have to include it in the firmware or figure out a way to add it via a user script.
 
If you've never looked at it before, I can guarantee you that one look at Asuswrt's webui code will give you nightmares for a few nights.
 
If you've never looked at it before, I can guarantee you that one look at Asuswrt's webui code will give you nightmares for a few nights.

Indeed...

It is complicated and a bit brittle - I can imagine the headaches their QA team has with each release.

Been there - mobile phone code base with 15 years of change behind it, including a core CPU arch change (intel to ARM) and various DSP changes - about a year after I left, they basically started over, and were better off for it.
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top