Project

General

Profile

Actions

Bug #12870

closed

Clicking Save & Force Update on a Dynamic DNS entry results in a GUI timeout

Added by Hong Duong Pham about 2 years ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Dynamic DNS
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
22.05
Release Notes:
Default
Affected Version:
2.6.0
Affected Architecture:
All

Description

The dynamic DNS on Pfsense was not automatically update the IP Address from the network to Cloudflare or any service into the configuration.
I entered the correct information, the IP just only update in the first time, but ip the network down and take the new IP, the new IP was not update to cloudflare. The same thing with other services.
In the first time I save the correct configuration setting, the system will be crash then I must restart the os to access web control again.


Related issues

Has duplicate Bug #12900: Clicking Save & Force Update on a Dynamic DNS entry results in a GUI timeoutDuplicate

Actions
Has duplicate Bug #13600: Saving a DDNS entry can lead to the GUI timing out.DuplicateJim Pingle

Actions
Actions #1

Updated by Viktor Gurov about 2 years ago

  • Status changed from New to Rejected
  • Priority changed from Very High to Normal
  • Target version deleted (22.01)

This site is not for support or diagnostic discussion.

For assistance in solving problems, please post on the Netgate Forum or the pfSense Subreddit .

See Reporting Issues with pfSense Software for more information.

Actions #2

Updated by Danilo Zrenjanin about 2 years ago

Tested on the:

2.6.0-RELEASE (amd64)
built on Mon Jan 31 19:57:53 UTC 2022
FreeBSD 12.3-STABLE

I replicated the issue. After finishing the DynDNS setup using CloudFlare service and clicking the Save or Save & Force Update it will not bring you back to the /services_dyndns.php page. After some time you will get 504 Gateway Time-out. But in my case, the settings were applied and the IP address got updated correctly.

After simulating the public IP address change the service pushed the new address to Cloudflare without any issues.

Actions #3

Updated by Danilo Zrenjanin about 2 years ago

  • Status changed from Rejected to New
Actions #4

Updated by Danilo Zrenjanin about 2 years ago

Here are related logs:

Feb 25 10:28:08     php-fpm     2514     /services_dyndns_edit.php: Response Header: server: cloudflare
Feb 25 10:28:08     php-fpm     2514     /services_dyndns_edit.php: Response Header:
Feb 25 10:28:08     php-fpm     2514     /services_dyndns_edit.php: Response Header:
Feb 25 10:28:08     php-fpm     2514     /services_dyndns_edit.php: Response Data: {"result":{"id":"xxxxx","zone_id":"xxxx","zone_name":"xxxx","name":"xxxx","type":"A","content":"109.x.x.x","proxiable":true,"proxied":false,"ttl":120,"locked":false,"meta":{"auto_added":false,"managed_by_apps":false,"managed_by_argo_tunnel":false},"created_on":"2022-02-25T09:27:35.439256Z","modified_on":"2022-02-25T10:13:24.990709Z"},"success":true,"errors":[],"messages":[]}
Feb 25 10:28:08     php-fpm     2514     /services_dyndns_edit.php: Dynamic DNS cloudflare (xx.xx.xx): _checkStatus() starting.
Feb 25 10:28:09     php-fpm     2514     /services_dyndns_edit.php: Dynamic DNS cloudflare (xx.xx.xx): 109.x.x.x extracted from Check IP Service
Feb 25 10:28:09     php-fpm     2514     /services_dyndns_edit.php: phpDynDNS: updating cache file /conf/dyndns_wancloudflare'xx.xx.xx'0.cache: 109.x.x.x
Feb 25 10:28:09     php-fpm     2514     /services_dyndns_edit.php: phpDynDNS (gate): (Success) gate updated to 109.x.x.x
Feb 25 10:31:05     nginx         2022/02/25 10:31:05 [error] 39537#100466: *1265 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 192.x.x.x, server: , request: "POST /services_dyndns_edit.php?id=0 HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "xx.x.xx", referrer: "https://xx.xx.oxx/services_dyndns_edit.php?id=0" 

Actions #5

Updated by Hong Duong Pham about 2 years ago

But when you disconnect the converter or renew the public IP, the IP was not updated to clodflare. It just only update after the OS reboot. Just one time you save & force update, IP will be updated but take the 504 Gateway time-out on the pfsense. if you save and force many time like that, the pfsense will be crash, then you cannot access to the web control.
With google domain, the service completely not update the IP address. I take the issue after upgrade pfsense to version 2.6.0

Actions #6

Updated by Kris Phillips almost 2 years ago

Hong Duong Pham wrote in #note-5:

But when you disconnect the converter or renew the public IP, the IP was not updated to clodflare. It just only update after the OS reboot. Just one time you save & force update, IP will be updated but take the 504 Gateway time-out on the pfsense. if you save and force many time like that, the pfsense will be crash, then you cannot access to the web control.
With google domain, the service completely not update the IP address. I take the issue after upgrade pfsense to version 2.6.0

Hello,

Please provide logging data to show this is a bug. Otherwise, this is likely a configuration issue on your firewall, which would be a support issue as previously mentioned.

