QoS - Web History Sort by Columns possible? (Or any columns for that matter.)

[mrf0ster]

Hello all,
I am just wondering, is it possible to have a choice when sorting columns by either "Access time" rather than "Domain name" when you select your particular client under QoS - Web History? (Domain Name appears to be the default sorting structure)

I guess a little like excel when you can sort a column of your choice? Maybe this is an option already that I may have missed on how to activate.

Cheers Mark

 

[Martineau]

Hello all,
I am just wondering, is it possible to have a choice when sorting columns by either "Access time" rather than "Domain name" when you select your particular client under QoS - Web History? (Domain Name appears to be the default sorting structure)

I guess a little like excel when you can sort a column of your choice? Maybe this is an option already that I may have missed on how to activate.

Cheers Mark

The GUI options are sadly lacking...perhaps my script Web History Reporting may be useful?

 

[mrf0ster]

Thank you martineua, I will explore this.

Cheers Mark

 

[FreshJR]

It is possible to create a matured WebUI implementation of WebHistory.

Mount the WebHistory.db on /www
parse WebHistory.db via javascript
draw the results as a table
have the table sortable + filterable by columns


--

I could recycle the last two elements from my QoS script so it wouldn't be a terrible ammount of work. But at this rate, I feel we would have to continue stripping all the broken abandon-ware, implementing our own functional approaches, and move furthur away from AsusWRT.

A LOT of features on the router have a broken/flawed implementation, with no intention for a future fix, and left to rot. Pretty sure Asus just wants the UI to be flashy at first glance, and assumes most people will never return after the initial configuration.

Boggles my mind how Asus cannot fix networkmap .........

 

[RMerlin]

Boggles my mind how Asus cannot fix networkmap .........

The new RT-AX88U firmware claims to have fixed it. We'll know for sure once that fix trickles down various GPL releases I guess...

Some backstory on networkmap:

The original implementation was written in the early days of Asus's routers - the code was just as badly written as infosvr. When I began working on Asuswrt-Merlin, I fixed a LOT of bugs in it:

- Buffer overruns causing the router to crash if you had a WDTV, or a Windows Home Server on your LAN
- More and more buffer overruns all over the place, no string boundary checks on data obtained through UPNP/SMB/Netbios/etc...
- Failure to scan anything because it was starting too early at boot time

At one point it seems Asus decided they didn't even feel like tracking down all those issues, and one firmware release I saw that they had simply replaced their networkmap code with mine (it included some code they didn't use, which is how I know they just copied the files from my repo). By then, networkmap worked fairly well.

Then in the late 380 days, they started rewriting the httpd/networkmap sharing by storing data into json structures. The networkmap code on the httpd (and webui side) became MUCH more complicated to follow.

And then came the 382 release.

- Networkmap got tied to the Trend Micro DPI engine (to better identify clients)
- Networkmap got tied to the Broadcom wireless code, to retrieve info such as link rates
- And because of these two, networkmap then became closed source.

Since then, networkmap stability/reliability has gone downhill, after having started to regain some semblance of reliability...

If that whole httpd-related backend wasn't so damn complicated, I would have reconsidered maybe reverting back to my old code, and building on top of it. But adapting it to the new data structure (and all this info it now retrieves from DPI/BCM and which I have no idea how to access) pretty much closed down that door.

Why a simple network mapping daemon has to be a) so complicated, and b) so unreliable is beyond me. It used to be horribly unstable, then it got better. Then a whole layer of bloat/features (based on your point of view) got added to it, and it's once again unreliable.

And we haven't mentioned the fact that it's hardcoded to only handle a /24 network.


In my personal opinion, having a fairly global understanding of the code in general (and only a very good understanding of some very specific areas of the code), Asuswrt has become unmanageable. Large portions of the code need to be thrown away, and rewritten from scratch. More specifically:

- The wanduck daemon (it needs to be taken behind the shed, and shot in the head. Twice.)
- The watchdog (lots of that stuff should be rewritten as cron events, and only a few select events kept in a constantly running watchdog)
- networkmap
- Portions of httpd (a few weeks ago I spent two days devoted to tracking down how settings were applied after a user clicked on Apply, as I was trying to track down the issues about those OpenVPN key/certs ending up in nvram in addition to jffs - let's just say it was a maze to follow)

The event notification system (rc_notify) could also see some redesign. Right now the system is a two-slot queue. If an event is underway while a second is sent, that second is queued for a limited amount of time. Send a third one, and it gets lost. This needs to be redesigned in a FIFO queue, not just that two-slot queue.

On the webui front:

- The webui needs a pass at consistency. Some things are presented as pages (the USB page), others as tabs (most pages), other as dropdown items (the QoS page), others as buttons (the OpenVPN pages)...
- All lists (DHCP, Port Forward, etc...) should be redone as editable tables. Looks to me like that was the idea behind their Table module, but it never got fully realized. Recently they redid the port forwarding page, which is a great improvement.
- All the System Log pages need to be redesigned as actual webpage, not just textareas with unformatted text. (this is what I have done with my firmware, redesigning each System Log pages one after another)
- A lot of obsolete code needs to be dropped (all the old DrAsus code that dates back to the 1.xx "Blue Webui"). The DDNS page still uses Alert() calls to notify you about the DDNS status instead of embedding it in the webui like everything else (that's something I'd like to take care of myself with 384.11)


Part of the problem is that's a LOT of thing to do, none of which actually sell routers, compared to all the ROG eye candy, or IFTTT support. As a business, it's probably hard to justify investing a whole team of engineers to doing these.

And on top of this all, it doesn't make things easy that they have to support so many VERY different products with the same Asuswrt codebase. So when you change something for one model, who knows what effect it will have on every other models. Or, they have to embed a bunch of conditional sections to handle some things differently depending on the router model.

 

[L&LD]

RMerlin, great post, and quite an eyeopener!

I think this is exactly what MS has been doing with Windows 10. Only on a much larger scale, of course.

Asus needs to take that same approach and possibly introduce their 'AX' final products with a new lean, mean and modern GUI with only the code needed for today's network requirements (but hopefully more than what is currently available, even with scripts). I don't mean 'modern' merely by how it looks. I mean modern by the under-the-hood changes that power it. I actually like the look of the GUI as-is, but the changes to make all the parts look and work the same would be beneficial too.

With a code base that is current, they can then concentrate on putting this on their next most current router(s). They don't need to look or work the same. Time will naturally let the old code die in a natural way (the hardware will be obsolete by then) and the new, clean code can be once again the standard across all their products.

Hopefully, we will see some of these things happen soon.

I'm already looking forward to 384.11! But that's just because 384.10 is working so well, as usual. Taking this time to give thanks for your great services once more.

 

[RMerlin]

Such a code reset sound unlikely to occur anytime soon IMHO, as it would require them to delay everything else (like releasing new models to the market). And if you don't release a steady stream of new products, the competition will quickly overtake you.

And to be honest, the competition ain't much better right now... Their code might not be as bloated, but a lot of it is even MUCH older, going back to the days of the original Linksys WRT54G source code. Who knows what security issues / silly bugs exist in these competitor's products... Back in 2005, programmers rarely bothered with buffer length validation, while in 2019, using something like strlcpy() instead of strcpy() is becoming much more common.