uiScribe uiScribe v1.4.12 [2026-Feb-16] - Custom System Log WebUI page for Scribe (syslog-ng) logs

[Ripshod]

@dineshgyl what is your aim on these forums? I notice you have made 51 posts in your 13+ months here, but two thirds of those have been removed for whatever reason. Here you are bleating about a problem with an addon you said you wouldn't consider installing. You seem to be investigating problems that don't exist, using invalid methods, disecting the work of others. You want senior members to change their code to suit your needs. Even your router can't keep an Internet connection.
Why don't you produce your own code for us, show us how it's done?

 

[dineshgyl]

Hi,

I am still learning how this works. I am sorry my posts are too basic. I tried Scribe for the first time and noticed this /jffs anomaly about size being constantly changing when even when du reports same size all the time. I searched the forum too and did not find this anomaly being reported earlier hence thought of sharing it.

I wanted to know if installing scribe makes /jjfs use much more.

I am sorry if I am bothering you so much.

 

[Tech9]

If flash wear is your concern - your router most likely will be EoL and replaced long before it happens.

 

[Martinski]

Release Notes for uiScribe v1.4.11 production version now available
[2026-Jan-12]

- Improvements in the display of CLI menus.

IMPORTANT:
- Installation of Scribe v3.2.6 (or later) version is required so that all calls to logrotate from both Scribe and uiScribe can be coordinated and managed properly.

Scribe - Scribe v3.2.6 [2025-Dec-22] - Entware syslog-ng and logrotate installer for Asuswrt-Merlin

Yep, the message has already been modified accordingly. That line in the .asp must set a record for length! If I follow, this message will show if the timeout is triggered. That would also happen if the file is too big (takes too long) to load. And, can the log file ever not exist for...

www.snbforums.com

The fork from @Jack Yaz's uiScribe add-on is now hosted on the AMTM-OSR GitHub repo:

GitHub - AMTM-OSR/uiScribe: uiScribe updates the System Log page to show log files created by Scribe (syslog-ng). Requires Scribe https://github.com/cynicastic/scribe

uiScribe updates the System Log page to show log files created by Scribe (syslog-ng). Requires Scribe https://github.com/cynicastic/scribe - AMTM-OSR/uiScribe

github.com

 

[Martinski]

Release Notes for uiScribe v1.4.12 production version now available
[2026-Feb-16]

1) FIXED: Bug fix in the code that searches for the full paths of all filtered log files.

For example, the following entry, which is syntactically valid in a syslog-ng configuration file, would generate an error message:​

destination d_MyLogFile { file("/opt/var/log/MyLogFile.log"); };

2) FIXED: Bug fix in the code that generates the list of all filtered log files.

For example, the following entry, which is syntactically valid in a syslog-ng configuration file, would not generate an error message, but the file path ended up being excluded from the list of filtered log files:​

destination d_MyLogFile { file('/opt/var/log/MyLogFile.log'); };

The fork from @Jack Yaz's uiScribe add-on is now hosted on the AMTM-OSR GitHub repo:

GitHub - AMTM-OSR/uiScribe: uiScribe updates the System Log page to show log files created by Scribe (syslog-ng). Requires Scribe https://github.com/cynicastic/scribe

uiScribe updates the System Log page to show log files created by Scribe (syslog-ng). Requires Scribe https://github.com/cynicastic/scribe - AMTM-OSR/uiScribe

github.com

 

[elorimer]

Perhaps it is related: I have a log file named "a86U.log". All of the other logs are alphabetic or with "-". All the logs show up in uiScribe, but a86U.log alone does not have a size appended. It is no big thing, but perhaps there is an issue with a log name including numerics?

EDIT: Nevermind. User error. I had erroneously placed the log file in a subdirectory of /opt/var/log in the destination definition. So the destination was valid for syslog-ng, and showed up in --preprocess-into, but GetFileSize was only looking for the stripped file name in /opt/var/log. Interestingly, the log was correctly displaying in the UI. When I changed the location the logsize was displaying.

 

[Martinski]

Perhaps it is related: I have a log file named "a86U.log". All of the other logs are alphabetic or with "-". All the logs show up in uiScribe, but a86U.log alone does not have a size appended. It is no big thing, but perhaps there is an issue with a log name including numerics?

