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

    Bizarre DHCP Behavior on WAN

    Scheduled Pinned Locked Moved
    DHCP and DNS
    3
    6
    2.7k
    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.
    • D
      dillbilly
      last edited by

      I've been on the phone with my ISP (Time Warner) regarding this issue probably 10 times in the last month, and they don't have any answers for me, so maybe you guys can help me out.

      I'm running pfSense on a SuperMicro server connected to my cable modem (plain vanilla modem, no router features).  If I have a power outage or whatnot, once the modem and server come back up pfSense will not get an IP address from the ISP.  It will send out DHCPREQUESTs indefinitely and will never be given an IP address.  If I spoof a MAC on the server and try to get an IP, no luck.  If, however, I plug my Dell laptop running linux in, with the MAC address spoofed from the server, it may take a moment or two, but eventually it is assigned an IP address.  I can then plug the server back in, and it will immediately get an IP address, but not the same address that was given to the Dell, even though they have moved to only allocating one IP address per account now.  Once connected everything works perfectly until the next power outage.

      Today my power went out again (I know, I should get a UPS) and so I took the opportunity to activate a new modem that I bought.  Plugged in the server, and not surprisingly got no address.  Plugged in the Dell, and even after an extended period got no address.  Plugged in my Mac, and had an address instantly.  Spoofed the Mac's MAC on the server, and I'm back online again.

      The guys I've talked to at the upper tiers of tech support tell me TW isn't blocking IP address assignment to particular devices, which almost makes sense, given that the Dell could usually get an address even with the spoofed MAC, but then why can't the pfSense box?  If I plug it into another router it gets an address immediately, and once it gets an address TW doesn't let it expire.  It's all a great mystery, and it's getting extremely frustrating, so any insight into the situation would be great.

      And as I typed this my pfSense box dropped its IP address and now won't get one with either its nor the Mac's MAC, nor will the Mac get its IP back.  Words cannot express how irritated I am with them…

      1 Reply Last reply Reply Quote 0
      • W
        wallabybob
        last edited by

        @dillbilly:

        I'm running pfSense on a SuperMicro server connected to my cable modem (plain vanilla modem, no router features).

        What version of pfSense?

        @dillbilly:

        If I have a power outage or whatnot, once the modem and server come back up pfSense will not get an IP address from the ISP.  It will send out DHCPREQUESTs indefinitely and will never be given an IP address.

        Have you done a packet capture? Do you see any replies at all?

        Please post the output of pfSense shell command```
        clog /var/log/system.log | grep dhclient

        1 Reply Last reply Reply Quote 0
        • D
          dillbilly
          last edited by

          I'm running 2.0.3-RELEASE (i386), but this has been happening for some time, and across versions.

          I don't get any traffic from the ISP unless I've already gotten an IP address by using my laptop first, and when I was on the phone with the tech (again) he said that he couldn't see my computer making any requests.

          A snip from the log:

          Apr 30 16:19:48 pfsense dhclient: PREINIT
          Apr 30 16:19:48 pfsense dhclient: EXPIRE
          Apr 30 16:19:48 pfsense dhclient: Deleting old routes
          Apr 30 16:19:48 pfsense dhclient: PREINIT
          Apr 30 16:19:48 pfsense dhclient[40997]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 2
          Apr 30 16:19:50 pfsense dhclient[40997]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 2
          Apr 30 16:19:52 pfsense dhclient[40997]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 3
          Apr 30 16:19:55 pfsense dhclient[40997]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 5
          Apr 30 16:20:00 pfsense dhclient[40997]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 13
          Apr 30 16:20:13 pfsense dhclient[40997]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 9
          Apr 30 16:20:22 pfsense dhclient[40997]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 11
          Apr 30 16:20:33 pfsense dhclient[40997]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 13
          Apr 30 16:20:46 pfsense dhclient[40997]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 3
          Apr 30 16:20:49 pfsense dhclient[40997]: No DHCPOFFERS received.
          Apr 30 16:20:49 pfsense dhclient[40997]: No working leases in persistent database - sleeping.
          Apr 30 16:20:49 pfsense dhclient: FAIL
          Apr 30 16:20:50 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 1
          Apr 30 16:20:51 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 1
          Apr 30 16:20:52 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 1
          Apr 30 16:20:53 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 1
          Apr 30 16:20:54 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 2
          Apr 30 16:20:56 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 3
          Apr 30 16:20:59 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 8
          Apr 30 16:21:07 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 9
          Apr 30 16:21:16 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 8
          Apr 30 16:21:24 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 15
          Apr 30 16:21:39 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 12
          Apr 30 16:21:51 pfsense dhclient[8735]: No DHCPOFFERS received.
          Apr 30 16:21:51 pfsense dhclient[8735]: No working leases in persistent database - sleeping.
          Apr 30 16:21:51 pfsense dhclient: FAIL
          Apr 30 16:21:52 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 1
          Apr 30 16:21:53 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 1
          Apr 30 16:21:54 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 2
          Apr 30 16:21:56 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 2
          Apr 30 16:21:58 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 4
          Apr 30 16:22:02 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 9
          Apr 30 16:22:11 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 19
          Apr 30 16:22:30 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 21
          Apr 30 16:22:51 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 2
          Apr 30 16:22:53 pfsense dhclient[8735]: No DHCPOFFERS received.
          Apr 30 16:22:53 pfsense dhclient[8735]: No working leases in persistent database - sleeping.
          Apr 30 16:22:53 pfsense dhclient: FAIL
          Apr 30 16:22:54 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 2
          Apr 30 16:22:56 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 4
          Apr 30 16:23:00 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 7
          Apr 30 16:23:07 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 11
          Apr 30 16:23:18 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 13
          Apr 30 16:23:31 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 10
          Apr 30 16:23:41 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 12
          Apr 30 16:23:53 pfsense dhclient[8735]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 2
          Apr 30 16:23:55 pfsense dhclient[8735]: No DHCPOFFERS received.
          Apr 30 16:23:55 pfsense dhclient[8735]: No working leases in persistent database - sleeping.
          Apr 30 16:23:55 pfsense dhclient: FAIL

          It's very strange.  If they were doing MAC filtering, then the laptop with the spoofed IP shouldn't be able to get an address.  If it were my server, then it shouldn't be able to get an address when plugged into a different router.  If it were a line issue then other computers should have trouble connecting.  And I really don't understand why once the laptop gets an address I can plug the server in and suddenly my ISP sees the DHCP request and gives it an address.

          1 Reply Last reply Reply Quote 0
          • W
            wallabybob
            last edited by

            @dillbilly:

            when I was on the phone with the tech (again) he said that he couldn't see my computer making any requests.

            This could be difficult to debug. Packet capture shows transmit frames when they are given to the device driver. It doesn't show frames that actually went out on the wire. The driver might decide to discard frames for a number of reasons including it thinking the physical connection is not "up". Are there any link transitions reported? What does pfSense shell command```
            ifconfig em0

            
