No WAN IP after Comcast outage



  • Whenever my Comcast connection goes down pfSense does not get a WAN IP address until some manual step is taken such as:

    • ifconfig igb0 down followed by igb0 up commands

    • Click release and then renew on the Status >Interfaces page

    • Unplug the cable between the modem and pfsense for a moment

    • Call Comcast and ask them to reboot the modem

    A single one of these actions will re-establish connectivity, but if no action is taken pfSense will sit for hours and never get a WAN IP address.

    I don't know if it's related but when this is happening my log is flooded with these messages:

    kernel: arpresolve: can't allocate llinfo for a.b.c.d

    Where a.b.c.d appears to be the default gateway assigned by DHCP right before the outage.

    I keep reading explanations that this is caused by the modem. However I have replaced a Motorola SB6183 modem with another and it did not make a difference. Then I bought a TP-Link brand modem and again no changes were observed. Finally I have made sure under Interfaces > WAN to set Reject leases from = 192.168.100.1 and can verify in the log the lease is being rejected. And even if it is the modem I don't understand. Why can't pfSense just get a DHCP lease and use it? I couldn't care if the log is flooded with some message as long as everything works after a reasonable amount of time.

    If I replace pfSense with a $20 Linksys router I don't see this issue and shortly after an outage is restored it grabs a WAN IP address and is back online with no problems.

    I see some posts were this issue was hacked around with scripts that reboots pfsense or issues the ifconfig up/down commands, but surely there has to be a better way?



  • If the log in pfSense constantly shows it is rejecting the 192.* lease that's being offered then it shows pfSense is asking for a lease and not being given a correct one. When you take down the interface on pfSense it also resets the modem interface, as does sending a release, which although not taking the port down will cause the dhcp server on the modem to release and start again, this giving you a legit IP.

    This does not happen with every pfSense unit, I have no issues with my modem, it appears it's only some modems that cause this problem. Using the script to force an interface reset is very simple to implement and I would just do it, problem resolved.



  • The issue seems to be that pfSense fails when assigning a WAN IP address. It attempts to use the last known DHCP lease but the IP address does not get assigned to the WAN interface and from this state it is not able to recover. I do not believe this is a modem issue as I have already tested with a different brand modem and I did not see any improvements.

    I can see in the log soon after the outage starts:

    Sep 30 18:39:13 pfsense dhclient[91165]: DHCPOFFER from 192.168.100.1 rejected.
    Sep 30 18:39:24 pfsense dhclient[91165]: DHCPDISCOVER on igb0 to 255.255.255.255 port 67 interval 9
    Sep 30 18:39:24 pfsense dhclient[91165]: DHCPOFFER from 192.168.100.1 rejected.
    Sep 30 18:39:33 pfsense dhclient[91165]: DHCPDISCOVER on igb0 to 255.255.255.255 port 67 interval 1
    Sep 30 18:39:33 pfsense dhclient[91165]: DHCPOFFER from 192.168.100.1 rejected.
    Sep 30 18:39:34 pfsense dhclient[91165]: No DHCPOFFERS received.
    Sep 30 18:39:34 pfsense dhclient[91165]: Trying recorded lease 123.123.123.123
    Sep 30 18:39:34 pfsense dhclient: TIMEOUT
    Sep 30 18:39:34 pfsense dhclient: Starting add_new_address()
    Sep 30 18:39:34 pfsense dhclient: ifconfig igb0 inet 123.123.123.123 netmask 255.255.248.0 broadcast 255.255.255.255
    Sep 30 18:39:34 pfsense dhclient: New IP Address (igb0): 123.123.123.123
    Sep 30 18:39:34 pfsense dhclient: New Subnet Mask (igb0): 255.255.248.0
    Sep 30 18:39:34 pfsense dhclient: New Broadcast Address (igb0): 255.255.255.255
    Sep 30 18:39:34 pfsense dhclient: New Routers (igb0): 123.123.123.1
    Sep 30 18:39:35 pfsense dhclient: New Routers (igb0): 123.123.123.1
    Sep 30 18:39:36 pfsense dhclient: Deleting old routes
    Sep 30 18:39:36 pfsense dhclient[91165]: bound: renewal in 170408 seconds.

    But then ifconfig shows no WAN IP address:

    igb0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
            options=400bb <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,jumbo_mtu,vlan_hwcsum,vlan_hwtso>ether 0c:c4:7a🆎cd:ef
            hwaddr 0c:c4:7a🆎cd:ef
            inet6 fe80::ec4:7afa:bb5f:cc1d%igb0 prefixlen 64 scopeid 0x1
            nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex>)
            status: active

    I try to issue the ifconfig command from dhclient log. There is no error, the IP address is still not assigned to the interface.

    I'm not quite sure what script you are referring to, but if it's known to fix this issue I would like more details.</full-duplex></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,jumbo_mtu,vlan_hwcsum,vlan_hwtso></up,broadcast,running,simplex,multicast>



  • That does look strange. What version of pfSense are you using?

    The script…

    Some time ago, I managed to remotely log into my pfSense and, in a moment of madness, I released the WAN interface. That was obviously not a good idea as I was then unable to restore it! As I was on the other side of the world on holiday it had to stay that way for two weeks, no mail, wife was not impressed!

    So a script needed to be brought into play to check the pfSense was behaving, I did not write the script but it tests OK and now pfSense will reset itself if it loses WAN connectivity.

    You will need to add a Cron entry, mine runs every 10 minutes, add the Cron package to make life easier.

    The script is attached, it will first try a WAN down/up to correct the problem, if that fails then it will reboot, you'll need to mod it to match your interface name mine is re0, yours may no be.

    Make sure your permissions are set correctly, in my case the script sits in usr/local/bin, try running it from the shell first to check those permissions are OK.

    ping_check.zip



  • You have some

    options=400bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO>

    Maybe it's time to "kill" some of these ?!

    Jumbo frames ?
    Gardware checksum ?
    TSO ?
    VLAN_HWCSUM ?
    Aren't these by default "off" ?

    What are all these references about VLAN ?


Log in to reply