Apparently I'm not the first to complain about FreeBSD's sub-par dhclient regarding this issue.

https://www.reddit.com/r/PFSENSE/comments/1wvoh7/wan_dhcp_release_issue/
https://forum.pfsense.org/index.php?topic=52608.0
https://forum.pfsense.org/index.php?topic=68396.0
https://twitter.com/search?f=tweets&vertical=default&q=pfsense%20dhcp%20release&src=typd
https://redmine.pfsense.org/issues/4209

SIGH! ISC dhclient is long overdue… oops.

Okay, I played around with the copy if ISC's dhclient that seems to be sitting on pfSense 2.3 beta.
It's executable binary and script are in: /usr/local/sbin
It's DHCP lease file is: /var/db/dhclient.leases
It's configuration file is: /usr/local/etc/dhclient.conf

It's default config has a bunch of examples that supersede and prepend the lease you get by adding additional domain-name and dns servers, so I just erased the config and wrote my own clean one.

Also the default-lease it asks the DHCP server for is way to low: send dhcp-lease-time 3600; So I changed it to 7 days, 604800.

I killed the FreeBSD dhclient processes that were running by kill -9'ing them.

ISC's dhclient works, but pfSense doesn't appear to pick up the new IP and refresh the rules or whatever the protocol is for that.
I'm able to get an IP and it configures the interface just fine.
/usr/local/sbin/dhclient -v -i em0 - Obtains an IP and sets it to the interface, I use -v verbose to watch what it's doing, might be a good idea to redirect that via > to the correct log spot for DHCP?
And to release I do /usr/local/sbin/dhclient -v -i em0 -r and it sends the correct DHCPRELEASE packet and removes the IP from the interface.
[2.3-BETA][root@venom.gtaxl.net]/usr/local/sbin: ./dhclient -v -i em0 -r
Killed old client process
Internet Systems Consortium DHCP Client 4.3.3-P1
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on BPF/em0/08:00:27:88:45:55
Sending on  BPF/em0/08:00:27:88:45:55
Sending on  Socket/fallback
DHCPRELEASE on em0 to 10.0.0.101 port 67

It will ask the DHCP server for the same IP if it sees the previous lease from the dhclient.leases file. So if you want the same IP back keep the lease file. If you want a different IP, issue a release, delete the file, then renew. If you delete the lease file before you release'd ISC won't release.

So, in conclusion, please start whatever process to get this on the roadmap. If you do, I request that you give us ability to configure everything via the web gui that would be in the dhclient.conf.

Keep the protocol timing options, but allow us to specify what DHCP lease time we ask the DHCP server, if we don't specify one, exclude the line from the dhclient.conf and we'll respect the DHCP server's default lease time. A lease time of 7 days would be configured like this in dhclient.conf: send dhcp-lease-time 604800;

Also give us the option to choose one of the 3 when the dhclient asks for an IP.

Ask the DHCP server for our same/old IP that's in the lease file, makes it so our IP stays static. To do this, don't delete the lease file. Ask the DHCP server for a new random IP. To do this delete the lease file right after a release, then renew. Allow us to explicitly set what IP we want to request from the DHCP server. This would be DHCP option 50, you would set it in dhclient.conf like this: send dhcp-requested-address 192.168.1.240;
I know I know, this could be dangerous, warn the user in the descriptive text. But for people that know what they're doing, like me, will enjoy this. I can basically ask for an IP address from my ISP such as 74.5.69.69 and be bad-ass. Assuming it's available and in the DHCP things will work, if not available the DHCP server just denies the request and we get a random IP.. And yes I know, you have to know what your ISP's DHCP pool is a head of time, like I said this is for people that know what they're doing.

There are a lot of things you can configure in dhclient.conf and I hope the web gui will at least implement what I have said, I see you allow the option for a configuration override and appreciate that a lot. I hope that if and when you switch to ISC you'll have the same options as well as what I asked.

Anyone please help me!

Hi,

Apply latest 2.3 Beta, problem fixed !
Maybe the card itself hangs, i don't know really what's happen.

Thanks.

Nicolas

I was just working on part of LDAP the other day on 2.3 and it worked fine, even the LDAP OU picker worked. Though that was against OpenLDAP, AD can be a bit trickier, though I had that working recently as well.

Thank you  :)

That's for sysctls, not boot loader.

Well done, thanks jimp.

@cmb:

In that case you actually added a special character? That sounds like the password change on Dyn's side made it start working rather than anything to do with the contents of the password.

I also have a Asus RT-N65U (padavan fw) using the same DYN-Pro account (different hostname though) for two years that has worked fine lately while pfsense didn't. I also have three other (total four) virtual pfSense installations using four different hostnames, all fails the same. Either the uppercase or the exclamation did it. Dunno.

I know the DYN password was correct as I was able to log in to their site using the "wrong" password, but the "correct" credentials in pfSense failed. I have deleted and recreated the DDNS client entry numerous times in pfSense and thought… alzheimer? Phew... anyhow, it works with "special/upper" characters added.

The two others I was thinking of with wrapping actions are:

status_dhcp_leases.php
status_dhcpv6_leases.php

The v6 page especially since the actual text on the page overflows in some cases. IPv6 addresses tend to cause that sort of madness though :-)

IIRC it was from a long time ago when we had multiple buttons on the page that had the same name but submitted different values, so testing the value was needed. But over time that practice changed as we refined other parts. Testing the presence of the button may be enough now.

Thanks for the help!

I'll dig more into it on that side.

yes its working now thanks

This should be fixed now.

If I do it happened without my knowledge.  I've not installed anything from the packages.

Not sure why this value is displayed in text, while RAM, CPU etc are progress bars. I'll change it to a bar.

Pushed the update. Available now via gitsync, or wait for the next image.

Sorry, That's my fault yes it Works

Well, Does the new version will be ntop, bandwidth packages

@cmb:

Ok good. All fine here for you now chpalmer if you gitsync?

All good!  :)

WAN.jpg
WAN.jpg_thumb

Same thing with the traffic shaping not working properly with bridged interfaces  :(

I've been looking over the icon usage and in some cases it has been a bit confusing. See my current thread on the topic. It would be nice to have a consistent usage and presentation of enable/disable across all of the various rule types.

I'm not terribly crazy about the slider style in this context. With text around it, it's more clear, but with only a small icon and no context, it's not so simple.