DHCP Client Issue
-
@xero9
From the symptoms you describe it sounds like you are hitting this bug https://redmine.pfsense.org/issues/9267Specifically, what happens is that if the DHCP client times out and there is any cached lease, pfSense will use said IP regardless of if it is valid or not for the remaining lease time.
However, if you are willing to compile dhclient and apply a patch using the pfSense system patch tool, it's pretty straightforward to fix this.
Rejecting the lease from the modem as mentioned earlier will also likely work. However the caveat to be aware of is if your modem loses upstream link when pfSense tries to renew the DHCP lease (small chance but not zero) you may lose your connection.
-
@nkaminski This sounds like my issue exactly!
So I'm no stranger to applying patches to file and re-compiling in say a Linux environment, but are there instructions on how I do this under pfSense? Is there a site with some documentation I can read? Thanks!
-
fyi: see also this thread for a workaround
https://forum.netgate.com/topic/127403/auto-renew-dhcp-after-outage -
My recommendation if you are new to building FreeBSD would be to prepare a "vanilla" FreeBSD 11.2 system/VM and then follow https://www.freebsd.org/doc/handbook/makeworld.html to verify you can build FreeBSD from source successfully. You don't need to actually install, just make sure you can successfully complete the process leading up to such.
Once you confident with building the unmodified source, apply the dhclient patch with arguments '-p1' from the referenced pfSense bug ticket to /usr/src and rerun make on your build host.
Then all you will need to do is copy the dhclient binary across to your pfSense host, reboot, apply the dhclient-script patch using the pfSense "system patches" package and you should be good.
Do also keep in mind that pfSense updates overwrite /sbin, therefore in my case I created a /patch folder containing a copy of the patched dhclient so that I can copy it into place after updates.
-
@johnpoz The specific problem we have here in Australia with NBN in particular is as follows:
After a power outage both the modem and pfsense reboot. (modem is a VDSL type)
pfsense is much faster at rebooting than the Modem is to sync up and allow pass through for the DHCP request:
NBN / FTTN Modem in passthrough mode. (so in this case its not the modem giving out a local DHCP addresss)Pfsense sees the ethernet WAN port come up - then requests a DHCP doesnt get it (modem stull doesnt have sync) and seems to give up and marks the port N/A and stops trying.
if at this stage you reboot pfsense its often OK
unplug/replug the WAN ethernet cable its often OK
WAN - release / reacquire a DHCP lease sometimes works. -
@timboau-0 said in DHCP Client Issue:
the specific problem we have here in Australia
Bad news, and good news : this problem is known all over the planet.
Instead of using Interfaces > WAN > "Reject leases from", go one line lower, check out what "Protocol timing" can do for you, add a 'delay' that works for you. -
@Gertjan
Thanks, I'll investigate and see how that goes - although I don't think its really addressing the root cause of the problem.While the delay function might work in this exact scenario I still don't feel a once of delay is the correct way to fix this problem. Sometime Sync can take longer than expected for example.
I would think if the WAN has a 0.0.0.0 or N/A IP address and set to DHCP it should be continually trying to obtain a valid IP address.
-
@timboau-0 said in DHCP Client Issue:
I would think if the WAN has a 0.0.0.0 or N/A IP address and set to DHCP it should be continually trying to obtain a valid IP address.
And thus hammering that WAN interface (network, because it's a broadcast) until the end of times ? That couldn't be the good default DHCP client behaviour neither.
It's a classic issue : on a network, the DHCP server should be running before clients are activated.What often happens is that the modem, slower as pfSense to start up, is handing over a LAN type, aka RFC 1918, for local management. Not good neither.
-
@timboau-0 Keep in mind that this is a bug (see links above). If you don't want to use the scripts, then wait for the release 2.5.0, which will likely include the fix.
-
@timboau-0 Exactly. The case you describe :"if the WAN has a 0.0.0.0 or N/A IP address and is set to DHCP it should be continually be trying to obtain a valid IP address" is exactly the behavior that this bug prevents.
Specifically, once dhclient times out, it will not retry for a potentially very long time; if you can share the dhclient logs (real IPs not necessary) from when you see the IP loss, we will be able to tell if this bug is indeed being triggered.
Hammering the WAN link with a large quantity of DHCP requests is also indeed bad, hence the implementation of an exponential backoff algorithm to mitigate this.