I love my Synology, the recent controversies notwithstanding. One of the many uses I have for my RS1221+ is using Log Center to receive syslog messages from all of my Ubiquiti networking equipment, among other sources.

Background

UniFi APs (notably the U7 Pro Wall) emit kernel-level Wi-Fi driver messages like this:

kernel: wlan: [0:F:OBJMGR] wlan_objmgr_iterate_log_del_obj_handler:
#peer in L-state,MAC: 96:d3:62:76:f7:24

UniFi tags these as severity “emerg”, which causes Synology Log Center to dutifully notify me as if something catastrophic just happened.

Seems serious right? Well, some quick work with ChatGPT and I found the following explanation for the message:

This is coming from the Qualcomm Wi-Fi 7 (802.11be) driver running on the U7 Pro Wall.
Translated:
#peer = a connected Wi-Fi client
L-state = Link teardown state
The AP believes the client connection should already be gone
But the client is still “half-present” in the driver’s object manager

This is a client-roaming / power-save edge case, not packet loss, not RF failure, and not a VLAN issue.

Why Apple devices trigger this more than anything else
Apple clients aggressively use:
802.11k / v (neighbor reports + fast roaming)
802.11r (Fast BSS Transition)
U-APSD power save
Opportunistic band switching
Very short dwell times when moving or screen-locking

So, TL;DR, you can safely ignore this message as it's expected behavior as the iOS devices will disconnect whenever you lock a screen or pretty much anything else, but the UniFi network won't like those short durations and half-open connections. Not sure why the kernel in the U7 Pro Wall devices is logging that as an emergency, but there you have it.

So, next step, how do I stop it from coming into my Synology Log Center and filling my email with these everytime someone locks their phone? Well, that turns out to be harder than you'd think.

Filtering the Log

At first, this seemed like a simple task as there are lots of tutorials about doing custom filtering within Log Center. It turns out; however, that all of those tutorials are written for Disk Station Manager 6.x and lower, I'm on Disk Station Manager 7.x. Seems Synology has permanently crippled DSM 7 with regards to Log Center. You can no longer filter, you can no longer change notification preferences, it's pretty limited now. That wouldn't be a big deal, except there really aren't any other solutions unless you want to roll your own on the Synology (like with Loki and Grafana; no thanks).

I pulled out my trusty minion and we set off trying to investigate how we could do it normally within DSM 7, without too much difficulty, which turned out to be difficult, for the following reasons:

  • DSM 7 does not support content-based log filtering in Log Center
  • Notification rules are global and coarse
  • UniFi syslog severity levels are… enthusiastic
  • Synology Log Center runs its own syslog-ng instance, separate from the system one
  • Much of Log Center’s real configuration is dynamically included from directories misleadingly named patterndb.d

So the fix has to happen inside Log Center’s syslog-ng pipeline, before messages are persisted or trigger alerts.

Step 1: Identify the Real Syslog Receiver

Log Center listens for remote syslog on UDP/514. The actual receiver is defined here:

/var/packages/LogCenter/target/etc/syslog-ng/patterndb.d/pkg-LogCenter-recvrule.conf

Inside that file you’ll find the relevant source definition:

source s_syno_ietf_IETF_UDP_514 {
    syslog(
        ip("0.0.0.0")
        port(514)
        transport(udp)
        ...
    );
};

This is the ingestion point we want to hook.

Step 2: Create a Drop Rule at Ingest Time

Because Log Center’s main config includes everything in its patterndb.d directory, the cleanest approach is to add a new config fragment there.

Create the following file:

/var/packages/LogCenter/target/etc/syslog-ng/patterndb.d/00-drop-unifi-objmgr.conf

(Using 00- ensures it’s evaluated early.)

Contents

# Drop noisy UniFi kernel WLAN OBJMGR peer cleanup messages

filter f_drop_unifi_objmgr {
    message("wlan_objmgr_iterate_log_del_obj_handler");
};

destination d_null { file("/dev/null"); };

log {
    source(s_syno_ietf_IETF_UDP_514);
    filter(f_drop_unifi_objmgr);
    destination(d_null);
    flags(final);
};

Key points:

  • We match on the stable function name, not severity
  • We drop the message at the receiver
  • flags(final) prevents the message from flowing into any downstream Log Center pipelines (storage, alerts, DB)

Optional hardening: you can scope this further by hostname if you want to ensure it only applies to a specific AP.

Step 3: Validate and Restart Log Center

Before restarting anything, always validate:

/var/packages/LogCenter/target/usr/bin/syslog-ng \
  -s --cfgfile=/var/packages/LogCenter/target/etc/syslog-ng/syslog-ng.conf

If the syntax check passes, restart Log Center:

synopkg restart LogCenter

Step 4: Test Correctly (This Part Matters)

If you test from the Synology itself, you’ll get misleading results as it will take the local pipeline and not the syslog pipeline. Also, macOS and BSD logger do not send remote syslog, even if you think they do.

To test properly, send a real UDP syslog packet from another machine. On macOS (since logger is broken), you can do it with 'nc':

echo '<0>kernel: wlan: [0:F:OBJMGR] wlan_objmgr_iterate_log_del_obj_handler test' \
| nc -u -w1 <NAS_IP> 514

On a raspberry pi it would look like:

logger -n <NAS_IP> -P 514 -d -t kernel 'wlan: [0:F:OBJMGR] wlan_objmgr_iterate_log_del_obj_handler: #peer in L-state,MAC: 96:d3:62:76:f7:24'

When tested this way, the message is successfully filtered and never appears in Log Center. Just to confirm, you should also try additional messages and those should come through normally.

This will confirm the rule is working on the actual ingestion path used by UniFi devices.

Important Notes (Read This Before a DSM Update)

  • Anything under /var/packages/.../target/ may be overwritten by package updates
  • Keep a copy of your custom .conf file elsewhere
  • Reapply it after Log Center upgrades if needed
  • This is unsupported by Synology—but it’s deterministic, minimal, and easy to restore

I consider that an acceptable tradeoff versus constant false “emergency” alerts.

Final Outcome

  • UniFi kernel WLAN noise: gone
  • Legitimate syslog messages: untouched
  • No port changes
  • No proxy syslog daemon
  • No alert fatigue

Synology Log Center remains what it is—a basic syslog sink—but with a little careful plumbing, it can be made to behave like a grown-up.

If you’re running UniFi gear and using Log Center, this is one of those fixes that pays dividends every single day.