ntpMerlin compatibility with Merlin 3006.102.3

[Ripshod]

I'm just wondering if this is being maintained. It seems this plugin is throwing a fistfull of errors every time the "generate" cron runs;

Jan 21 18:30:25 ripshod kernel: blog_get_dstentry_by_id:dstid[1388] match fails entry.dstid[1516]
Jan 21 18:30:25 ripshod kernel: blog_get_dstentry_by_id:dstid[1388] match fails entry.dstid[1516]
Jan 21 18:30:27 ripshod kernel: blog_get_dstentry_by_id:dstid[1389] match fails entry.dstid[1517]
Jan 21 18:30:27 ripshod kernel: blog_get_dstentry_by_id:dstid[1390] match fails entry.dstid[1518]
Jan 21 18:30:27 ripshod kernel: blog_get_dstentry_by_id:dstid[1391] match fails entry.dstid[1519]
Jan 21 18:30:29 ripshod kernel: blog_get_dstentry_by_id:dstid[1392] match fails entry.dstid[1520]
Jan 21 18:30:30 ripshod kernel: blog_get_dstentry_by_id:dstid[1393] match fails entry.dstid[1521]
Jan 21 18:30:30 ripshod kernel: blog_get_dstentry_by_id:dstid[1394] match fails entry.dstid[1522]
Jan 21 18:30:32 ripshod kernel: blog_get_dstentry_by_id:dstid[1396] match fails entry.dstid[1524]
Jan 21 18:30:33 ripshod kernel: blog_get_dstentry_by_id:dstid[1397] match fails entry.dstid[1525]
Jan 21 18:30:33 ripshod kernel: blog_get_dstentry_by_id:dstid[1398] match fails entry.dstid[1526]
Jan 21 18:30:35 ripshod kernel: blog_get_dstentry_by_id:dstid[1399] match fails entry.dstid[1527]
Jan 21 18:30:36 ripshod kernel: blog_get_dstentry_by_id:dstid[1400] match fails entry.dstid[1528]
Jan 21 18:30:37 ripshod kernel: blog_get_dstentry_by_id:dstid[1401] match fails entry.dstid[1529]
Jan 21 18:30:47 ripshod kernel: blog_get_dstentry_by_id:dstid[1405] match fails entry.dstid[1533]
Jan 21 18:30:50 ripshod kernel: blog_get_dstentry_by_id:dstid[1407] match fails entry.dstid[1535]
Jan 21 18:31:27 ripshod kernel: blog_get_dstentry_by_id:dstid[1420] match fails entry.dstid[1548]
Jan 21 18:31:27 ripshod kernel: blog_get_dstentry_by_id:dstid[1422] match fails entry.dstid[1550]
Jan 21 18:31:27 ripshod kernel: blog_get_dstentry_by_id:dstid[1423] match fails entry.dstid[1551]
Jan 21 18:31:27 ripshod kernel: blog_get_dstentry_by_id:dstid[1424] match fails entry.dstid[1552]
Jan 21 18:31:28 ripshod kernel: blog_get_dstentry_by_id:dstid[1426] match fails entry.dstid[1554]
Jan 21 18:31:28 ripshod kernel: blog_get_dstentry_by_id:dstid[1428] match fails entry.dstid[1556]
Jan 21 18:31:28 ripshod kernel: blog_get_dstentry_by_id:dstid[1432] match fails entry.dstid[1560]
Jan 21 18:31:28 ripshod kernel: blog_get_dstentry_by_id:dstid[1434] match fails entry.dstid[1562]
Jan 21 18:31:30 ripshod kernel: blog_get_dstentry_by_id:dstid[1438] match fails entry.dstid[1566]

I know this is not a serious issue but it would be nice to clear this one up, wouldn't it?

 

[dave14305]

I doubt they are related. blog is part of Broadcom’s proprietary stuff.

 

[visortgw]

I doubt they are related. blog is part of Broadcom’s proprietary stuff.

I believe that you are spot on — I'm seeing these same errors, and ntpMerlin is one add-on that I DON'T use. I am receptive to any ideas of what might actually be causing them — some users are seeing them, and others are not.

 

[dave14305]

I am receptive to any ideas of what might actually be causing them

No idea, but here is the place where the log msg originates.

asuswrt-merlin.ng/release/src-rt-5.04behnd.4916/kernel/bcmkernel/net/core/blog_dst.c at b5fb23a4be5c87df4c345551461de39455e58bfa · RMerl/asuswrt-merlin.ng

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

github.com

 

[Ripshod]

