Hi everyone,
First of all, I hope it’s okay to post this here even though I’m not currently using an OpenWRT router (the router in question is a Huawei HG8245). I’m posting here because I believe the OpenWRT community has some of the most knowledgeable and experienced people when it comes to DHCP, embedded networking, and low-level IP behavior — and this issue definitely falls in that domain.
I’m working with a fleet of embedded devices (STM32 + CycloneTCP) connected via Ethernet. These devices use DHCP to acquire an IP address from the router.
The initial DHCP handshake works perfectly: DISCOVER → OFFER → REQUEST → ACK.
The problem appears after the router reboots:
• The router forgets the DHCP lease table
• Devices still hold onto their previously assigned IPs (which are valid)
• They continue to correctly function (connected to local MQTT broker with static IP)
• Devices continue to send Gratuitous ARPs and even DHCPINFORM
• But the router does not re-learn their MAC/IP bindings
• When a new device joins the network, the router may reassign the same IP already in use by one of the embedded devices, resulting in a IP conflict.
• If router restarts before T1 of the device(s), device will try RENEW (fails), then REBIND (fails) then the next step of the device is RE-INIT DHCP (succeeds), which causes the device to drop all connections of-course, even on the LOCAL net which is unwanted.
I’ve even tested a variation(s) where the embedded device:
• Sends a new DHCPDISCOVER
• Ignores the DHCPOFFER (with a different IP)
• Then sends a DHCPREQUEST for its current IP (which is still working on the LAN)
Still, the router allways either ignores the request or does not treat it as valid without a pre-existing RE-INIT DHCP lease record.
My Question:
-
What is the safest way for a client to reassert its IP after the router has lost state — without fully restarting its network stack or breaking ongoing TCP connections (e.g. MQTT)?
-
It appears to me that some routers silently ignore a lot of the protocol, and since I am not up-to-date for what practice is deprecated while still being documented...well.. I need your help 
I’d be grateful for any insight or suggestions — configuration tricks, patches, or even best practices from other embedded projects. Thanks in advance!
what you can and cannot do with your router, we can't tell, we know nothing about it.
you could however double NAT.
It appears you are using firmware that is not from the official OpenWrt project.
When using forks/offshoots/vendor-specific builds that are "based on OpenWrt", there may be many differences compared to the official versions (hosted by OpenWrt.org). Some of these customizations may fundamentally change the way that OpenWrt works. You might need help from people with specific/specialized knowledge about the firmware you are using, so it is possible that advice you get here may not be useful.
You may find that the best options are:
- Install an official version of OpenWrt, if your device is supported (see https://firmware-selector.openwrt.org).
- Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
- Provide the source code for the firmware so that users on this forum can understand how your firmware works (OpenWrt forum users are volunteers, so somebody might look at the code if they have time and are interested in your issue).
If you believe that this specific issue is common to generic/official OpenWrt and/or the maintainers of your build have indicated as such, please feel free to clarify.
2 Likes
Hi Frolic,
Many thanks for your reply.
As I stated in the beginning, this is NOT OpenWRT related, but it is (as I hope to be found by someone) - an interesting observation from our 1 week of debugging and sniffing a specific router behavior.
My hope is that some DHCP expert out there will have something/anything to say about common practice and possible workarounds about this kind of issues these days.
Update:
Observation from monitoring the router traffic, and defined behaviors:
After a router restarts: =================
- Router losses DHCP clients lease list table.
- Router Ignores clients DHCP-RENEW message.
- Router Ignores Grattitous ARP sent periodically from device.
- Router will only respond to DHCP DISCOVER from client, often giving an OFFER for IP it thinks its free (when it is not). In this case my device (client) makes ARP probe and DECLINEs the offer. If this continues, router will only give OFFER for the next "available" IP and if this in reality is also found to be in use, device DECLINES, and this (only two addresses) IP loop OFFER/DECLINE goes on forever....
Router will toggle between 2 addresses he thinks are free.
- If client requests its current (working) trying to maintain the same IP, router will also ignore it silently.
We hit a brick-wall here and don't know what else to try. Our devices need to be delivered out-there where we do not have control over the installations, meaning we cannot know what type of router will serve the DHCP. Of course we can always request devices to be assigned static IP but this rather awkward case is driving my OCD through the roof. It seems like a basic networking task is rendered unsolvable. I could also disregard the router being cheep, but this is an ISP provided equipment (optical input - router) so cannot change it easily, yet even if we do change it, we would like this mystery resolved anyway. If it means faulty router firmware, that will do, but our goal is to implement the best we can in our devices so they are capable to survive this kind of cases.
Any help is greatly appreciated, THANKS!