[Preview] Work in Progress

[RMerlin]

Where do you pull the Memory stats from that you display here?

From /proc/meminfo.

asuswrt-merlin.ng/release/src/router/httpd/sysinfo.c at main · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

are these truly MB

Yes. meminfo reports them as kB, and I divide them by 1024 to obtain MB.

 

[Martinski]

... How do you determine that total RAM is actually 1024 MB?

The "MemTotal" value shown by /proc/meminfo is the total amount of physical RAM that is usable by the system *after* subtracting the memory that is permanently reserved by the F/W and kernel code during bootup. The amounts of memory allocated during bootup are usually shown in the boot log.

So if you add up all the reserved memory allocated during bootup and the "MemTotal" amount shown by /proc/meminfo, you should get the total amount of physical RAM.

 

[RMerlin]

The "MemTotal" value shown by /proc/meminfo is the total amount of physical RAM that is usable by the system *after* subtracting the memory that is permanently reserved by the F/W and kernel code during bootup. The amounts of memory allocated during bootup are usually shown in the boot log.

So if you add up all the reserved memory allocated during bootup and the "MemTotal" amount shown by /proc/meminfo, you should get the total amount of physical RAM.

Asus "cheats" there to determine the total amount of memory: they calculate the next power of two based on MemTotal, since it's known that total physical memory will be a power of two.

unsigned long next_power_of_two(unsigned long n) {
        if (n == 0) return 1;
        n--;
        n |= n >> 1;
        n |= n >> 2;
        n |= n >> 4;
        n |= n >> 8;
        n |= n >> 16;
#if ULONG_MAX > 0xFFFFFFFF
        n |= n >> 32;  //for 64-bit unsigned long
#endif
        return n + 1;
}

 

[Martinski]

Asus "cheats" there to determine the total amount of memory: they calculate the next power of two based on MemTotal, since it's known that total physical memory will be a power of two.

unsigned long next_power_of_two(unsigned long n) {
        if (n == 0) return 1;
        n--;
        n |= n >> 1;
        n |= n >> 2;
        n |= n >> 4;
        n |= n >> 8;
        n |= n >> 16;
#if ULONG_MAX > 0xFFFFFFFF
        n |= n >> 32;  //for 64-bit unsigned long
#endif
        return n + 1;
}

Interesting "cheat" LOL!! For all intents and purposes, it should be good enough.

 

[Viktor Jaep]

From /proc/meminfo.

Thanks for this. Gives me something to go on!

The "MemTotal" value shown by /proc/meminfo is the total amount of physical RAM that is usable by the system *after* subtracting the memory that is permanently reserved by the F/W and kernel code during bootup. The amounts of memory allocated during bootup are usually shown in the boot log.

So if you add up all the reserved memory allocated during bootup and the "MemTotal" amount shown by /proc/meminfo, you should get the total amount of physical RAM.

That's great info, @Martinski! Thank you. I'm going to definitely use that power-of-2 hack to determine true physical memory now.

 

[RMerlin]

Slowly but surely getting there. This is roughly a whole week of work there.

$ git log --oneline 2369691168..HEAD
a87515a789 (HEAD -> asuswrt6) webui: update switcher on Other VPN Servers page for UI4
8fae8df06e webui: update Site Survey page for UI4
7689497448 webui: fix Connections Log sort order display.
3d04048293 webui: update PPTP/L2TP VPN client page for UI4
307662aede webui: update WireGuard Client page for UI4
0343b417d3 webui: Update OVPN Client page for UI4
8fc6b27b2a webui: update DNSDirector alignment for UI4
f7f50fb7f3 webui: update VPNDirector page layout for UI4
35bef3270d webui: update table.js (header sort highlight colour) for UI4
271735a1f4 webui: update Connections Log page for UI4
8cbcb2636f webui: update OpenVPN Server page for UI4
4c2e01e11f webui: tweak notes on the Connections Log and DHCP Leases pages
ea11210055 webui: update Wireless Log page for UI4
08d7e84b7b webui: remove show_app_table() listener - we don't display the app link
2071edf4c0 webui: make Sysinfo chart colours configurable, with UI4 support; improve mem table layout
ac29a36961 webui: hide UI4 clock to save some header space
31e59ec264 webui: add Merlin logo to UI4

 

[dave14305]

View attachment 68511

What has 4GB RAM?

 

[Tech9]

Perhaps the new AI thing.

ROG Rapture GT-BE19000AI | Gaming Networking｜ROG - Republic of Gamers｜ROG Global

World’s first AI WiFi 7 tri-band gaming router with 19Gbps speeds, dual 10G + 4×2.5G ports, AI Game Booster, ASUSWRT 6.0, up to 5 VLAN & SSID, and AiProtection.

rog.asus.com

 

[dave14305]

Slowly but surely getting there. This is roughly a whole week of work there.

Unclear where UI4 will show up, but is this likely to be another fragment in the fragmented add-on community for different WebUI requirements per firmware branch/version?

 

[Tech9]

@Martinski, you're hired!

 

[RMerlin]

Unclear where UI4 will show up, but is this likely to be another fragment in the fragmented add-on community for different WebUI requirements per firmware branch/version?