EDIT: Nevermind. User error. I had erroneously placed the log file in a subdirectory of /opt/var/log in the destination definition. So the destination was valid for syslog-ng, and showed up in --preprocess-into, but GetFileSize was only looking for the stripped file name in /opt/var/log. Interestingly, the log was correctly displaying in the UI. When I changed the location the logsize was displaying.

You brought up a good point. Technically, both syslog-ng and logrotate can handle log files located in a subdirectory within the "/opt/var/log" directory, so that scenario should be allowed to work - unless there's some limitation that I'm not aware of.

I've now modified the few dependencies that were in place within Scribe and uiScribe that expected log files to be searched for and located only at the "/opt/var/log" directory level.

Note that the 'messages' log file is a special case and must be located in the "/opt/var/log" and *not* in a subdirectory.

 

[aru]

Since installing the Scribe & uiScribe addon, I’ve discovered how easily logs can be categorized and organized, which sparked my interest in further integration. I began by adding my AiMesh nodes, then expanded to include switch logs, and eventually even integrated my NAS logs. Before I knew it, it had evolved into a centralized logging hub for all my home network devices.

At first, I was concerned that integrating so many devices might impact performance, but so far it has been running smoothly and reliably. I’m genuinely curious about its performance limits. Many thanks to the developer for the thoughtful design and hard work behind this project!

 

[Martinski]

At first, I was concerned that integrating so many devices might impact performance, but so far it has been running smoothly and reliably. I’m genuinely curious about its performance limits. Many thanks to the developer for the thoughtful design and hard work behind this project!

I got to say, first and foremost, the credit goes to the two original authors. Scribe & uiScribe add-ons are the result of a great collaborative effort between @cmkelley & @Jack Yaz, along with several forum users who provided assistance with testing, feedback, bug reports, and suggestions.

As for my contributions, I’ve just been ironing out some of the wrinkles, smoothing out a few rough edges, and adding/modifying code to improve the overall functionality, but the bulk of the work and the heavy lifting were already done by @cmkelley & @Jack Yaz.

 

[JGrana]

I got to say, first and foremost, the credit goes to the two original authors. Scribe & uiScribe add-ons are the result of a great collaborative effort between @cmkelley & @Jack Yaz, along with several forum users who provided assistance with testing, feedback, bug reports, and suggestions.

As for my contributions, I’ve just been ironing out some of the wrinkles, smoothing out a few rough edges, and adding/modifying code to improve the overall functionality, but the bulk of the work and the heavy lifting were already done by @cmkelley & @Jack Yaz.

@Martinski IMHO you are much too modest.
Yes, the early pioneers like @JackYaz, @thelonelycoder ,@Martineau , @Adamm, @dave14305 , @cmkelley and many other helped create this great addon ecosystem. Some have moved on, some continue.
I have studied your code and you are as gifted as any.

It’s people like you, @Viktor Jaep ,@ExtremeFiretop and many others that have kept it alive and growing.

I (and I’m sure others) appreciate all of your fine efforts and support!

PS: I should also mention that without @RMerlin and @thiggins - none of this would be possible.

 

[elorimer]

All kudos are so well deserved. I just want to keep alive the memory of @kvic, who started us down this road.

 

[dave14305]

I just want to keep alive the memory of @kvic, who started us down this road.

I see him post occasionally at the OpenWrt forums, last time in December.

 

[aru]

The original author gave the project its life. The maintainer gave it the chance to survive.

In open-source communities — especially in a niche but hardcore space like Asuswrt-Merlin — ongoing maintenance is often harder than the initial development.

We’ve all seen it happen.Brilliant scripts. Solid foundations. Well-designed logic.Then life happens. The original author moves on. Updates stop.

No one steps in to deal with firmware changes, compatibility issues, or UI breakage… and eventually the project becomes another GitHub repo full of code that used to work.

Merlin firmware itself keeps evolving. From the old 386 branch to the newer 3004/3006 series, Firmware has changed quite a bit under the hood — WebUI structure, CSS layout, JavaScript dependencies, even system log paths. What worked yesterday can silently break tomorrow.

Most people don’t realize how difficult it is to take over someone else’s “legacy.” This kind of maintenance isn’t the fun, creative rush of building something from scratch.

