ISP Comcast WANs failing on DHCP lease modifications
-
I recently identified a cause of dropping WAN connections. Likely exclusive to Comcast customers that use DHCP and have the modem in bridge mode. Perhaps the failure is only seen if the customer uses the 2g down -200k up plan. The bug occurs regardless of the modem manufacturer (tested 3 of XB8s and 4 different CODA56 modems, so it appears not to be a modem issue but maybe some combination of their profiling, or their gateways or DHCP servers).
In my Netgate 6100 (running Version 23.09), if the WAN’s DHCP lease time is changed (modified using "supersede dhcp-lease-time x") from what the server/modem assigned, then precisely at the 50% point of the lease, the monitoring of the WAN’s status will no longer receive replies (such as ping test to 8.8.8.8), and the router will consider the port failed. The WAN connection will come back online when only one of these events occurs: (a) manually release/renew the DHCP; (2) the lease expires and renews; (3) the Port is unplugged/replugged; (4) WAN is disabled/re-enabled; or (5) reboot of the router or the modem is done.
The up/down of the WAN will cycle at the time set for the lease, with 1/2 being up and the other 1/2 down. Reducing or increasing the cycle time of sending ARPs does not change the cycle or results.
Also, I found another bug that sometimes causes WANs to switch into "Pending" status and not always return to online or offline if the connection is a DHCP. Happens when unplugging/replugging cable from router to the modem or if the modem is power cycled. Appears to be an issue of the process dpinger.
-
@halp It’s a discussion if this is really a bug, because it’s caused by your ISP trying to make life impossible for customers that does NOT use their firewall/router. I have the exact same issue with an ISP in France.
If my own router does not follow the DHCP lease times given exactly, the ISP will stop passing traffic all together until a completely new DHCP Discover/offer/accept is completed. The annoying thing is that they assign lease times around 80 - 90K secs, (around one day), and that means that any issue on the ISP side that does not bring the actual link down, causes WAN to be unavailable until the WAN DHCP lease completely times out, and pfSense does a real DISCOVER (starting over instead of renew). (Or I do it manually like you)That’s because the ISP’s box will abandon it’s valid DHCP lease if its built-in WAN dpinger looses connection with its gateway. It will start a endless loop of doing full DHCP DISCOVER again. This is the ISP’s way of doing “login” to their services.
Whereas pfSense will do nothing as long as the actual link does not drop. In pfSense if dPinger looses its gateway, it will restart some services, but it will not do anything DHCP related on WAN as long as the DHCP lease is valid and link has not been lost.What we need is the ability to ask pfSense to release its DHCP lease and start anew (dhclient) on WAN as a gateway action when dpinger looses its gateway.
-
@keyser just chiming in here, I believe I have exactly the same issue (based on the observed symptoms) here in Belgium with my ISP.
-
K keyser referenced this topic on
-
settings that function as-configured are not "bugs."
-
@cyberconsultants
Which issue? I described a number them.
I don't think they intended for the connection to cycle (working then fail 1/2 the client time).
hp
