Hey everyone.
I have a strange and persistent problem. I have a Brume 3 as my main router which also handles all DHCP.
Now I got a Mango v2 which runs in Repeater/ Bridge mode to bring a printer to the Wifi.
Problem now is, that the brume assigns the mango an IP address which is already in use. And it does that repeatedly. I did numerous factory resets on the mango etc.
Now I could assign a static IP manually. But I would rather find out were that problem is rooted.
I’ll attach a screenshot from the client list. The shelly is also automatically assigned by the brumes DHCP server. But as soon as I plug in the mango it gets assigned the same IP and the resulting IP address conflict makes both devices unreachable.
Bot devices run the most up to date firmware
Hi,
Thank you for the information.
It is unusual for two devices with different MAC addresses to be assigned the same IP address by the same DHCP server.
Could you please perform the following checks on the Brume 3?
While the Mango is disconnected and the Shelly device is working normally, please SSH into the Brume 3 and run:
cat /tmp/dhcp.leases | grep -iE '192\.168\.1\.129|ec:c9:ff:e7:9d:54|96:83:c4:08:75:26'
Then connect the Mango again. Once the IP conflict occurs, please run the same command again and send us both results.
Could you please check whether there is any static DHCP binding related to this IP address or either device. Please run:
uci show dhcp | grep -iE '192\.168\.1\.129|ec:c9:ff:e7:9d:54|96:83:c4:08:75:26'
Could you please confirm which DHCP address Brume 3 actually provided to Mango when it connected? Please run the following:
logread -f | grep -E 'dnsmasq-dhcp|DHCPDISCOVER|DHCPOFFER|DHCPREQUEST|DHCPACK|DHCPNAK'
While this command is running, please reconnect the Mango and wait until the IP conflict appears, then copy the related DHCP output for us.
Thank you for your understanding and cooperation.
1 Like
First output with only the shelly connected:
root@GL-MT5000:~# cat /tmp/dhcp.leases | grep -iE '192\.168\.1\.129|ec:c9:ff:e7:9d:54|96:83:c4:08:75:26'
1787098768 ec:c9:ff:e7:9d:54 192.168.1.129 shellypro3em-ecc9ffe79d54 01:ec:c9:ff:e7:9d:54
The second output:
root@GL-MT5000:~# cat /tmp/dhcp.leases | grep -iE '192\.168\.1\.129|ec:c9:ff:e7:9d:54|96:83:c4:08:75:26'
1787098768 ec:c9:ff:e7:9d:54 192.168.1.129 shellypro3em-ecc9ffe79d54 01:ec:c9:ff:e7:9d:54
Which is kind a surprise because these are the screenshots I took at the same time:
The interface of the brume
(Here should be the screenshot of the interface of the mango, but as a new user I can only upload one embedded screenshot, but the mango also show .129 as its IP)
Here ist the logread.
root@GL-MT5000:~# logread -f | grep -E 'dnsmasq-dhcp|DHCPDISCOVER|DHCPOFFER|DHCPREQUEST|DHCPACK|DHCPNAK'
Tue Aug 18 18:23:43 2026 daemon.info dnsmasq-dhcp[23663]: DHCPDISCOVER(br-lan) 96:83:c4:08:75:26
Tue Aug 18 18:23:43 2026 daemon.info dnsmasq-dhcp[23663]: DHCPOFFER(br-lan) 192.168.1.117 96:83:c4:08:75:26
Tue Aug 18 18:23:43 2026 daemon.info dnsmasq-dhcp[23663]: DHCPREQUEST(br-lan) 192.168.1.129 96:83:c4:08:75:26
Tue Aug 18 18:23:43 2026 daemon.info dnsmasq-dhcp[23663]: DHCPNAK(br-lan) 192.168.1.129 96:83:c4:08:75:26 address in use
Just for completion the output for the static route which is none
root@GL-MT5000:~# uci show dhcp | grep -iE '192\.168\.1\.129|ec:c9:ff:e7:9d:54|96:83:c4:08:75:26'
root@GL-MT5000:~#
Hi,
Thank you for the additional information.
From the DHCP log, the Brume 3 actually offered 192.168.1.117 to the Mango, while the Mango requested 192.168.1.129 , which was then rejected by the Brume 3 with DHCPNAK ... address in use .
Tue Aug 18 18:23:43 2026 daemon.info dnsmasq-dhcp[23663]: DHCPDISCOVER(br-lan) 96:83:c4:08:75:26
Tue Aug 18 18:23:43 2026 daemon.info dnsmasq-dhcp[23663]: DHCPOFFER(br-lan) 192.168.1.117 96:83:c4:08:75:26
Tue Aug 18 18:23:43 2026 daemon.info dnsmasq-dhcp[23663]: DHCPREQUEST(br-lan) 192.168.1.129 96:83:c4:08:75:26
Tue Aug 18 18:23:43 2026 daemon.info dnsmasq-dhcp[23663]: DHCPNAK(br-lan) 192.168.1.129 96:83:c4:08:75:26 address in use
Since the Mango UI still shows 192.168.1.129 , could you please check whether this is a display/state synchronization issue or whether the Mango is actually still using that IP address.
When the issue occurs again, SSH into mango and run:
ip -4 addr
ip -4 route
Please also check whether the Mango itself still has network connectivity at that time, for example by pinging the Brume 3 and a public IP address.
ping -c 4 192.168.1.1
ping -c 4 8.8.8.8
Could you please also provide the related DHCP client log from the Mango to see what it does after receiving the NAK:
logread | grep -iE 'udhcpc|DHCP|NAK|bound|lease|deconfig'
Thank you for your understanding and cooperation.
I would love to test it further. But after being connected for some time the mango now gets assigned or takes the IP *.106. And that IP really is free and inside my DHCP range. Even after resetting and deleting all old dhcp releases from the brumes tables I can’t get it to repeat the problem.
Hi,
Thank you for the update.
Glad to hear that everything is now working normally. It looks like the previous issue may have been caused by the Mango retaining or requesting an already-used IP address during one of the DHCP exchanges, which resulted in the temporary IP conflict.