It’s about reverse-engineering someone else’s thought process:
Why was it written this way? There’s no comment — is this workaround intentional or just masking a bug? If I clean this up, will I break some hidden assumption? You’re not designing a new house. You’re renovating one without the blueprints.

What Martinski has done goes far beyond just “moving code forward.” He fixed real issues introduced by firmware changes — the scrollbar bug, pagination loading errors, and compatibility with 3006.102.x builds. Without that work, uiScribe might already be broken on 3006 firmware or newer hardware like WiFi 7 models.

Developers who are willing to quietly step in, carry the torch, and keep things working — without taking credit or making it about themselves — are the real backbone of communities like this.

 

[archiel]

I have just swapped out my RT-AX88U for a RT-BE88U and the re-installed all my old scripts (manually). Scribe appears to be working as before other than with the skynet / ethernet filters. on the AX88U the skynet filter would pickup the BLOCKED lines leaving ethernet to list any other "eht1"..."eth#" messages.

With the BE88U, the ethernet filter is grabbing all the skynet BLOCKED lines

Router kernel: [BLOCKED - INBOUND] IN=eth1 OUT= MAC=a8:a1:59:....

. Also looking directly at the skynet-0.log it only contains entries like

Feb 25 18:10:16 Router Skynet: [#] 6836 IPs (+0) -- 1421 Ranges Banned (+0) || 0 Inbound -- 0 Outbound Connections Blocked! [start] [20s]
Feb 25 18:21:48 Router Skynet: [#] 6836 IPs (+0) -- 1421 Ranges Banned (+0) || 35 Inbound -- 0 Outbound Connections Blocked! [settings] [1s]
Feb 25 18:22:07 Router Skynet: [#] 6836 IPs (+0) -- 1421 Ranges Banned (+0) || 36 Inbound -- 0 Outbound Connections Blocked! [settings] [0s]
Feb 25 19:00:01 Router Skynet: [#] 6836 IPs (+0) -- 1421 Ranges Banned (+0) || 120 Inbound -- 0 Outbound Connections Blocked! [save] [1s]

Have I messed up the install or is there another reason for this happening?

 

[elorimer]

I have just swapped out my RT-AX88U for a RT-BE88U and the re-installed all my old scripts (manually). Scribe appears to be working as before other than with the skynet / ethernet filters. on the AX88U the skynet filter would pickup the BLOCKED lines leaving ethernet to list any other "eht1"..."eth#" messages.

With the BE88U, the ethernet filter is grabbing all the skynet BLOCKED lines

Router kernel: [BLOCKED - INBOUND] IN=eth1 OUT= MAC=a8:a1:59:....

. Also looking directly at the skynet-0.log it only contains entries like

Feb 25 18:10:16 Router Skynet: [#] 6836 IPs (+0) -- 1421 Ranges Banned (+0) || 0 Inbound -- 0 Outbound Connections Blocked! [start] [20s]
Feb 25 18:21:48 Router Skynet: [#] 6836 IPs (+0) -- 1421 Ranges Banned (+0) || 35 Inbound -- 0 Outbound Connections Blocked! [settings] [1s]
Feb 25 18:22:07 Router Skynet: [#] 6836 IPs (+0) -- 1421 Ranges Banned (+0) || 36 Inbound -- 0 Outbound Connections Blocked! [settings] [0s]
Feb 25 19:00:01 Router Skynet: [#] 6836 IPs (+0) -- 1421 Ranges Banned (+0) || 120 Inbound -- 0 Outbound Connections Blocked! [save] [1s]

Have I messed up the install or is there another reason for this happening?

Three separate things.

The ethernet filter is picking up the skynet messages because it is matching to the eth1 in IN=eth1, and it processes the ethernet filter before the skynet filter (it's alphabetical). I don't know why that hasn't been reported before. You might rename the ethernet configuration file "zethernet".

I speculate. My skynet messages on an AX88U come from eth0. The ethernet filter doesn't match to eth0, only 1-8. While I don't use the ethernet filter, that is why I wouldn't see the problem. So maybe the newer routers use eth1 instead of eth0, and that switch is why you are now seeing the problem.

Skynet reaches in and manipulates the skynet log file to roll up all of the DROP messages, etc. into the lines you see, but it should only be doing it hourly. So in normal operation, the skynet log will have the rolled up messages at each start of the hour, and then all the DROP, etc messages since then, until they are purged in the next rollup. So not sure why you are seeing those odd times.

 

[visortgw]

Three separate things.

The ethernet filter is picking up the skynet messages because it is matching to the eth1 in IN=eth1, and it processes the ethernet filter before the skynet filter (it's alphabetical). I don't know why that hasn't been reported before. You might rename the ethernet configuration file "zethernet".

I speculate. My skynet messages on an AX88U come from eth0. The ethernet filter doesn't match to eth0, only 1-8. While I don't use the ethernet filter, that is why I wouldn't see the problem. So maybe the newer routers use eth1 instead of eth0, and that switch is why you are now seeing the problem.

Skynet reaches in and manipulates the skynet log file to roll up all of the DROP messages, etc. into the lines you see, but it should only be doing it hourly. So in normal operation, the skynet log will have the rolled up messages at each start of the hour, and then all the DROP, etc messages since then, until they are purged in the next rollup. So not sure why you are seeing those odd times.

I'm seeing the hourly "roll up" summaries every hour, but the previous messages are not being deleted as they used to be. Snippet shows a few messages pre- and post- roll up:

Feb 25 18:59:20 routS1R kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=10:7c:61:af:76:68:00:01:5c:8a:a2:46:08:00 SRC=91.231.89.130 DST=66.24.51.119 LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=64433 DF PROTO=TCP SPT=45749 DPT=9801 SEQ=448385948 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B4080A4445414400000000030301040200) MARK=0x8000000
Feb 25 18:59:21 routS1R kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=10:7c:61:af:76:68:00:01:5c:8a:a2:46:08:00 SRC=79.124.58.150 DST=66.24.51.119 LEN=40 TOS=0x00 PREC=0x00 TTL=240 ID=44707 PROTO=TCP SPT=40012 DPT=8666 SEQ=3610426382 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000
Feb 25 18:59:25 routS1R kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=10:7c:61:af:76:68:00:01:5c:8a:a2:46:08:00 SRC=78.128.114.42 DST=66.24.51.119 LEN=40 TOS=0x00 PREC=0x00 TTL=240 ID=25167 PROTO=TCP SPT=43890 DPT=8443 SEQ=4206064067 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000
Feb 25 18:59:36 routS1R kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=10:7c:61:af:76:68:00:01:5c:8a:a2:46:08:00 SRC=176.65.139.41 DST=66.24.51.119 LEN=44 TOS=0x00 PREC=0x00 TTL=49 ID=57803 PROTO=TCP SPT=50000 DPT=3001 SEQ=1066338317 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B4) MARK=0x8000000
Feb 25 18:59:42 routS1R kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=10:7c:61:af:76:68:00:01:5c:8a:a2:46:08:00 SRC=85.217.149.34 DST=66.24.51.119 LEN=52 TOS=0x00 PREC=0x00 TTL=52 ID=25108 PROTO=TCP SPT=59258 DPT=16361 SEQ=2898306953 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B40103030801010402) MARK=0x8000000
Feb 25 19:00:01 routS1R Skynet: [#] 34245 IPs (+0) -- 2601 Ranges Banned (+0) || 1784 Inbound -- 0 Outbound Connections Blocked! [save] [1s]
Feb 25 19:00:03 routS1R kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=10:7c:61:af:76:68:00:01:5c:8a:a2:46:08:00 SRC=185.242.226.97 DST=66.24.51.119 LEN=29 TOS=0x00 PREC=0x00 TTL=52 ID=48321 PROTO=UDP SPT=58484 DPT=40685 LEN=9 MARK=0x8000000
Feb 25 19:00:06 routS1R kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=10:7c:61:af:76:68:00:01:5c:8a:a2:46:08:00 SRC=176.65.134.3 DST=66.24.51.119 LEN=44 TOS=0x00 PREC=0x00 TTL=237 ID=25253 PROTO=TCP SPT=48693 DPT=3629 SEQ=1081434111 ACK=0 WINDOW=1025 RES=0x00 SYN URGP=0 OPT (020405B4) MARK=0x8000000
Feb 25 19:00:16 routS1R kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=10:7c:61:af:76:68:00:01:5c:8a:a2:46:08:00 SRC=89.248.163.200 DST=66.24.51.119 LEN=40 TOS=0x00 PREC=0x00 TTL=243 ID=50295 PROTO=TCP SPT=41374 DPT=6379 SEQ=371978219 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000
Feb 25 19:00:27 routS1R kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=10:7c:61:af:76:68:00:01:5c:8a:a2:46:08:00 SRC=167.94.138.131 DST=66.24.51.119 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=56467 PROTO=TCP SPT=16166 DPT=389 SEQ=1158734450 ACK=0 WINDOW=42340 RES=0x00 SYN URGP=0 OPT (020405B40402080A699F5916000000000103030A) MARK=0x8000000
Feb 25 19:00:28 routS1R kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=10:7c:61:af:76:68:00:01:5c:8a:a2:46:08:00 SRC=91.231.89.138 DST=66.24.51.119 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=52523 DF PROTO=TCP SPT=22577 DPT=9762 SEQ=220396673 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B4080A4445414400000000030301040200) MARK=0x8000000

 

[Martinski]

I have just swapped out my RT-AX88U for a RT-BE88U and the re-installed all my old scripts (manually). Scribe appears to be working as before other than with the skynet / ethernet filters. on the AX88U the skynet filter would pickup the BLOCKED lines leaving ethernet to list any other "eht1"..."eth#" messages.

With the BE88U, the ethernet filter is grabbing all the skynet BLOCKED lines

Router kernel: [BLOCKED - INBOUND] IN=eth1 OUT= MAC=a8:a1:59:....

I have modified the syslog-ng ethernet filter configuration file to prevent it from capturing log entries intended for the Skynet log file. Note that there are other ways to fix the issue you reported; this is just one of several possible solutions.

To download and install the latest ethernet filter config file, go to the Scribe CLI menu and choose the "ft. Update filters" option. When prompted to update the filter files, type "y" and follow the prompts to accept the update to the ethernet filter config file.

After you have completed updating the filter file and exited the menu, you're done.

Now you can double-check if new log entries are correctly filtered to the corresponding Skynet and Ethernet log files.

HTH

 

[elorimer]

I can see from the other thread about vlan mapping that some of the newer routers are using eth0 for a LAN port and eth1 or others for WAN. You've fixed it to cover that scenario, but perhaps the ethernet filter should now also include eth0 as a possible LAN port, or maybe just eth. (Or, this might be a place to try out in-list filtering for fun). Looking at past logs, I see br2 popping up with these kinds of messages as well. But not enough messages for this filter for me to bother screening them out of the messages log.

It might still be worth renaming the configuration file at the end of the alphabet so fewer messages are tested. As it is this filter comes before more noisy stuff like hostapd, skynet, roamast and wlceventd. It's a complicated filter and while AND/OR filtering is not supposed to bog things down MATCH is less performant. Not that performance seems to be an issue.

EDIT: Also, this is more scribe than uiscribe.

 

[Martinski]

I can see from the other thread about vlan mapping that some of the newer routers are using eth0 for a LAN port and eth1 or others for WAN. You've fixed it to cover that scenario, but perhaps the ethernet filter should now also include eth0 as a possible LAN port, ...

Yes, good point. I have now modified the ethernet filter config file to handle this possible scenario.

... or maybe just eth.

That would match any messages containing the substring, such as method or ethernet, which is not the intended target.

... Looking at past logs, I see br2 popping up with these kinds of messages as well.

This scenario is now handled as well.

It might still be worth renaming the configuration file at the end of the alphabet so fewer messages are tested. As it is this filter comes before more noisy stuff like hostapd, skynet, roamast and wlceventd. It's a complicated filter and while AND/OR filtering is not supposed to bog things down MATCH is less performant. Not that performance seems to be an issue.

According to the recent documentation I've read, the match() function has virtually the same performance as the message() function IFF the scope is limited to the "MESSAGE" value. IOW, the following calls are essentially equivalent:

message('stringToMatch');

match('stringToMatch' value("MESSAGE"));

However, when regular expressions are used, the performance may start to drop, and sometimes it can be significant, depending on several factors such as the message length, pattern matching complexity (e.g. grouping, nexted groups, lookaheads, backtracking, etc.), and extensive use of general wildcards due to the overhead. So the general rule is to keep regular expressions as simple and as tightly focused as possible (e.g. "eth[0-9]" is more performant than "eth.*").