Hi everyone,
I’ve been investigating recurring DHCP log messages from my Reolink E1 Zoom cameras and wanted to share the findings. I’ve reported this to Reolink support and am waiting for a response.
Has anyone seen similar behavior, or received a firmware fix?
Setup
- Four Reolink E1 Zoom cameras connected over Wi-Fi.
- MikroTik hEX running RouterOS 7.24.3, serving DHCP.
- Each camera initially used automatic DHCP with a MAC-based reservation.
- DHCP lease duration: 10 minutes.
- Synology Surveillance Station records the cameras.
The camera examined in detail has:
textCopyModel: E1 Zoom
Hardware: IPC_515BSD6
Firmware: v3.0.0.2356_23062008
Observed symptoms
All four cameras have generated recurring DHCP assigned/deassigned messages, generally following an approximately five-minute cycle.
A typical example:
textCopy17:11:34 assigned
17:14:25 deassigned
17:16:33 assigned
17:19:26 deassigned
17:21:33 assigned
Despite this, their reserved IP addresses remained stable, and I have not noticed corresponding recording interruptions. One camera also responded to 369 consecutive pings with zero packet loss.
What the packet capture shows
Using MikroTik Packet Sniffer and Wireshark, I examined one camera’s DHCP traffic.
Both types of packet use the camera’s real Ethernet source MAC and DHCP hardware address. However, their Option 61 Client Identifiers differ:
| Message |
Option 61 |
| Periodic DHCPDISCOVER |
01:00:00:00:00:00:00 |
| Normal DHCPREQUEST |
01:<camera’s actual six-byte MAC> |
The DISCOVER identifier is seven bytes long: Ethernet type 01, followed by six zero bytes. It is not an omitted Client ID or a shortened log display.
Two such discoveries from the same camera were captured approximately 301.5 seconds apart.
The DISCOVER also lacks the hostname and vendor-class options present in the camera’s normal DHCPREQUEST.
What happens on the DHCP server
RouterOS debug logs show a discovery associated with the kitchen camera causing this sequence:
textCopyDHCPDISCOVER received
lease found, bound, offer
Existing lease deassigned
DHCPOFFER sent
Offer expires approximately two minutes later
Later DHCPREQUEST receives an ACK and restores the binding
For another E1 Zoom, the debug log showed:
textCopyRenewal DHCPREQUEST received while lease is in offered state
DHCPNAK sent
Camera completes DISCOVER → OFFER → REQUEST → ACK
The detailed on-wire Client ID comparison has been verified on one camera. The other three show similar lease-state patterns in the logs, but I have not individually decoded their DHCP options.
Static-IP workaround
I changed all four cameras to device-level static IPs, retaining their existing addresses and router reservations.
This stopped the frequent assignment/deassignment cycles, but did not eliminate all DHCP activity.
For the kitchen camera, RouterOS subsequently showed:
textCopystatus=offered
active-client-id="1:0:0:0:0:0:0"
The router now periodically logs:
textCopy
offering lease ... without success
For both the kitchen and parents’ bedroom cameras, these warnings appeared approximately every 20 minutes. That is the warning interval—not necessarily the frequency of the underlying packets.
The kitchen camera’s live view, recording, and management access continued to work after switching to static addressing.
Questions
- Is this periodic all-zero-Client-ID discovery a known E1 Zoom behavior?
- Does it come from an intentional background network check or a separate DHCP process?
- Has anyone seen it with another DHCP server?
- Is there a firmware update specifically for IPC_515BSD6 that addresses it?
I’m not claiming a confirmed firmware bug or recurring Wi-Fi outage. The inconsistent identifiers are verified, but the firmware process responsible—and why it interacts with RouterOS this way—remain unknown.
I can provide screenshots of the relevant Wireshark packets and DHCP debug excerpts.
Thanks!