after pppoe (mpd) restart, dyndns update error

FireOdo

Hi,

I updated yesterday to 2.9.0 CE and I found a problem when pppoe-wan interface is restarted. The dyndns clients dont get updated and this error is shown in log:

ERROR [phpDynDNS] (redacted) Could not determine the request IP address (using "wan", "pppoe0"): gateway not online

This never happend since I can remember (back to pfsense 2.4.1 etc).

I'm thinking its a timing problem

Aug 23 05:03:01	php-fpm	78988	NOTICE [Filter] IP Address has changed, killing states on former IP Address xx.13.177.77.
Aug 23 05:03:01	php-fpm	78988	NOTICE Default gateway setting WAN IPv4 Gateway as default.
Aug 23 05:02:58	php-fpm	78775	ERROR [phpDynDNS] (redacted) Could not determine the request IP address (using "wan", "pppoe0"): gateway not online

(the dyndns tryes to update before gateway is really up) because if I call instantly after pppoe restart,

/etc/rc.dyndns.update

everything gets OK.

I would have opened a redmine ticket but if I call pfsense redmine I get a "404 Not Found" ...
(seems like Friday the 13teen and the black cat together )

Have a nice sunday,
FireOdo

EDIT: Here my "quick and dirty" workaround:

As after a restart of the pppoe session the file /etc/rc.newwanip is called, I attached at the end of that file
(before the "?>"

shell_exec('/etc/rc.dyndns.update');

and that resolved the dyndns update (for me).
As I said - its a quick&dirty patch until the bug introduced by 2.9.0 is found.

pfpv

Thank you for posting. I came here to post the same. I have the exact same issue that started with 2.9.0. I will try your workaround. I am pinging @jimp and @johnpoz to bring attention to this. DynDNS is critical to those on PPPoE.
EDIT: I am using if_pppoe. So, it's not dirver related.

And while we are on the topic of DynDNS I would like to bring another old issue to attention:
https://forum.netgate.com/topic/201207/when-one-dyndns-entry-is-force-updated-the-others-get-n-a-for-cached-ip

pfpv

I would also like to ping @stephenw10, as he recently worked on the if_pppoe kernel driver. Although this issue is not related, and may not even be related to the driver.

pfpv

@FireOdo
Your workaround works quite well. And DynDNS doesn't update at all without that line in /etc/rc.newwanip
I wonder how it was before this bug showed up. Maybe the developers forgot this line. I kind of wonder what the original mechanism was.

FireOdo

@pfpv said in after pppoe (mpd) restart, dyndns update error:

Maybe the developers forgot this line.

No, they have not. This line is just a circumvention of the issue, added by myself.

I kind of wonder what the original mechanism was.

As far as I understand the code, the original mechanism is at line 262 - but it seems that this mechanism got a timing problem. (I might be wrong, but thats what I think).

Gertjan

@FireOdo said in after pppoe (mpd) restart, dyndns update error:

As after a restart of the pppoe session the file /etc/rc.newwanip is called, I attached at the end of that file
(before the "?>"

shell_exec('/etc/rc.dyndns.update');

and that resolved the dyndns update (for me).

like this :

?

have a look at the file "/etc/rc.dyndns.update".
It calls "services_dyndns_configure($interface);"
Now, back to my image, the first spot marked in green : is was already called.
But with a condition (look further up) :

if (!is_ipaddr($oldip) || ($curwanip != $oldip) || file_exists("{$g['tmp_path']}/{$interface}_upstart4") ||
    (!is_ipaddrv4(config_get_path("interfaces/{$interface}/ipaddr")) && (config_get_path("interfaces/{$interface}/ipaddr") != 'dhcp')))

The conditions are :
If there was not an old known (WAN) IP,
or
The current WAN IP different from the old WAN IP
or
If the file /tmp/{$interface}_upstart4 exists (or /var/tmp/{$interface}_upstart4, not sure)
or
If (see the config.xml file) interfaces/{$interface}/ipaddr is NOT a IPv4 address
or
If (see the config.xml file) interfaces/{$interface}/ipaddr is not set to 'dhcp'

Then the last part is executed, and also "services_dyndns_configure($interface);" get called.

Can you check if that final part gets executed ? If the 'if' fails then yeah, no "services_dyndns_configure($interface);" gets called.

FireOdo

@Gertjan said in after pppoe (mpd) restart, dyndns update error:

Can you check if that final part gets executed ? If the 'if' fails then yeah, no "services_dyndns_configure($interface);" gets called.

As far as I can see - no fails, digging.

PS. I am still digging, but in my case it seems a issue between dpinger and the gateway of my ISP.

Gertjan

@FireOdo

With 'fail' I meant that this if test resulted in a 'false' so lines 225 to 290 are skipped, so line 259 ( services_dnsupdate_process($interface); ) doesn't get executed.

FireOdo

@Gertjan said in after pppoe (mpd) restart, dyndns update error:

With 'fail' I meant that this if test resulted in a 'false' so lines 225 to 290 are skipped, so line 259 ( services_dnsupdate_process($interface); ) doesn't get executed.

Aha, OK - thanks for clarification.

weizenspreu

I have the additional issue that trying to update the DynDNS status results in a "gateway not online" error message in the logs. This stems from lines 4652-4655 in /etc/inc/services.inc.

I simply commented them out like this:

        if (!empty($interface_gateway)) {
                // Bail early if the gateway is down.
                list($gateway_status, $gateway_details) = get_gateway_status($interface_gateway);
#                if(!is_online_gateway_status($gateway_status)) {
#                       $error = 'gateway not online';
#                       return [$source_address, $error];
#                }
                        
                // If the address family hasn't been specified, base it on the gateway.
                if (!isset($address_family)) {
                        $address_family = (array_get_path($gateway_details, "config/ipprotocol") == 'inet') ? AF_INET : AF_INET6;
                }
        }

Hopefully, Netgate won't take months to fix this as it's really annoying.

AlexanderK

I am facing something like this.

https://forum.netgate.com/topic/201337/2.9.0-and-dyndns-with-no-ip

Have a look here

Gertjan

@weizenspreu said in after pppoe (mpd) restart, dyndns update error:

to fix this

Just a thought :
If the gateway is marked as "off line" - and this makes dyndns fail - but the internet access seems to work just fine, then you need to know this : it's not uncommon that gateways doesn't reply to ping requests.
Not a big issue, as you can pick yourself another IP, it doesn't need to be the gateway.

Example :

AlexanderK

any fix for this issue?

Gertjan

@AlexanderK

The fix I implied was : make the gateway monitor happy again by creating this situation :

You fixed that ? ( by using IP that is know to reply on ping, so dpinger, the gateway monitor shows a green 'online' )

pfpv

@Gertjan said in after pppoe (mpd) restart, dyndns update error:

it's not uncommon that gateways doesn't reply to ping requests.

It is uncommon, and it's not an issue here. There is a bug.

rpsmith

@Gertjan ~ I always set the monitor ip to 8.8.4.4 and have not seen this problem on any of my pppoe firewalls that use dyndns.

Gertjan

@rpsmith

Suggestion : connect to the console, or better : ssh, and :

[26.07-RELEASE][root@pfSense.bhf.tld]/root: ping -S 192.168.10.4 8.8.4.4
PING 8.8.4.4 (8.8.4.4) from 192.168.10.4: 56 data bytes
64 bytes from 8.8.4.4: icmp_seq=0 ttl=111 time=17.142 ms
64 bytes from 8.8.4.4: icmp_seq=1 ttl=111 time=16.981 ms
64 bytes from 8.8.4.4: icmp_seq=2 ttl=111 time=18.975 ms
64 bytes from 8.8.4.4: icmp_seq=3 ttl=111 time=16.947 ms
^C
--- 8.8.4.4 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 16.947/17.511/18.975/0.848 ms

I've added "-S 192.168.10.4" as that is my WAN IP, making sure the ping packets go out over WAN.
This is what the monitor does.
When replies come back, your status is 'Online'.

You get packets back when ping manually, but your status is marked as offline ?

pfpv

@Gertjan
The status is never marked as offline in the GUI but the log states "offline". It's a bug. It has nothing to do with connectivity. I've been running the gateway monitoring with an external IP (not the ISP gateway) for a few years, and the problem started in 2.9.0, nothing else changed. There is no issue with connectivity, only with DynDNS updates.

luckman212

If you want some good candidates for pingable IPs "close" to your WAN interface that aren't the usual 8.8.8.8 etc, you could give my hopfinder tool a try.

It's on my to-do list to make this a package so it's easier to integrate.

pfpv

@luckman212
The today pingable IPs may not be pingable tomorrow. It's best to use the ISP gateway or some other well-known, established DNS servers. The distance doesn't really matter. The reliability is paramount.