Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    ISP Comcast WANs failing on DHCP lease modifications

    DHCP and DNS
    4
    5
    366
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • H
      halp
      last edited by

      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.

      keyserK 1 Reply Last reply Reply Quote 0
      • keyserK
        keyser Rebel Alliance @halp
        last edited by

        @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.

        Love the no fuss of using the official appliances :-)

        A 1 Reply Last reply Reply Quote 1
        • A
          alainf @keyser
          last edited by

          @keyser just chiming in here, I believe I have exactly the same issue (based on the observed symptoms) here in Belgium with my ISP.

          1 Reply Last reply Reply Quote 0
          • keyserK keyser referenced this topic on
          • tinfoilmattT
            tinfoilmatt
            last edited by

            settings that function as-configured are not "bugs."

            H 1 Reply Last reply Reply Quote 0
            • H
              halp @tinfoilmatt
              last edited by

              @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

              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.