It was expected from the beginning that anything that touched the webui would be susceptible to break at any time. I implemented a basic API back in the day to at least prevent mod authors from constantly patching the existing pages through binding mounts, which would cause issues with every single new firmware releases as people "forgot" they had replaced a web page with a customized one. But breakage will still happen whenever Asus changes the menu rendering engine (the switch to menuTree), changes dependencies on built-in javascripts (the recent client_functions.js changes) or flat out changes the whole UI or switches from a dark to a light theme (the switch to Bootstrap with UI4/Business UI).

Asus themselves took "shortcuts" in UI4 by having Boostrap dynamically replace some CSS values on-the-fly so their original non-Boostrap pages (basically all the Settings pages) would require minimum changes. The frequently used #FFCC00 colour used for notifications for instance is automatically replaced by a shade of blue that's readable on a white background. In-page text set to white is also automatically switched to that same blue colour. But if you got creative and used your own colour that's not readable on a white background, you have to handle that yourself.

Here's a fragment showing a partial portion of changes I had to do on a single page - and that kind of rework has more or less to be repeated for all the other pages that I created myself.

Spoiler

index 279ef1ba27..8596f696b1 100644
--- a/release/src/router/www/Main_WStatus_Content.asp
+++ b/release/src/router/www/Main_WStatus_Content.asp
@@ -52,6 +52,11 @@ var dataarray3 = [], wificlients3 = [];
 
 var dfs_statusarray0 = [], dfs_statusarray1 = [], dfs_statusarray2 = [];
 
+if (isSupport("UI4")){
+       var secondFieldStyle = "margin-top:-15px; color: blue;";
+} else {
+       var secondFieldStyle = "margin-top:-15px; color: cyan;";
+}
 <% get_wl_status(); %>;
 
 var classObj= {
@@ -196,9 +201,9 @@ function generate_clients(clientsarray) {
                        if (client[12] != "" && client[12] != guestheader) {
                                guestheader = client[12];
                                if (sw_mode == "2") {
-                                       code += '<tr><th colspan="6" style="color:white;height:20px;"><span class="hint-color" style="font-weight:bolder;">Local Clients: </span> ' + guestheader;
+                                       code += '<tr><th colspan="6" style="height:20px;"><span class="hint-color" style="font-weight:bolder;">Local Clients: </span> ' + guestheader;
                                } else {
-                                       code += '<tr><th colspan="6" style="color:white;height:20px;"><span class="hint-color" style="font-weight:bolder;">Guest Network: </span> ' + guestheader;
+                                       code += '<tr><th colspan="6" style="height:20px;"><span class="hint-color" style="font-weight:bolder;">Guest Network: </span> ' + guestheader;
                                        if (client[13] != "") {
                                                code += '<span style="float:right;"><span class="hint-color" style="font-weight:bolder;">VLAN: </span> ' + client[13] + '</span>';
                                        }
@@ -210,7 +215,7 @@ function generate_clients(clientsarray) {
                        // Mac
                        mac = client[0];
                        overlib_str = "<p><#MAC_Address#>:</p>" + mac;
-                       code += '<td><span style="margin-top:-15px; color: white;" class="link" onclick="oui_query_full_vendor(\'' + mac +'\');overlib_str_tmp=\''+ overlib_str +'\';return overlib(\''+ overlib_str +'\');" onmouseout="nd();" style="cursor:pointer; text-decoration:underline;">'+ mac +'</span>';
+                       code += '<td><span style="margin-top:-15px;" class="link" onclick="oui_query_full_vendor(\'' + mac +'\');overlib_str_tmp=\''+ overlib_str +'\';return overlib(\''+ overlib_str +'\');" onmouseout="nd();" style="cursor:pointer; text-decoration:underline;">'+ mac +'</span>';
 
                        if (typeof clientList[mac] === "undefined")
                                nmapentry = false;
@@ -226,9 +231,9 @@ function generate_clients(clientsarray) {
                        }
 
                        if (hostname.length > 24) {             // Name
-                               code +='<br><span style="margin-top:-15px; color: cyan;" title="' + hostname + '">'+ hostname.substring(0,20) +'...</span></td>';
+                               code +=`<br><span style="${secondFieldStyle}"${hostname}">${hostname.substring(0,20)}...</span></td>`;
                        } else {
-                               code +='<br><span style="margin-top:-15px; color: cyan;">'+ htmlEnDeCode.htmlEncode(hostname) +'</span></td>';
+                               code +=`<br><span style="${secondFieldStyle}">${htmlEnDeCode.htmlEncode(hostname)}</span></td>`;
                        }
 
                        ipaddr = client[1];
@@ -240,27 +245,27 @@ function generate_clients(clientsarray) {
 
(snipped for length)

Boostrap only processes the page at load time, so that means anything inserted into the DOM at runtime (like the client entries in the example above) will need to handle the UI4 colouring itself.

I currently need to load each page that I had created myself one by one, documenting the visual issues, and addressing them. Some are just a few colour tweaks. Others (like the VPN client and server pages) are completely broken as the tab switcher didn't render properly, and needed deeper investigation to resolve. It's all slow work, but by now I made it far enough to know that it's very doable. It's also the occasion for me to start learning some ECMAScript 2015 features that do make this much more manageable - namely the use of Template Strings.

So yes, once I start releasing firmware for models that are using UI4, addon authors should be prepared to potentially have a LOT of work to do, depending on how "creative" they got in their layout, or if they tried to stick to a more traditional Asus page layout, reusing the existing CSS classes.

At this time tho, I cannot go into any further details as to what my plans are regarding models using that new UI4. That will come later. Some stuff is still under embargo for me.