Bug #943
closed
2.0-BETA4 Dynamic DNS updates not working
Added by R B about 14 years ago. Updated over 13 years ago.
0%
Description
Running 2.0-BETA4 (i386) NanoBSD 1G image dated "Mon Sep 20 22:40:28 EDT 2010". WAN is a DSL PPPoE link in bridged (dumb modem) mode, terminated on an FXP NIC on the pfSense host. Dynamic DNS entry is a DynDNS (static) account.
Test:
- DynDNS entry reflects X.Y.137.135
- Unplug DSL phone line, simulating WAN failure
- Wait until pfSense host recognizes circuit as down
- Plug DSL back in, allow system to resume operation
- WAN assigned new IP of X.Y.136.130
- DynDNS still points at X.Y.137.135
Please see attached system log, annotated with logger. Edited solely for privacy (IPs, hostname, username redacted).
Files
| system.log (10.1 KB) system.log | R B, 10/11/2010 03:34 PM | ||
| dyndns.log (1.39 KB) dyndns.log | Michel Samovojski, 11/06/2010 10:26 PM | ||
| ddns_test.log (8.56 KB) ddns_test.log | R B, 11/07/2010 12:34 PM | ||
| wan-test.log (9.92 KB) wan-test.log | R B, 01/21/2011 10:31 AM |
Updated by Jim Pingle about 14 years ago
- Status changed from New to Feedback
Please update to a much more recent (10/10 newer) snapshot and try again, then update the ticket. Many changes happened since Sep 20, and this problem may already be fixed.
I'm on a 10/2 snap at home and DynDNS updates my PPPoE DSL WAN fine.
Updated by R B about 14 years ago
Nope. Just updated to "Sun Oct 10 23:06:39 EDT 2010" and the same test produces the same behavior: DynDNS.org still points to X.Y.136.67 while pppoe1 now has X.Y.124.54.
The syslog clearly shows the "check_reload_status: updating dyndns wan" entry, indicating it's somehow attempted to, but the only way it updates my entry is by manually clicking the 'edit' and 'save' buttons on the UI for that entry.
To clarify:
- Running Dynamic DNS client, type "DynDNS (static)"
- Wildcard enabled, no MX
- Using a long-standing account that's been fine updating until (as noted on the support ML) the July/August timeframe.
Updated by Jim Pingle about 14 years ago
And I do the same thing on mine and it works:
Oct 12 11:28:34 blooper check_reload_status: updating dyndns wan Oct 12 11:28:35 blooper php: : DynDns: Running updatedns() Oct 12 11:28:35 blooper php: : DynDns: updatedns() starting Oct 12 11:28:35 blooper php: : DynDns: _detectChange() starting. Oct 12 11:28:35 blooper php: : DynDns: _checkIP() starting. Oct 12 11:28:35 blooper php: : DynDns debug information: x.x.217.98 extracted from local system. Oct 12 11:28:35 blooper php: : DynDns: Current WAN IP: x.x.217.98 Oct 12 11:28:35 blooper php: : DynDns: Cached IP: x.x.86.95 Oct 12 11:28:35 blooper php: : DynDns debug information: DynDns: cacheIP != wan_ip. Updating. Cached IP: x.x.86.95 WAN IP: x.x.217.98 Oct 12 11:28:35 blooper php: : DynDns: DynDns _update() starting. Oct 12 11:28:36 blooper php: : DynDns: DynDns _checkStatus() starting. Oct 12 11:28:36 blooper php: : DynDns: Current Service: dyndns Oct 12 11:28:36 blooper php: : DynDns: _checkIP() starting. Oct 12 11:28:36 blooper php: : DynDns debug information: x.x.217.98 extracted from local system. Oct 12 11:28:36 blooper php: : phpDynDNS: updating cache file /conf/dyndns_wandyndns.cache: x.x.217.98 Oct 12 11:28:36 blooper php: : phpDynDNS: (Success) IP Address Changed Successfully! (x.x.217.98)My settings are:
- DynDNS (Dynamic) -- though in the code it looks like Static takes the same code paths so it may not matter
- No Wildcard, no MX
Updated by R B about 14 years ago
Perhaps the difference is the platform. Mine's running the embedded NanoBSD build and I get no such 'DynDns: xxx' messages unless I edit & save the DynDNS entry.
Updated by Jim Pingle about 14 years ago
That is possible, I am on a full install. First, can you try setting for DynDNS (Dynamic) and unchecking Wildcard just to see if that makes any difference?
Any way you can try to switch to a non-embedded install as a test temporarily to help narrow it down?
Updated by R B about 14 years ago
Switched to DynDNS (Dynamic) and unset the wildcard. Tested with the three combinations (dynamic/wild, static/nowild, dynamic/nowild) to no avail.
Switching to a full install is not an option for me right now.
Updated by Jim Pingle about 14 years ago
- Status changed from Feedback to New
I'll set this back to new for now. You might want to start a forum post on the 2.0 board to see if anyone else has similar experiences to yours.
I have an ALIX I could try this on when I get a few spare cycles, but I'm not sure that will happen today.
Updated by R B about 14 years ago
Will look at opening a forum account and doing so. Already discussed on the support@ ML and Chris suggested opening a ticket.
Updated by Jim Pingle about 14 years ago
Yeah that's good but the forum sees more traffic, and the 2.0 board is very active. There are probably quite a few people in a position to help test.
Updated by Ermal Luçi about 14 years ago
- Status changed from New to Feedback
Please try a new snapshot some fixes were done to dyndns which might fix even your issues.
Updated by R B about 14 years ago
Updated to "FreeBSD 8.1-RELEASE-p1 #0: Sat Oct 23 01:35:35 EDT 2010" and no improvement. System log shows only the "check_reload_status: updating dyndns wan" entry, nothing further.
Updated by Ermal Luçi about 14 years ago
Are you sure that you have the latest snapshot?
Can you post a system log here?
Can you post your config here?
Updated by Michel Samovojski about 14 years ago
- File dyndns.log dyndns.log added
working well for me under this snapshot
Full 2.0-BETA4 (i386) built on Sat Oct 30 19:40:13 EDT 2010 FreeBSD 8.1-RELEASE-p1
Updated by R B about 14 years ago
Ermal -
Yes, I was running the latest snapshot two weeks ago when you asked me to try again, I made sure the snapshot I used was cut well after you made the changes according to the git log. I will update again and show as much again. I've also posted one set of logs, and don't see what benefit will come from the effort of sanitizing my config just to post it is going to do - what else are you looking for? Has anyone else tried using the NanoBSD build to confirm the bug?
Michel -
It's pretty well-established that it works fine on the full installation, but not on the embedded build I'm using.
Updated by R B about 14 years ago
- File ddns_test.log ddns_test.log added
Tested again with NanoBSD 1GB snapshot dated "Sun Nov 7 06:14:22 EST 2010" and still exhibiting the same behavior. Uploading sanitized log of the test - unplug DSL line, wait until confirmed down, plug back in.
Updated by Ermal Luçi about 14 years ago
Your log makes me suggest you reinstall from scratch because you might have some corrupted/modified files.
Updated by R B about 14 years ago
Will look at doing so, but it may be a day or two. I may just set up a VM with a vanilla NanoBSD installation and test that.
Updated by John Bradshaw about 14 years ago
I'm running a clean install of NanoBSD 4GB dated Oct 8, 2010 and I'm not having any issues with this.
Updated by Jeppe Oland about 14 years ago
I am seeing the same problem on a clean boot of pfSense-2.0-BETA4-20101120-0520.iso - well a clean install followed by a restore of my configuration.
The connection is via Comcast Cable.
When the cablemodem comes online, it initially gives out a 192.168.100.x address.
A short while later, it revokes it and gives out the correct address.
When the 192.x.x.x address is given out, the dyndns script fails with exactly the same error as the real IP later ... so I will only copy the last log:
Nov 21 23:02:10 firewall dhclient42096: bound to 24.x.x.x -- renewal in 1800 seconds.
Nov 22 07:02:10 firewall check_reload_status: Rewriting resolv.conf
Nov 21 23:02:10 firewall php: : rc.newwanip: Informational is starting em1.
Nov 21 23:02:10 firewall php: : rc.newwanip: Informational is starting em1.
Nov 21 23:02:10 firewall php: : rc.newwanip: on (IP address: 24.x.x.x) (interface: wan) (real interface: em1).
Nov 21 23:02:10 firewall php: : rc.newwanip: on (IP address: 24.x.x.x) (interface: wan) (real interface: em1).
Nov 21 23:02:10 firewall php: : ROUTING: change default route to 24.x.x.1
Nov 21 23:02:10 firewall php: : ROUTING: change default route to 24.x.x.1
Nov 21 23:02:11 firewall apinger: Starting Alarm Pinger, apinger(21973)
Nov 21 23:02:11 firewall apinger: Starting Alarm Pinger, apinger(21798)
Nov 21 23:02:11 firewall php: : DynDns: Running updatedns()
Nov 21 23:02:11 firewall php: : DynDns: Running updatedns()
Nov 21 23:02:11 firewall php: : DynDns: updatedns() starting
Nov 21 23:02:11 firewall php: : DynDns: updatedns() starting
Nov 21 23:02:11 firewall php: : DynDns: _detectChange() starting.
Nov 21 23:02:11 firewall php: : DynDns: _checkIP() starting.
Nov 21 23:02:11 firewall php: : DynDns: _detectChange() starting.
Nov 21 23:02:11 firewall php: : DynDns: _checkIP() starting.
Nov 21 23:02:11 firewall php: : DynDns debug information: 24.x.x.x extracted from local system.
Nov 21 23:02:11 firewall php: : DynDns: Current WAN IP: 24.x.x.x
Nov 21 23:02:11 firewall php: : DynDns debug information: 24.x.x.x extracted from local system.
Nov 21 23:02:11 firewall php: : DynDns: Current WAN IP: 24.x.x.x
Nov 21 23:02:11 firewall php: : DynDns: Cached IP: 0.0.0.0
Nov 21 23:02:11 firewall php: : DynDns debug information: DynDns: cacheIP != wan_ip. Updating. Cached IP: 0.0.0.0 WAN IP: 24.x.x.x
Nov 21 23:02:11 firewall php: : DynDns: DynDns _update() starting.
Nov 21 23:02:11 firewall php: : DynDns: Cached IP: 0.0.0.0
Nov 21 23:02:11 firewall php: : DynDns debug information: DynDns: cacheIP != wan_ip. Updating. Cached IP: 0.0.0.0 WAN IP: 24.x.x.x
Nov 21 23:02:11 firewall php: : DynDns: DynDns _update() starting.
Nov 21 23:02:13 firewall dnsmasq39846: reading /etc/resolv.conf
Nov 21 23:02:13 firewall dnsmasq39846: using nameserver 68.87.78.134#53
Nov 21 23:02:13 firewall dnsmasq39846: using nameserver 68.87.76.182#53
Nov 21 23:02:18 firewall php: : Curl error occurred: Couldn't resolve host 'members.dyndns.org'
Nov 21 23:02:18 firewall php: : Curl error occurred: Couldn't resolve host 'members.dyndns.org'
Nov 21 23:02:18 firewall php: : DynDns: DynDns _checkStatus() starting.
Nov 21 23:02:18 firewall php: : DynDns: Current Service: dyndns
Nov 21 23:02:18 firewall php: : DynDns: DynDns _checkStatus() starting.
Nov 21 23:02:18 firewall php: : DynDns: Current Service: dyndns
Nov 21 23:02:18 firewall php: : phpDynDNS: PAYLOAD:
Nov 21 23:02:18 firewall php: : phpDynDNS: PAYLOAD:
Nov 21 23:02:18 firewall php: : phpDynDNS: (Unknown Response)
Nov 21 23:02:18 firewall php: : phpDynDNS: (Unknown Response)
Nov 21 23:02:24 firewall php: : Resyncing openvpn instances configurations for interface WAN.
I went to edit the dyndns rule, and saved it again.
This triggered the script to run again, and this time it worked.
(Exact same IP and DNS servers, only everything succeeded)
I guess maybe Comcast takes a few seconds after the interface comes up before they can reply to DNS queries.
Would it be possible for the dyndns script to retry after maybe 30 seconds if it failed?
Updated by Hugo Sousa about 14 years ago
Same problem. Dyndns(dynamic) only updates when saving.
No wildcards
Full new install no config restore.
ADSL is a DSL PPPoE link in bridged (dumb modem) mode
wan is nic card connected to fibre modem
lan and vlan
2.0-BETA4 (amd64)
built on Mon Nov 22 12:02:04 UTC 2010
Pentium(R) Dual-Core CPU E5300 @ 2.60GHz
2GB Ram
Packages:Squid, squidguard, phpSysInfo
Log:
Nov 23 07:42:24 kernel: arp:xxx.xxx.xx.xx moved from 00:0f:1f:2f:36:c7 to 00:0f:1f:3b:0e:61 on em1_vlan2
Nov 23 06:50:36 dnsmasq22791: using nameserver xxx.xxx.xxx.xx#53
Nov 23 06:50:36 dnsmasq22791: using nameserver xxx.xxx.xxx.xx#53
Nov 23 06:50:36 dnsmasq22791: using nameserver xxx.xxx.xxx.xx#53
Nov 23 06:50:36 dnsmasq22791: reading /etc/resolv.conf
Nov 23 06:46:28 check_reload_status: reloading filter
Nov 23 06:46:28 check_reload_status: reloading filter
Nov 23 06:46:28 kernel: ovpns1: link state changed to UP
Nov 23 06:46:28 check_reload_status: reloading filter
Nov 23 06:46:28 check_reload_status: reloading filter
Nov 23 06:46:28 kernel: ovpns1: link state changed to DOWN Nov 23 06:46:28 php: :Resyncing openvpn instances configurations for interface ADSL.
Nov 23 06:46:22 php: : phpDynDNS: (Unknown Response)
Nov 23 06:46:22 php: : phpDynDNS: PAYLOAD:
Nov 23 06:46:22 php: : DynDns: Current Service: dyndns
Nov 23 06:46:22 php: : DynDns: DynDns _checkStatus() starting.
Nov 23 06:46:22 php: : Curl error occurred: connect() timed out!
Nov 23 06:45:52 php: : DynDns: DynDns _update() starting.
Nov 23 06:45:52 php: : DynDns debug information: DynDns: cacheIP != wan_ip. Updating. Cached IP: xxx.xxx.79.44 WAN IP: xxx.xxx.79.4
Nov 23 06:45:52 php: : DynDns: Cached IP: xxx.xxx.79.44
Nov 23 06:45:52 php: : DynDns: Current WAN IP: xxx.xxx.79.4
Nov 23 06:45:52 php: : DynDns debug information: xxx.xxx.79.4 extracted from local system.
Nov 23 06:45:52 php: : DynDns: _checkIP() starting.
Nov 23 06:45:52 php: : DynDns: _detectChange() starting.
Nov 23 06:45:52 apinger: Starting Alarm Pinger, apinger(51255)
Nov 23 06:45:52 php: : DynDns: updatedns() starting
Nov 23 06:45:52 php: : DynDns: Running updatedns()
Nov 23 06:45:52 apinger: Exiting on signal 15.
Nov 23 06:45:52 check_reload_status: Rewriting resolv.conf
Nov 23 06:45:50 check_reload_status: Rewriting resolv.conf
Nov 23 01:01:01 php: : phpDynDNS: (Success) IP Address Changed Successfully! (xxx.xxx.79.44)
Nov 23 01:01:01 php: : phpDynDNS: updating cache file /conf/dyndns_opt2dyndns'my.dnsalias.com'.cache: xxx.xxx.79.44
Nov 23 01:01:01 php: : DynDns debug information: xxx.xxx.79.44 extracted from local system.
Nov 23 01:01:01 php: : DynDns: _checkIP() starting.
Nov 23 01:01:01 php: : DynDns: Current Service: dyndns
Nov 23 01:01:01 php: : DynDns: DynDns _checkStatus() starting.
Nov 23 01:01:00 php: : DynDns: DynDns _update() starting.
Nov 23 01:01:00 php: : DynDns debug information: DynDns: cacheIP != wan_ip. Updating. Cached IP: xxx.xxx.79.102 WAN IP: xxx.xxx.79.44
Nov 23 01:01:00 php: : DynDns: Cached IP: xxx.xxx.79.102
Nov 23 01:01:00 php: : DynDns: Current WAN IP: xxx.xxx.79.44
Nov 23 01:01:00 php: : DynDns debug information: xxx.xxx.79.44 extracted from local system.
Nov 23 01:01:00 php: : DynDns: _checkIP() starting.
Nov 23 01:01:00 php: : DynDns: _detectChange() starting.
Nov 23 01:01:00 php: : DynDns: updatedns() starting
Nov 23 01:01:00 php: : DynDns: Running updatedns()
Nov 22 20:12:26 check_reload_status: reloading filter
Nov 22 20:12:26 kernel: ovpns1: link state changed to UP Nov 22 20:12:26 last message repeated 2 times
Nov 22 20:12:26 check_reload_status: reloading filter
Nov 22 20:12:26 kernel: ovpns1: link state changed to DOWN
Nov 22 20:12:26 php: : Resyncing openvpn instances configurations for interface ADSL.
Nov 22 20:12:20 php: : phpDynDNS: (Unknown Response)
Nov 22 20:12:20 php: : phpDynDNS: PAYLOAD:
Nov 22 20:12:20 php: : DynDns: Current Service: dyndns
Nov 22 20:12:20 php: : DynDns: DynDns _checkStatus() starting.
Nov 22 20:12:20 php: : Curl error occurred: connect() timed out!
Nov 22 20:11:55 dnsmasq22791: using nameserver xxx.xxx.xxx.xx#53
Nov 22 20:11:55 dnsmasq22791: using nameserver xxx.xxx.xxx.xx#53
Nov 22 20:11:55 dnsmasq22791: using nameserver xxx.xxx.xx.xx#53
Nov 22 20:11:55 dnsmasq22791: reading /etc/resolv.conf
Nov 22 20:11:50 php: : DynDns: DynDns _update() starting
Nov 22 20:11:50 php: : DynDns debug information: DynDns: cacheIP != wan_ip. Updating. Cached IP: xxx.xxx.79.102 WAN IP: xxx.xxx.79.44
Nov 22 20:11:50 php: : DynDns: Cached IP: xxx.xxx.79.102
Nov 22 20:11:50 php: : DynDns: Current WAN IP: xxx.xxx.79.44
Nov 22 20:11:50 php: : DynDns debug information: xxx.xxx.79.44 extracted from local system.
Nov 22 20:11:50 php: : DynDns: _checkIP() starting.
Nov 22 20:11:50 php: : DynDns: _detectChange() starting. Nov 22 20:11:50 php: : DynDns: updatedns() starting
Nov 22 20:11:50 php: : DynDns: Running updatedns()
Nov 22 20:11:50 apinger: Starting Alarm Pinger, apinger(10966)
Nov 22 20:11:50 apinger: Exiting on signal 15.
Nov 22 20:11:50 check_reload_status: Rewriting resolv.conf
Updated by Ermal Luçi about 14 years ago
@Jeppe Oland
can you try with a new snapshot i committed fix to retry resolving 3 times before bailing.
@Hugo please try with the forums your problem is not related to this ticket.
Updated by Jeppe Oland about 14 years ago
Can you try with a new snapshot i committed fix to retry resolving 3 times before bailing.
Will do ... but with the holidays I can't verify until sometime next week.
One question about the retry logic ... regarding safety:
What happens in my case, if the connection comes up with the 192.x.x.x address. You try up to three times, but before it completes that, the IP is released and a new is given out.
Will 2 scripts run at the same time?
Can that cause problems?
Updated by Jeppe Oland almost 14 years ago
Sorry, but it doesn't seem to be working.
I tested with a clean install of pfSense-2.0-BETA4-20101201-1616.iso followed by a config restore.
During all this, the cable modem was powered off.
After pfSense was booted successfully with my configuration, I powered on the cable modem.
Failure is the same as before, and I don't see any retries.
Updated by Jeppe Oland almost 14 years ago
Trust me - I tried.
Yesterday, the server kept giving me "Internal error" whenever I updated this bug ... other bugs worked fine though.
To add more detail, here are some log snippets.
First IP assignment (bogus 192.168.x.x address local to the modem):
Dec 1 23:54:11 firewall php: : rc.newwanip: on (IP address: 192.168.100.10) (interface: wan) (real interface: em1).
Dec 1 23:54:11 firewall apinger: Starting Alarm Pinger, apinger(6180)
Dec 1 23:54:11 firewall apinger: No usable targets found, exiting
Dec 1 23:54:11 firewall php: : DynDns: Running updatedns()
Dec 1 23:54:11 firewall php: : DynDns: updatedns() starting
Dec 1 23:54:11 firewall php: : DynDns: _detectChange() starting.
Dec 1 23:54:11 firewall php: : DynDns: _checkIP() starting.
Dec 1 23:54:11 firewall php: : Dyndns debug information: Could not resolve checkip.dyndns.org to ip using interface ip 192.168.100.10.
Dec 1 23:54:11 firewall php: : DynDns: Current WAN IP: 192.168.100.10
Dec 1 23:54:11 firewall php: : DynDns: No Cached IP found.
Dec 1 23:54:11 firewall php: : DynDns debug information: DynDns: cacheIP != wan_ip. Updating. Cached IP: 0.0.0.0 WAN IP: 192.168.100.10 Inital update.
Dec 1 23:54:11 firewall php: : DynDns: DynDns _update() starting.
Dec 1 23:54:11 firewall php: : Curl error occurred: Couldn't resolve host 'members.dyndns.org'
Dec 1 23:54:11 firewall php: : DynDns: DynDns _checkStatus() starting.
Dec 1 23:54:11 firewall php: : DynDns: Current Service: dyndns
Dec 1 23:54:11 firewall php: : phpDynDNS: PAYLOAD:
Dec 1 23:54:11 firewall php: : phpDynDNS: (Unknown Response)
A few seconds later, the new IP is handed out:
Dec 1 23:55:14 firewall php: : rc.newwanip: on (IP address: 24.x.x.x) (interface: wan) (real interface: em1).
Dec 1 23:55:14 firewall php: : ROUTING: change default route to 24.x.x.1
Dec 1 23:55:14 firewall apinger: Starting Alarm Pinger, apinger(35932)
Dec 1 23:55:14 firewall php: : DynDns: Running updatedns()
Dec 1 23:55:14 firewall php: : DynDns: updatedns() starting
Dec 1 23:55:14 firewall php: : DynDns: _detectChange() starting.
Dec 1 23:55:14 firewall php: : DynDns: _checkIP() starting.
Dec 1 23:55:14 firewall php: : DynDns debug information: 24.x.x.x extracted from local system.
Dec 1 23:55:14 firewall php: : DynDns: Current WAN IP: 24.x.x.x
Dec 1 23:55:14 firewall php: : DynDns: Cached IP: 0.0.0.0
Dec 1 23:55:14 firewall php: : DynDns debug information: DynDns: cacheIP != wan_ip. Updating. Cached IP: 0.0.0.0 WAN IP: 24.x.x.x
Dec 1 23:55:14 firewall php: : DynDns: DynDns _update() starting.
Dec 1 23:55:17 firewall dnsmasq34774: reading /etc/resolv.conf
Dec 1 23:55:17 firewall dnsmasq34774: using nameserver 68.87.78.134#53
Dec 1 23:55:17 firewall dnsmasq34774: using nameserver 68.87.76.182#53
Dec 1 23:55:21 firewall php: : Curl error occurred: Couldn't resolve host 'members.dyndns.org'
Dec 1 23:55:21 firewall php: : DynDns: DynDns _checkStatus() starting.
Dec 1 23:55:21 firewall php: : DynDns: Current Service: dyndns
Dec 1 23:55:21 firewall php: : phpDynDNS: PAYLOAD:
Dec 1 23:55:21 firewall php: : phpDynDNS: (Unknown Response)
Note that on the first failure, both checkip.dyndns.org and members.dyndns.org fail.
In the second failure there is no mention of checkip failing ... and there is no retry logic on curl.
Manually running the /etc/rc.dyndns.update script after the connection is verified working succeeds.
Updated by Ermal Luçi almost 14 years ago
It looks strange to me that your dns updates during dyndns running which is highly unlikely to happen!
Are you on dhcp link?
Updated by Jeppe Oland almost 14 years ago
Yes, the connection is Comcast Cable with DHCP.
I agree it seems strange, but it happens every time.
Thankfully, they give me the same IP almost every time, so I survive.
It looks strange to me that your dns updates during dyndns running which is highly unlikely to happen!
What do you mean "dns updates during dyndns running"?
What seems more likely is that DNS simply does not work for a second after the IP is delivered.
I looked at the script code, and the flow is this:
1) Cablemodem delivers a local (192.168.x.x) address since the connection hasn't established yet.
2) Update script runs, and "_checkIP" fails to hit checkip.dyndns.org as mentioned in the log.
3) Cablemode connects, revokes the local address and issues a new routable address.
4) Update script runs. Since the new address (24.x.x.x) is publicly routable, "_checkIP" does nothing
and simply uses the address as-is.
5) Since DNS is not working yet, "_update" fails to access members.dyndns.org
After this, there is no retry logic, and dyndns will not be updated.
Updated by R B almost 14 years ago
Just re-installed a fresh image on a different CF card "Version 2.0-BETA5 (i386) built on Mon Jan 3 04:24:15 EST 2011", platform "nanobsd (4g)".
Exhibits exact same behaviour as outlined in comment 15 above, DynDNS does not update when the bridged DSL connection drops and is re-connected.
Updated by Ermal Luçi almost 14 years ago
Can you try again with new snapshots i added some changes to make dns reloading faster and have more time to reload before dyndns gets called.
Updated by R B almost 14 years ago
Updated to "Version 2.0-BETA5 (i386) built on Thu Jan 20 23:14:10 EST 2011", same behavior:
1. Unplug working bridged DSL connection with correct DynDNS entry
2. Wait until system acknowledges the connection as fully down and is attempting re-connections ("ppp: [wan_link0] LCP: state change Stopped --> Starting" log entries)
3. Plug DSL connection back in, wait for pfSense to sense and re-build PPP WAN connection
4. Observe logs, no indication updatedns() was run or even attempted; nslookup concurs
5. Wait 60 seconds, still no update
6. Forcefully reset DDNS by clicking edit/save
Updated by Jim Pingle almost 14 years ago
Post your system log from the time of the reconnect, especially anything that mentions rc.newwanip and entries around it.
Updated by R B almost 14 years ago
- File wan-test.log wan-test.log added
Attaching log from start of test through end.
Updated by M Schweitzer almost 14 years ago
I think this can be closed now...
I've been testing it for about Two weeks and it works fine.
Updated by R B almost 14 years ago
Unfortunately I disagree - still not seeing DDNS update on a clean install of the NanoBSD images as noted in comment 31 above and updated to snapshot dated "Wed Feb 16 03:53:41 EST 2011". Same behavior as before.
Of note also is that BETA5 has been fat-fingered to BEAT5 in recent images.
Updated by M Schweitzer almost 14 years ago
R B wrote:
Unfortunately I disagree - still not seeing DDNS update on a clean install of the NanoBSD images as noted in comment 31 above and updated to snapshot dated "Wed Feb 16 03:53:41 EST 2011". Same behavior as before.
Of note also is that BETA5 has been fat-fingered to BEAT5 in recent images.
This is gonna sound really stupid but:
Do me a favor and see if you maybe by accidend checked the "disable" checkbox at the top of the dyndns account settings.... (i did this once and it took me three days to notice this...)
Updated by R B almost 14 years ago
The only thing it's less stupid than is finding out that was the problem. I have no idea when or how that got checked - perhaps because I've come to (perhaps incorrectly) expect the checkbox at the top of a group of settings in pfSense to have the opposite meaning, to enable.
Thanks to all for helpfully troubleshooting my failure to read carefully. No idea if Jeppe's issue was addressed, but mine can't really be addressed by the pfSense team.
Updated by Chris Buechler almost 14 years ago
- Status changed from Feedback to Resolved
Updated by Ross Williamson over 13 years ago
I am seeing this behaviour on RC1 (and was also on several Beta 5 builds prior to updating to RC1) with a 3G connection. In this case I'm not doing anything to trigger the update, the ISP is doing that for me. The status page is updated with the new IP and in Dynamic DNS the new IP is shown next to "Cached IP" but the IP in the dynamic DNS provider (No-IP in my case) never gets updated.
A reboot of the firewall is often required to fix this situation, or sometimes simply disabling and re-enabling that particular dynamic DNS entry works. I can confirm "Disabled" is not checked. Happy to provide any logs if requested.