WLCEVENTD log Entries - old thread

[killweav]

Not sure when this started exactly bc I don't check logs on the daily. The last successful log entry in WLCEVENTD rotate file was Mar 26, 2026. I do see associated hostapd and dnsmasq entries in the messages log but nothing fills up in wlceventd.log file. I've reinstalled/rebooted w/no success. Other logs populate just not wlceventd.log.

I ran checks in scribe via amtm and they all appear normal. I produced a debug file but don't understand it fully. Log level is set to 6. Here's an output of what I see:

killweav@Datagate:/tmp/mnt/USB32G/entware/var/log# ls -l
-rw-------    1 killweav root         20877 Apr 10 13:56 logrotate.log
-rw-------    1 killweav root        460584 Apr 10 14:15 messages
-rw-------    1 killweav root       1055832 Mar 18 00:03 messages-202603180005
-rw-------    1 killweav root       1826776 Mar 25 00:03 messages-202603250005
-rw-------    1 killweav root       2429142 Mar 29 00:03 messages-202603290005
-rw-------    1 killweav root       1064027 Apr  8 00:03 messages-202604080005
-rw-------    1 killweav root         25127 Apr 10 14:16 skynet-0.log
-rw-------    1 killweav root       6060345 Mar 28 00:04 skynet-0.log-202603280005
-rw-------    1 killweav root       3470744 Mar 29 00:04 skynet-0.log-202603290005
-rw-------    1 killweav root       6401272 Mar 31 00:04 skynet-0.log-202603310005
-rw-------    1 killweav root       6480275 Apr  2 00:05 skynet-0.log-202604020005
-rw-------    1 killweav root        249114 Apr 10 14:15 syslog-ng.log
-rw-rw-rw-    1 killweav root           353 Apr 10 14:15 syslogd.ScribeInitReboot.LOG
-rw-------    1 killweav root             0 Apr 10 13:11 wlceventd.log
-rw-------    1 killweav root         73790 Mar 26 10:28 wlceventd.log-20260410131157
killweav@Datagate:/tmp/mnt/USB32G/entware/var/log# nvram get log_level
6
killweav@Datagate:/tmp/mnt/USB32G/entware/var/log#

When I cat the log rotate for wlceventd it shows last entry March 26th.

Disk check for external storage shows CLEAN.

UIScribe states that the file is empty or does not yet exist.

I removed the 0 byte file and restarted scribe to see if it would re-create it and it does not re-create the wlceventd.log file.

I can see that the symlink in /jffs is working:

lrwxrwxrwx    1 killweav root            21 Apr 10 14:36 syslog.log -> /opt/var/log/messages
-rw-rw-rw-    1 killweav root            24 Apr 10 14:36 syslog.log-1

I'm at a loss here. Thanks for any/all help offered.

Running Merlin 3006.102.7_2 on BE92U HW v6 router.

 

[elorimer]

Check how whether you have the SIGHUP right. It used to be that scribe wrote individual configuration files for each log, which ended with a postrotate command to restart syslog-ng. If logrotate rotated a log file, it would create a new empty log file, but syslog-ng would still be looking for an old node. Thus the need to restart syslog-ng to reset the node.

That changed in December, when the SIGHUP was moved to a new A01global file, which ends with the postrotate command:

# THIS DIRECTIVE MUST BE LAST #
postrotate
    /usr/bin/killall -HUP syslog-ng
endscript

#EOF#

It may be in the course of reinstalling your logrotate.d files weren't updated, or updated incosnsistently.

 

[killweav]

It may be in the course of reinstalling your logrotate.d files weren't updated, or updated incosnsistently.

Thanks. I checked and the content of the A01global file contains the necessary postrotate section at the end. Any other suggestions? I've since cleared all logs with no change.

 

[elorimer]

And there is no sighup in the wlcevent logrotate configuration file? I thought for sure it was a node problem. Maybe, delete both wlc log files and restart syslog-ng. It will create a new file if it doesn't exist.

 

