pfSense » pfSense Plus

I have seen cases where restarting dpinger fails to clear the Pending status and where it should have worked. Dpinger has difficulty distinguishing between having a connection while waiting for the IP from DHCP and there is none because the cable is disconnected, failed or the modem is powered off. I believe dpinger has one or more bugs.

Hal Prewitt wrote in #note-1:

I have seen cases where restarting dpinger fails to clear the Pending status and where it should have worked. Dpinger has difficulty distinguishing between having a connection while waiting for the IP from DHCP and there is none because the cable is disconnected, failed or the modem is powered off. I believe dpinger has one or more bugs.

Hello Hal,

With a DHCP WAN that has it's cable unplugged, it's expected behavior to show "Pending" on the gateway. This is because there is no IP defined for the gateway due to lack of DHCP and physical link. Unless you are referring to a situation where your WAN has link and a valid IP address, subnet, and gateway, but the gateway still shows Pending, this is expected behavior.

Using Pending when there is no physical link is confusing and I would say is an incorrect reporting of the actual status vs the condition where there is a link but waiting for the IP from a DHCP server. Obviously, these are very different reasons for not having a working WAN. Offline means to me (and most people), there is no connection to even expect an IP. Makes us look for wiring or power problems causing the failure. I and one of your techs have seen Pending stuck when there is a physical link and IP.

Hal Prewitt wrote in #note-3:

Using Pending when there is no physical link is confusing and I would say is an incorrect reporting of the actual status vs the condition where there is a link but waiting for the IP from a DHCP server. Obviously, these are very different reasons for not having a working WAN. Offline means to me (and most people), there is no connection to even expect an IP. Makes us look for wiring or power problems causing the failure. I and one of your techs have seen Pending stuck when there is a physical link and IP.

Hello Hal,

If you can please provide an example of this attached to the redmine, that would be most helpful. However, I'm not able to reproduce your issue.

As for the Offline vs Pending, this is expected behavior. If you'd like to open a redmine for changing the wording to be more clear, please feel free to do so.

Yes, sometimes reconnecting the port will clear Pending but not always.  Appears there are many ways to get into Pending and be stuck.

This is a serious bug. Today, I spent many hours trying every config change I could think of (reboots, config rollback, disabling, enabling, dhcp release/refresh, unplugging/replugging cables ect) to clear the Pending status. All failed except one process. Changing the Interface to use a static IP & its gateway to the last known DHPC values and rebooting the WAN modem. Once online, switching back to a DHCP Interface worked.

As for being the expected behavior of displaying Offline vs Pending, this is not an issue of changing the wording to be more clear. I don't see a good reason to treat gateways differently whether or not they use DHCP or a Static IP.  

Why be different than what's shown under the Interface Status tab? That display will typically show UP (working), Down (A dynamic DHCP WAN type is not fully connected or does not have an IP),  No Carrier (cable is not plugged in or the device on the other end is malfunctioning in some way.).  

WANs/Gateways are either Online, Offline, or Warning (partial working but failing, % of loss in other words seeing errors).  Perhaps there are, except I am unaware of a continuous state or condition where Pending is correct.

This Pending Status is a design error and needs to be removed.  Has many logic and operational errors. There is no timeout meaning this status may stay forever.

There are no gateway log entries to indicate the actual status of the gateway.  No notices are sent when the gateway becomes Pending. Under the tab and when using Diagnostics/Ping or Traceroute and selecting the Pending Gateway in Source Address, will result in what appears to be a working connection. Regardless of the selection, traffic is actually using a different Interface.(assuming another one is available).

Each of these result in no user awareness of the failure.

Hal Prewitt wrote in #note-5:

Yes, sometimes reconnecting the port will clear Pending but not always.  Appears there are many ways to get into Pending and be stuck.

