Cannot bind IP - "This entry already exists."

[pgershon]

I am using an ASUS GT-AX6000 with the latest Merlin firmware running. I have 131 manually assigned IPs, and many other static IPs on my network. I have three devices that are getting DHCP assignments from the DHCP server that I cannot customize. When I add the IPs to the list of manually assigned IPs, they seem to get listed. But my devices will not give up the initially assigned IP addresses. I have tried reseting the devices themselves but the IPs will either not release, or when I do manage to get them released, the devices get a newly DHCP assigned IP and not the manual one I specified. Also, when I go to the Network Map, find the device and try to manually bind the IP, I get the message "This entry already exists", even if I first remove the manual assignments of those devices. It is like something invisible to me is already reserving those IP addresses and I am unable to release them. I have spent several hours fighting with my network today and completely struck out. These devices had at one time been assigned to other devices, but those devices were re-configured as static IP devices, initially with that IP but subsequently using a different IP. For whatever reason, the IP's I want to reassign are not being released.

Any ideas? Thanks in advance.

 

[eibgrad]

I assign almost everything via DHCP, both dynamic and static leases. It just makes it a lot easier to manage. And I *never* use the GUI. It's tedious, limited in how many static leases you can create, limited to only one (1) MAC address per device, and a pain to migrate to new firmware during a clean upgrade.

Instead, create your own dhcp-host and host-record directives in DNSMasq using a dnsmasq.conf.add file.

#!/bin/sh
CONFIGS_DIR='/jffs/configs'
CONFIG="$CONFIGS_DIR/dnsmasq.conf.add"

mkdir -p $CONFIGS_DIR

create_config() {
cat << 'EOF' > $CONFIG
# dhcp static leases
dhcp-host=00:00:00:00:00:00,192.168.1.11,hostname11,24h
dhcp-host=00:00:00:00:00:00,192.168.1.12,hostname12,24h
dhcp-host=00:00:00:00:00:00,192.168.1.13,hostname13,24h
dhcp-host=00:00:00:00:00:00,192.168.1.14,hostname14,24h
dhcp-host=00:00:00:00:00:00,00:00:00:00:00:00,192.168.1.15,hostname15,24h

# dns records for dhcp static leases
host-record=hostname11,hostname11.<domain>,192.168.1.11
host-record=hostname12,hostname12.<domain>,192.168.1.12
host-record=hostname13,hostname13.<domain>,192.168.1.13
host-record=hostname14,hostname14.<domain>,192.168.1.14
host-record=hostname15,hostname15.<domain>,192.168.1.15
EOF
}

if [ -f $CONFIG ]; then
    echo "error: $CONFIG already exists; requires manual installation"
else
    create_config
    echo 'Done.'
fi

It will obviously take some effort to configure for the first time, but it will make your life so much easier in the long run. Specify your own MAC addresses and replace <domain> w/ your own domain. I recommend having your static leases defined *outside* the DHCP range.

Notice you can specify *multiple* MAC addresses per device, which comes in handy when a device has multiple network interfaces (e.g., wired and wireless). You just have to make sure only *one* of those network interfaces is active at any given time.

After making your changes to the script, enable "Enable JFFS custom scripts and configs" under Administration->System, then copy/paste it into an ssh terminal window and it will create the file. Then reboot.

The GUI is fine for a handful of static leases, but totally impractical when dealing w/ anything much larger. You're just better off managing it yourself.

 

[pgershon]

Thanks. But how do I locate the cause of the IP's that system says are "in use"? 192.168.1.192, 192.168.1.193 and 192.168.1.194? Best I can tell, no device is using these IPs but the system, wont let me reassign. These IPs were used (by static IP devices) until about 2 weeks ago, when I reassigned their IPs address to numbers in the 180s, and the new device numbers interact fine. I just can't clear the flag that 192.168.1.192, 192.168.1.193 and 192.168.1.194 are in use.

 

[eibgrad]

The reason I suggested what I did is to NOT have to deal w/ these kinds of problems. You avoid conflicts if you centralize management using DHCP, and ideally, using your own directives. It's crazy to be manually configuring 131 individual devices! That's how you end up in the situation you're now facing. IMO, it's just a waste of time trying to track down these specific offenders if your overall strategy is poor.

 

[pgershon]

But how do I release what is already taken? Let's assume I start from scratch as you suggest, I still must clear the existing devices, including the phantom ones.
Is there a way to look at my current assignment list, in total? I think I want to examine dnsmasq.conf, but I could be confused.

 

[pgershon]

Just to add, I can look at DHCP leases in the ASUS GUI and these IPs are not listed.

 

[pgershon]

Bumping this. I realize the suggestion that came in was to create my own DHCP server which makes sense in long term, but for now I would like to free up those three ghosted IP addresses. the ASUS router thinks 192.168.1.192-4 are in use or "reserved" but I cannot find anything that would be reserving them. There were a few devices that used 192,193 and 194 as static IPs, but they are now using different addresses. But how do I release or resent the ASUS's use of IP addresses? Short of doing a complete reset of the router.

 

[eibgrad]

But how do I release or resent the ASUS's use of IP addresses? Short of doing a complete reset of the router.

By reconfiguring DHCP as suggested.

This should NOT require a total reset of the router. Just make sure to delete an DHCP reservations you may have created in the GUI. I don't believe any active leases will be preserved across a reboot. Upon reboot, as long as you have your devices NOT using manually assigned IPs, but only DHCP, and have DHCP configured as suggested, it should fix itself. But trying to manually track down a handful of rogue IP assignments given your current situation seems much harder. Esp. since only YOU have access to the network for such investigative purposes.

Bite the bullet, reset DHCP and your devices approproiately, and get past the issue.

 

[W3Wilkes]

I'm guessing the GT-AX6000 must allow more than the 128 reserved addresses like in the RT-AX68U? I do find it interesting that you have 3 ghosted items which corresponds to 128+3=131. My AX86U only allows 128 reserved addresses and I'm also an advocate of reserved IP's being outside the range defined for the DHCP pool; IE; my DHCP range is defined as IP 32 through 254 with all my reserved IP's in the 2 through 31 range.

 

[pgershon]

By reconfiguring DHCP as suggested.

This should NOT require a total reset of the router. Just make sure to delete an DHCP reservations you may have created in the GUI. I don't believe any active leases will be preserved across a reboot. Upon reboot, as long as you have your devices NOT using manually assigned IPs, but only DHCP, and have DHCP configured as suggested, it should fix itself. But trying to manually track down a handful of rogue IP assignments given your current situation seems much harder. Esp. since only YOU have access to the network for such investigative purposes.

Bite the bullet, reset DHCP and your devices approproiately, and get past the issue.

I dont know why, but these leases were reserved after reboot as well. Just those thee IP addresses. And to clarify, these IPs were never reserved - they were at one time static IPs used / specified by Shelly devices. And those Shellys now use a different IP.

 

[pgershon]

Problem solved for anyone with same issue who may be looking:

I found the problem. NVRAM dhcp_staticlist had all the bad IPs. Not sure how it got there. Fixed with:

nvram set dhcp_staticlist="" fixed it