Please provide supporting documentation.

Actions #7

Updated by Hong Duong Pham almost 2 years ago

Logs is the same reply from Danilo Zrẹnanin. Please check !

Actions #8

Updated by Steve Wheeler almost 2 years ago

  • Subject changed from Dynamic DNS on Pfsense was not worked to Dynamic DNS client fails to complete.
  • Target version set to 2.7.0
  • Affected Plus Version set to 22.01

We replicated this on a customer firewall using Cloudflare dyndns.

At boot the client comes up correctly and shows as up to date.

If you make a change, such as setting the dyndns client to a different WAN, and save/force_update the client seems to run correctly but the webpage never returns. With verbose logging enabled the system log shows the complete and successful update.
Eventually the page times out and shows a 504 error. After that it's no longer possible to trigger a dyndns update either from the gui or by a WAN update such as a gateway failover.
If you restart PHP it is then possible to trigger one further update. It appears something in the update process fails to complete and prevents further updates.

Actions #9

Updated by Marcos M almost 2 years ago

  • Project changed from pfSense Plus to pfSense
  • Subject changed from Dynamic DNS client fails to complete. to Clicking Save & Force Update on a Dynamic DNS entry results in a GUI timeout
  • Category changed from Dynamic DNS to Dynamic DNS
  • Affected Plus Version deleted (22.01)
  • Plus Target Version set to 22.05
  • Affected Version set to 2.6.0
  • Affected Architecture All added
  • Affected Architecture deleted (amd64)
Actions #10

Updated by Marcos M almost 2 years ago

  • Has duplicate Bug #12900: Clicking Save & Force Update on a Dynamic DNS entry results in a GUI timeout added
Actions #11

Updated by Jim Pingle almost 2 years ago

  • Assignee set to Jim Pingle

I can reproduce this in my lab with Namecheap as well.

I added some debug logging and it seemed to be getting caught up on curl_close() but commenting out the calls to that didn't help so it's not just that. I'll try to at least narrow it down further.

Actions #12

Updated by Jim Pingle almost 2 years ago

  • Status changed from New to In Progress

Seems to be a problem with multiple overlapping curl requests. It doesn't like making new requests when there is one still hanging out unclosed. Not too hard to work around in this case since it isn't really necessary to keep it open the way it is currently being handled.

I have a fix ready, will be in shortly.

Actions #13

Updated by Jim Pingle almost 2 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100
Actions #14

Updated by Jim Pingle almost 2 years ago

  • Status changed from Feedback to Resolved

I can't reproduce this on any of my Namecheap entries on today's snapshot with the fix in place. Looks good to me.

Actions #15

Updated by Chris Swinney almost 2 years ago

Jim Pingle wrote in #note-14:

I can't reproduce this on any of my Namecheap entries on today's snapshot with the fix in place. Looks good to me.

This is great @jim. Are there any plans for a v26.1 dot release, or is this only going to make it to v27?

Actions #16

Updated by Jim Pingle almost 2 years ago

No plans for a point release at this time.

You can install the System Patches package and then create an entry for bdffb77d1aa21770b23ef408ad9fba79d0825ec5 to fetch and apply the fix. I may add that into the recommended patches list for 2.6.0/22.01 as well.

Actions #17

Updated by Dean Arnold over 1 year ago

I was able to replicate this issue with GoDaddy DNS. Click Save & Force Update then eventually a 504/timeout error appears and the logs show the update was made successfully. I testing using pfSense 2.7.0.a.20221123.0600 and I the patch does not appear to be listed in the System Patches Recommended Patch list for 2.7.

Will this appear fix become part of 2.7 in an upcoming Devl build and/or the full release?

Actions #18

Updated by Jim Pingle over 1 year ago

  • Status changed from Resolved to New
  • % Done changed from 100 to 0

The fixes should already be in 23.01/2.7.0 snapshots, but it's possible some other change broke this again.

I can reproduce it here as well with Namecheap. It updates but the GUI never returns from the action, like it's still being held open again.

I'll take another look.

Actions #19

Updated by Jim Pingle over 1 year ago

I think I have this fixed again, it's still weirdness in cURL.

With PHP 8, curl_close() does nothing, which explains why it worked for a while and then broke -- curl_close was fixing the problem on older builds with PHP 7, but that benefit was lost on PHP 8.x

Setting CURLOPT_FORBID_REUSE on the connection handle before doing curl_exec() appears to fix it. This prevents the connection from attempting to reuse the same TCP connection for later calls to cURL.

It's still not clear why this only seems to affect the save+force update code path, but it's a better behavior overall anyhow.

Commit coming shortly.

Actions #20

Updated by Jim Pingle over 1 year ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions #21

Updated by Marcos M over 1 year ago

  • Has duplicate Bug #13600: Saving a DDNS entry can lead to the GUI timing out. added
Actions #22

Updated by Marcos M over 1 year ago

  • Status changed from Feedback to Resolved

The fix worked for me, thanks!

Actions #23

Updated by Dean Arnold over 1 year ago

I can also confirm the recent changeset fixes the issue in 2.7.0 snapshots.

Actions

Also available in: Atom PDF