DHCP Release

[rbngan]

This was discussed some time ago (http://forums.untangle.com/networkin...lease.html)and it appears it will not be a feature in UT. Here is my problem and maybe someone can walk me through how to release a DHCP lease. I have a Samsung TV joining the network and it was assigned a random internal DHCP. Since the TV needs to bypass the Web Cache, I set up a policy for TV's to be assigned to a rack that bypasses this base on it's IP address. I assign an IP based on the MAC into a pool of IP's for all the TV's on the network. The problem I have is that I've the TV initially picked up the internal public IP address and even though I've assigned it a static IP in the TV bypass range it is retaining the internal DHCP IP. In other words it has to have a static IP of x.x.x..26 and it is getting and retaining x.x.x.127. I've had the TV power cycled, turned off and on renewed on the tv end, pull the plug and it still picks up x.x.x.127. If I can delete x.x.x.127 from the DHCP list then it should force it to pick up x.x.x.26. mrunkel posted some commands to enter, but I am 160 miles from location and I don't understand where or if those commands will help. I've run into this before but not to this extent where unplugging would not relnew the DHCP on the devices. Any help in being able to release the a specific DHCP lease x.x.x.127 remotely would be helpful.

[sky-knight]

This problem, isn't a problem at all. The reason it's indicated it won't be "fixed" is because there is nothing to fix!

If you create a DHCP reservation for a device, when that device requests a new address it will get the reserved address. Regardless of what address it currently has.

The problem, is a ton of DHCP clients that don't follow RFCs and insist on using the address they already have. (Untangle can't fix this)

None of this is a "static IP", that's a term associated to when a device is manually configured and not using DHCP at all. In which case Untangle really has nothing to do with the IP configuration of the device anymore.

I don't understand why people over complicate this. You have a device, and it needs special treatment. So you make a rack for it, and you use policies to push the device's address into that rack. Why is it you insist on having a special range for it? Why not just make a quick reservation out of the lease that's already there, and make a policy rule to match the address assigned?


This path means you have one network, one set of security settings changed based on source address. Making a known range punch a hole in your defenses is simply creating something that can be exploited, and making more work for yourself while doing it. It makes no sense!

[rbngan]

This problem, isn't a problem at all. The reason it's indicated it won't be "fixed" is because there is nothing to fix!

I stand corrected. It is not broken so it does not need fixing. It is a feature I've used on other systems and would like it added to UT.

If you create a DHCP reservation for a device, when that device requests a new address it will get the reserved address. Regardless of what address it currently has.

The problem, is a ton of DHCP clients that don't follow RFCs and insist on using the address they already have. (Untangle can't fix this)

Thus that is why I would like to be able to remove the originally assigned lease from UT to help these client pick up the new lease.

None of this is a "static IP", that's a term associated to when a device is manually configured and not using DHCP at all. In which case Untangle really has nothing to do with the IP configuration of the device anymore.

Again I stand corrected. I meant to indicate I used UT to assigned IP via MAC not Static.

I don't understand why people over complicate this. You have a device, and it needs special treatment. So you make a rack for it, and you use policies to push the device's address into that rack. Why is it you insist on having a special range for it? Why not just make a quick reservation out of the lease that's already there, and make a policy rule to match the address assigned?

There are reasons to group the similar devices into ranges and free up the DHCP range I use for public access. Also UT support recommend I create the special rack for these devices. I'm sure I'm making this more complicated that it needs to be not because I want to but because this is the only way I can figure out how to make the SamSung TV devices work on the network since they can't play well with Web Cache and Captive Portal. If they are not turned off or bypassed then the TV will not work.

This path means you have one network, one set of security settings changed based on source address. Making a known range punch a hole in your defenses is simply creating something that can be exploited, and making more work for yourself while doing it. It makes no sense!

I don't know if allowing these particular TV devices through web cache and captive portal pose a real threat to our network. You are correct it is on one network and I would like to change that but have not figured out how to configure VLANS or other complex networking to separate the network uses. To complicate it more most of the network is run over WIFI network between several buildings separated by several hundred yards. To make this even more difficult, the site is 160 miles away and one wrong click shuts the site down and lock me out. I have to be sure of what a click will do before I start setting up VLANs. I volunteer for this organization and I've grown the network to the point where the learning curve may be too steep for me. One day I hope to meet someone that can help.

In the mean time we temporarily solved this particular issue by statically assigning the IP on the client TV and it passed to the proper rack and was able to access the web. I don't know if a DHCP release option would have worked but I would like to have tried it.

[sky-knight]

Thus that is why I would like to be able to remove the originally assigned lease from UT to help these client pick up the new lease.

You don't understand, the client once the reservation is made ISN'T ASKING FOR A NEW LEASE. It's simply keeping the old address. If it was asking for a new lease, Untangle would give it the new address. The old address will never be used because part of the DHCP lease process the server and client check to see if an IP address is in use, the DHCP server then marks it as "bad".

The DHCP client in the TV is broken, that's the problem. Untangle can't fix that. Don't believe me? Get out a packet sniffer and watch the DHCP transaction yourself. YOUR DEVICE, needs the release feature not Untangle.

[rbngan]

You don't understand, the client once the reservation is made ISN'T ASKING FOR A NEW LEASE. It's simply keeping the old address. If it was asking for a new lease, Untangle would give it the new address. The old address will never be used because part of the DHCP lease process the server and client check to see if an IP address is in use, the DHCP server then marks it as "bad".

The DHCP client in the TV is broken, that's the problem. Untangle can't fix that. Don't believe me? Get out a packet sniffer and watch the DHCP transaction yourself. YOUR DEVICE, needs the release feature not Untangle.

You are correct, I don't understand, there is a lot about this I don't understand. However, I think you are helping me understand this a bit more. Since it is the client that is the problem then it is the client that needs to be worked on, so assigning it a static IP was the correct solution?

What I don't understand is why does UT keeps the old IP in the active Current DHCP Leases list after I assigned it a new IP based on MAC address and the device had been turned off? So UT list the same MAC with two IP, the one I assigned via MAC and the one the devices was using listed under "Current DHCP Leases". It is now using the correct IP but not because it picked it up from UT, but because it was given a static IP. I agree the DHCP in the client must be having issues (new Samsung TV). How do I now have the IP that was original used by the TV become free to use by others?

As to getting out a packet sniffer, I would not know where to start and I believe you.

Thanks for helping me understand this just a bit more.

[sky-knight]

Untangle will track the lease until the lease expires. There's no easy way to delete a lease. But DNSMasq (the service that does DHCP and DNS in Untangle) will renew the lease as the client requests it. Should it refuse to do so? Possibly... but oddly enough that's part of the DHCP standard too.

And yes, the proper fix is to make it static. If you want a fully functional and configurable DHCP solution, Untangle simply doesn't provide it.