Is pfSense running on the "bare metal" or under the control of a hypervisor such as VMWare, VirtualBox etc? (My first attempt to run pfSense under VirtualBox failed. I allowed the default NIC emulation in VirtualBox, an AMD NIC. pfSense reported sending DHCPDISCOVERs but I couldn't find any evidence they made it out of the VM. I changed the type of the emulated NIC to Intel E1000, rebooted and reconfigured pfSense and saw response to the DHCPDISCOVER.)

Is there any kind of packet capture or event log on your modem that you could use to confirm the modem is really seeing the DHCPDISCOVERs? Is there any physical evidence (e.g NIC lights flashing) of the DHCPDISCOVER frames getting to the wire?

@dillbilly:

> And I really don't understand why once the laptop gets an address I can plug the server in and suddenly my ISP sees the DHCP request and gives it an address.

This is also puzzling. Maybe the laptop tickles the modem the "right way" and the modem's memory of that persists for a while. If the modem loses signal from its upstream does it drop carrier on its downstream link or change mode (e.g. to 10Mbps.)? Maybe pfSense doesn't notice the mode change and the laptop resets the mode and then all is good until the next time the modem loses sync with its upstream.
            1 Reply Last reply Reply Quote 0
            • D
              dillbilly
              last edited by

              Well I spent some more time with TW this afternoon, and the mystery deepens.  Apparently the MAC address that shows up on their end is not the MAC address that my server has, nor is it a MAC that I've spoofed.  Just a totally random MAC address in the SuperMicro server range.  Next time it stops working I'll have to do some investigation with another router and see what it does on my network.

              1 Reply Last reply Reply Quote 0
              • T
                TravisD
                last edited by

                Does the server have an IPMI sharing that interface? Some of them can share the same physical port but they're basically a different machine. Since it's up first, it could be grabbing the lease before pfSense ever comes up. I believe most cablemodems will lock to the first MAC they hand an address to and refuse the rest. I know I had similar issues running pfSense under VMWare.

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