DGS-1210-10P rev F3 + OpenWrt: keeping PoE powered when realtek-poe can't drive the PSE

Hardware Questions and Recommendations
1

Device: D-Link DGS-1210-10P, hardware revision F3 (Realtek RTL8380 + RTL8238B PoE controller)
OpenWrt: 25.12.x, realtek/rtl838x target
Role: dumb/managed VLAN switch powering HikVision PoE cameras + a UniFi AP

TL;DR

On the F3, realtek-poe cannot properly talk to the PoE controller (constant bad checksum / Invalid port (port=97) / num_detected_ports=255 spam, no per-port control). I was advised (by AI) to stop and disable the service to kill the log spam. That works right up until your next cold power-cycle, after which the PoE chip comes up OFF and, with the daemon disabled, nothing ever switches it back on, so all your PDs go dark.

The fix that worked for me: leave the poe service ENABLED on boot (starting it latches the PSE on, despite the checksum errors), and use a small /etc/rc.local job to stop it ~60s after boot so the log spam goes away while the power stays latched.

Background / the trap

realtek-poe on the F3 spams the log because it speaks the wrong protocol to the PoE MCU. So, like some others, I did:

/etc/init.d/poe stop
/etc/init.d/poe disable

PoE kept working and the spam stopped. Great. But it was a trap: the PSE was only still powered because it had been latched on earlier (by the stock firmware / a previous daemon run), and the PoE MCU holds its state across warm reboots but loses it on a real power cut. The MCU is volatile.

I only found this out after physically relocating the switch (= a cold power-cycle). It came back with every PoE port dead, and because the daemon was disabled there was no longer anything to switch the PSE on. A link check showed no PD power on any port.

The key finding

Even though realtek-poe on the F3 throws checksum errors and can't do per-port control, the act of starting the daemon latches the PSE on. Confirmed cleanly:

  • After the cold boot (PSE off), /etc/init.d/poe start brought a UniFi AP and a camera straight back to life.
  • The power then PERSISTS after the daemon is stopped - it survived /etc/init.d/poe stop, moving the PD between ports, and hard power-cycling the PD itself.

So the daemon only needs to run briefly at each boot to latch power. After that it is just generating noise.

The fix

  1. Make sure the service is enabled at boot:
/etc/init.d/poe enable
/etc/init.d/poe start
  1. Add a delayed auto-stop to /etc/rc.local (above exit 0). It backgrounds itself so boot is not stalled, waits for the PSE to latch, stops the daemon, and logs what it did:
(
    sleep 60
    if ps w | grep realtek-poe | grep -v grep >/dev/null 2>&1; then
        logger -t poe-autostop "poe running after boot, stopping it to silence realtek-poe spam (PoE stays latched)"
        /etc/init.d/poe stop >/dev/null 2>&1
        sleep 3
        if ps w | grep realtek-poe | grep -v grep >/dev/null 2>&1; then
            logger -t poe-autostop "WARNING poe still running after stop"
        else
            logger -t poe-autostop "poe stopped, PoE power remains latched"
        fi
    else
        logger -t poe-autostop "poe was not running at the post-boot check"
    fi
) &

Now every boot - including a cold one - self-heals: poe starts and latches the ports on, then gets stopped 60s later and the spam stops. Power stays up the whole time.

Optional: silence the residual boot-burst in your logs

You still get ~60s of spam at each boot. If you forward to a central syslog (I use syslog-ng), drop it by program name there, and keep your own poe-autostop breadcrumbs (different program name):

filter f_poe_spam { program("realtek-poe"); };

log {
    source(s_network);          # your network source
    filter(f_poe_spam);
    flags(final);               # match = drop, stops further processing
};

Place that drop log{} above your main storage log{} so it is consumed first.

Caveats / notes

  • This is specific to rev F3 (Realtek PSE). I believe that on F1/F2 (Broadcom PSE) realtek-poe works properly and none of this is needed.
  • No per-port PoE control or power reporting - it is all-or-nothing latching. Fine for a dumb switch; not if you need to power-cycle individual PDs from the switch.
  • 802.3af/at detection still happens in PSE hardware, so non-PoE devices on the powered ports are not at risk.
  • Do not reflash stock to "fix" it - same MCU firmware, and the F3's signed-image bootloader makes recovery a faff (serial + U-Boot to get OpenWrt back).

Hope this saves someone the "why did all my cameras die after a power cut" head-scratch I had.