[killweav]

And there is no sighup in the wlcevent logrotate configuration file? I thought for sure it was a node problem. Maybe, delete both wlc log files and restart syslog-ng. It will create a new file if it doesn't exist.

OK thank you. In following your instructions and troubleshooting (and even updating Scribe to 3.2.12) I think I found the culprit. I downloaded and installed the new Merlin firmware 3006.102.7_2 on my BE92U router on 3/26. That's also the last log entry for the wlceventd logrotate file.

So, I uninstalled scribe (again) and rebooted. Now looking into regular event log there is no wlceventd messages anywhere to be found after full router reboot and forced connection/disconnection to the network. Hostapd message and dnsmasq-dhcp messages sure, but no wlceventd messages.

I never suspected the firmware because I figured since 3/26 more people would have noticed this. Perhaps I'm missing something else. In the meantime, I've sticking with regular system log until I can see those messages appear before using scribe again.

@RMerlin - is this something you have seen or can help with? Log level is set to six and I have also set it to the highest (showing all messages). Still no wlceventd entries in the system log which makes it appear that scribe isn't working. Thanks for your help in advance.

 

[killweav]

@RMerlin here is what I am (and am not) seeing. Log level set to 8 at this point for troubleshooting:

ASUSWRT-Merlin RT-BE92U 3006.102.7_2 Tue Mar 24 20:24:06 UTC 2026
killweav@Datagate:/tmp/home/root# nvram get log_level
8

I also checked message_loglevel which is at 7.

Here is all log entries from a disconnect and reconnect of my phone to the network: No wlceventd messages. Am I missing something or did I find a bug?