This is a serious bug. Today, I spent many hours trying every config change I could think of (reboots, config rollback, disabling, enabling, dhcp release/refresh, unplugging/replugging cables ect) to clear the Pending status. All failed except one process. Changing the Interface to use a static IP & its gateway to the last known DHPC values and rebooting the WAN modem. Once online, switching back to a DHCP Interface worked.

1. I disconnected and connected the cable from the Netgate 6100's WAN interface 20 times. Following each reconnection, the status transitioned from Pending to Online without any failures.
2. I performed 10 modem reboots. Each time, the gateway successfully transitioned from "Pending" to "Packet Loss" to "Online."

In my lab environment, I was unable to reproduce the scenario where the gateway status becomes stuck in a Pending state.

There are no gateway log entries to indicate the actual status of the gateway. No notices are sent when the gateway becomes Pending. Under the tab and when using Diagnostics/Ping or Traceroute and selecting the Pending Gateway in Source Address, will result in what appears to be a working connection. Regardless of the selection, traffic is actually using a different Interface.(assuming another one is available).

Yes, I can confirm that the Status/System Logs/System/Gateways does not contain any logs other than dpinger restart, indicating that the gateway was down while in a Pending status. Which should be improved.

I had the same experience. Down the link and it goes Pending. Up the link and it transitions to Online after enough replies are received.

"Pending" is a valid gateway status if the pings cannot be sent. Reasons a ping cannot be sent would be interface down, lack of ARP for the gateway address. It is not "Down" because pings cannot be sent so packet loss and latency cannot be measured. It is "Pending" until pings can be sent. This is similar to CARP INIT state.

Reply to what Danilo Zrenjanin wrote in #note-6:

(1) Nothing surprising your 20 times worked. I too, saw many successes doing these simple tests. Except:
(2) There are many permutations and combinations in computer applications that each result in different conditions. There is a real bug in dpinger's Pending implementation or maybe in the DHCP client processing. It's just hard to find the right conditions so the bug occurs and is repeatable. Perhaps, Chris W's testing described in #note-8 and resulting just issued patch for "BPF device not available for the DHCP client", will fix one of the problems of being stuck in Pending.

Reply to what Chris Linstruth wrote in #note-7:

I am aware of the transitions due to replies, except that was not my issue. Showing "Pending" is not the correct status when a port is disconnected such as when there is no ethernet cable attached or the modem is powered off. Status should show down or Offline because nothing is pending. The port may never reconnect. As I wrote above, there are many operational or design problems with the current implementation of "Pending". Furthermore, I don't see its usefulness. DHCP & Static IP configurations should be treated the same (Status) when disconnected.

Try this patch: https://github.com/pfsense/pfsense/commit/338d722a3dcd5703d6d56fe2727490ca0ed33cad

Above patch didn't seem to make a difference with respect to the VTI tunnel that sticks in pending when monitoring is enabled on my setup. Also when a gateway is in pending status the option to force state, mark gateway as down, does nothing to effect the status (pending) when option is used for said gateway, it remains pending.

Tested this on the 24.03 BETA and this issue is present on that version as well.

Tested on 24.03-RC and this issue is still present.

Tested on 24.03-RELEASE and this issue is still present.

I just got this on a IPv4 gateway DHCP WAN. Usually it works, but on powering up pfSense on this occasion it was stuck in pending, I restarted the dpinger service and it came online.

In my case I am on 2.7.2 CE.

To summarize current ways this happens:

1. VTI tunnels
2. OpenVPN Client or Server interfaces that are assigned to an interface
3. Wireguard interfaces
4. DHCPv6 interfaces when a lease doesn't get applied to the interface before it comes up with IPv4
5. DHCPv4 interfaces if an interface has a gateway with no address when dpinger starts

This happens for me as well on 2.7.2 CE, usually restarting the gateway service on the gateways page fixes it. The interesting thing is the other instances you guys refer to are with VPNs - I do have some VPNs, but have never had this issue with them, this issue seems to happen for the primary interface on my dual wan setup.

Are there any known workarounds outside restarting dpinger manually?