It's happening in my system log in blocks every 10 minutes to a few seconds. As "ntpMerlin generate" is the only cron I have that runs every 10 minutes I naturally assume it's that. I've spent the afternoon installing one addon at a time, letting it settle for 30 minutes, then a backup. I wasn't seeing these messages at all before I install ntpMerlin. If I wind back to a previous backup I see none of these messages.
It could be an interaction between a couple of addons.
I remember a long time ago someone posted an edit to syslog-ng's configuration files that would drop certain messages but I can't find it now. Something like that to drop these messages would seem to be the easiest option - for my sanity reading the logs.

 

[visortgw]

It's happening in my system log in blocks every 10 minutes to a few seconds. As "ntpMerlin generate" is the only cron I have that runs every 10 minutes I naturally assume it's that. I've spent the afternoon installing one addon at a time, letting it settle for 30 minutes, then a backup. I wasn't seeing these messages at all before I install ntpMerlin. If I wind back to a previous backup I see none of these messages.
It could be an interaction between a couple of addons.
I remember a long time ago someone posted an edit to syslog-ng's configuration files that would drop certain messages but I can't find it now. Something like that to drop these messages would seem to be the easiest option - for my sanity reading the logs.

Yes, I tried to "suppress" them by changing log level to Log only messages more urgent than notice. Didn't quite work as planned as now I see frequent messages of the format kernel: blog_get_dstentry_by_id: 43 callbacks suppressed instead of the individual messages. I'm going to try playing with scribe again. Is that what you were talking about with "an edit to syslog-ng's configuration files"?

 

[Ripshod]

I'm going to try playing with scribe again. Is that what you were talking about with "an edit to syslog-ng's configuration files"?

Indeed yes.
I was a beta tester for both BACKUPMON and VPNMON-R3.There were some erroneous messages getting into the system log, messing it up. But at my age I'm excused for forgetting which one and where.

 

[visortgw]

@Ripshod: You got me thinking when you mention ntpMerlin as the suspected cause. Under Administration >> System, do you have Intercept NTP client requests enabled? If so, could you please disable it to see if messages go away after a bit?

 

[visortgw]

@Ripshod: You got me thinking when you mention ntpMerlin as the suspected cause. Under Administration >> System, do you have Intercept NTP client requests enabled? If so, could you please disable it to see if messages go away after a bit?

Never mind they're back...

 

[visortgw]

OK, possible fix...

1. If you haven't already installed scribe, install modified version compatible with 3006.102.3 firmware:

curl -LSs --retry 4 --retry-delay 5 --retry-connrefused \
https://raw.githubusercontent.com/cynicastic/scribe/fadcc527ec832d224dbc961023f6819b41b373a2/scribe \
-o /jffs/scripts/scribe && chmod a+x /jffs/scripts/scribe

2. Launch/install scribe from amtm.

3. Create dstentry filter file:

filter f_dstentry {
    program("kernel") and
    message("blog_get_dstentry_by_id:");
};

log {
    source(src);
    filter(f_dstentry);
    flags(final);
};

#eof

4. Copy dstentry file to known directory for scribe: cp dstentry /opt/etc/syslog-ng.d/dstentry

5. Restart syslog-ng from scribe main menu.

 

[Ripshod]

This is crazy. I can't access the router via the gui, and my ssd is running constantly. Looks like I gotta restore again
*edit* nope, I gotta rebuild from scratch

 

[visortgw]

This is crazy. I can't access the router via the gui, and my ssd is running constantly. Looks like I gotta restore again

OUCH!!! Thank you, @Viktor Jaep, for BACKUPMON!!!

 

[dave14305]

I gotta rebuild from scratch

Glad to see you crossed out a lot of “extras” in your signature. Decide what you absolutely can’t live without from an operational point of view for your router. Abandon most of the “management/eye candy” extras. If it doesn’t make routing traffic better or safer, don’t install it.

 

[Ripshod]

Glad to see you crossed out a lot of “extras” in your signature. Decide what you absolutely can’t live without from an operational point of view for your router. Abandon most of the “management/eye candy” extras. If it doesn’t make routing traffic better or safer, don’t install it.

Agreed. The old RT-AX88U is still fully loaded as a testbed/diagnostic tool but this one will only get what I use, as and when. Decisions, decisions
ntpMerlin is a necessity to me - with all the radio work I do an accurate timebase is definitely useful, though I'm also thinking of switching to ptp. In this respect I'm glad ntpMerlin has been proven an innocent victim of these logged errors rather than the perpetrator.