Apr 12 13:35:40 hostapd: wl2.1: STA 34:10:be:ef:22:27 IEEE 802.11: disassociated
Apr 12 13:35:40 hostapd: wl2.1: STA 34:10:be:ef:22:27 IEEE 802.11: disassociated
Apr 12 13:35:48 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=60:cf:84:fa:df:60:f8:c0:01:7c:9d:cc:08:00 SRC=66.132.186.242 DST=174.28.34.169 LEN=60 TOS=0x00 PREC=0x00 TTL=59 ID=24915 PROTO=TCP SPT=8983 DPT=55615 SEQ=668445813 ACK=0 WINDOW=42340 RES=0x00 SYN URGP=0 OPT (020405B40402080A69D5E95E000000000103030A) MARK=0x8000000
Apr 12 13:35:48 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=60:cf:84:fa:df:60:f8:c0:01:7c:9d:cc:08:00 SRC=204.76.203.30 DST=174.28.34.169 LEN=40 TOS=0x00 PREC=0x00 TTL=241 ID=54321 PROTO=TCP SPT=38990 DPT=8443 SEQ=3253065557 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0x8000000
Apr 12 13:35:52 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=60:cf:84:fa:df:60:f8:c0:01:7c:9d:cc:08:00 SRC=205.210.31.211 DST=174.28.34.169 LEN=44 TOS=0x00 PREC=0x00 TTL=248 ID=51691 PROTO=TCP SPT=51946 DPT=5907 SEQ=2430073937 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405B4) MARK=0x8000000
Apr 12 13:35:55 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=60:cf:84:fa:df:60:f8:c0:01:7c:9d:cc:08:00 SRC=139.99.125.65 DST=174.28.15.64 LEN=60 TOS=0x00 PREC=0x20 TTL=49 ID=46826 DF PROTO=TCP SPT=51744 DPT=9200 SEQ=3296347203 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A619B98350000000001030307) MARK=0x8000000
Apr 12 13:35:55 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=60:cf:84:fa:df:60:f8:c0:01:7c:9d:cc:08:00 SRC=139.99.125.65 DST=174.28.15.64 LEN=60 TOS=0x00 PREC=0x20 TTL=49 ID=60627 DF PROTO=TCP SPT=48354 DPT=443 SEQ=3412766273 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A619B98370000000001030307) MARK=0x8000000
Apr 12 13:35:55 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=60:cf:84:fa:df:60:f8:c0:01:7c:9d:cc:08:00 SRC=139.99.125.65 DST=174.28.15.64 LEN=60 TOS=0x00 PREC=0x00 TTL=52 ID=45892 DF PROTO=TCP SPT=60566 DPT=80 SEQ=2007026174 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A619B98370000000001030307) MARK=0x8000000
Apr 12 13:35:56 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=60:cf:84:fa:df:60:f8:c0:01:7c:9d:cc:08:00 SRC=139.99.125.65 DST=174.28.15.64 LEN=60 TOS=0x00 PREC=0x20 TTL=49 ID=60628 DF PROTO=TCP SPT=48354 DPT=443 SEQ=3412766273 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A619B9C260000000001030307) MARK=0x8000000
Apr 12 13:35:56 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=60:cf:84:fa:df:60:f8:c0:01:7c:9d:cc:08:00 SRC=139.99.125.65 DST=174.28.15.64 LEN=60 TOS=0x00 PREC=0x20 TTL=49 ID=46827 DF PROTO=TCP SPT=51744 DPT=9200 SEQ=3296347203 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A619B9C260000000001030307) MARK=0x8000000
Apr 12 13:35:56 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=60:cf:84:fa:df:60:f8:c0:01:7c:9d:cc:08:00 SRC=139.99.125.65 DST=174.28.15.64 LEN=60 TOS=0x00 PREC=0x00 TTL=52 ID=45893 DF PROTO=TCP SPT=60566 DPT=80 SEQ=2007026174 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A619B9C260000000001030307) MARK=0x8000000
Apr 12 13:35:57 hostapd: wl2.1: STA 34:10:be:ef:22:27 IEEE 802.11: associated (aid 3)
Apr 12 13:35:57 hostapd: wl2.1: STA 34:10:be:ef:22:27 RADIUS: starting accounting session 16CE75755D8DC04F
Apr 12 13:35:57 hostapd: wl2.1: STA 34:10:be:ef:22:27 WPA: pairwise key handshake completed (RSN)
Apr 12 13:35:57 dnsmasq-dhcp[6784]: DHCPREQUEST(br0) 10.10.10.55 34:10:be:ef:22:27
Apr 12 13:35:57 dnsmasq-dhcp[6784]: DHCPACK(br0) 10.10.10.55 34:10:be:ef:22:27 Dragon
Apr 12 13:35:59 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=60:cf:84:fa:df:60:f8:c0:01:7c:9d:cc:08:00 SRC=45.205.1.110 DST=174.28.34.169 LEN=40 TOS=0x00 PREC=0x00 TTL=242 ID=54321 PROTO=TCP SPT=50451 DPT=8728 SEQ=1931122781 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0x8000000

 

[killweav]

I checked my stock ASUS BE92U HW v3 media bridge and saw that it updated to the 3.0.0.6.102_39061 firmware last night based on the schedule I set. I agreed to the new EULA and went into the system log for the media bridge. I could see wlceventd service start messages every time it rebooted. Until this FW update. I cleared logs, rebooted again after the FW update and search finds no wlceventd messages whatsoever. I've made a submission to ASUS through the stock firmware of that media bridge. I couldn't find an appropriate section so I chose Others.

I guess this is a wait and see from ASUS type of thing.

PS: I also checked the logs for my ASUS RT-AX55 media bridge running 3.0.0.4.386_53327 and can clearly see the wlceventd service start messages upon boot. Thankfully this router hasn't been hit by whatever FW changes make these disappear (yet).

Jan 1 00:00:34 wlceventd: main(964): wlceventd Start...

 

[killweav]

Creating new thread to eliminate confusion with Scribe. This isn't an issue with Scribe after all.