Get online support
I have security cameras installed that I wish to manage at a property 3 hours away and all was fine before transfer to the NBN. Now due to dynamic IP addressing, im forced to use NO-IP to access and manage the security system at the property. I have successfully entered the details in the modem's DDNS settings page and pressed "SAVE". I then log out and then back on to verify that the settings have been saved, all good.
I switch off Wi-Fi on my device and try to connect via the http using my no-ip address, Hey presto! all is working fine, all good.
The issue that I have is this.
After a time could be an hour, could be a week when at home (3 hours away), i try to log in and find that my browser cannot access the log in page of the NVR, P2P connection is still working so I can see video from cameras, but I cannot manage the NVR with this.
Upon investigation I discovered that in the DDNS settings of the router had mysteriously reverted to the default off state. To be clear the setting has not been cleared but has been deactivated by unticking the check box, my no-ip setup is still in router memory, when no-ip provider is selected and the box is re-ticked everything works again. Very odd!
As a work around, using my no-ip address I resorted to trying to set up remote router management via http so that I could view the external IP address at the property when it changed and gain access by this method, but I found that the exact same thing is happening.
In the router Admin settings→remote admin via http, the check boxes are being unchecked after a time by some mysterious action. Again the settings are retained, when tick boxes are re-checked my "no-ip addressort number" re-appear and everything works again till the next time the router decides to deactivate them. Im always carefull to click the save button when performing these changes because i have been caught out in the past with this.
Im not sure if im overlooking something basic here, please help as acquiring a fixed IP business account is not an option for me.
Hi Marko67.
Are there any indications in the System Log about settings being changed? Or any unusual events.
Hi Marko67.
Here are some suggestions.
If the DDNS and remote management settings are not being remembered across reboot, it might be a firmware bug. You could make a new post with the router's hardware and firmware versions for TPG to check if the firmware has a later version. TPG download firmware on request. Something to do when you are next spending a few days there.
Two users asked about firmware levels for their Archer routers.
Archer VR1600v v1 00000000. Current Firmware 0.1.0 0.9.1 v5006.0 Build 180828 Rel.56416n
Archer VR1600v v2 00000000. Current Firmware 0.1.0 0.9.1 v5006.0 Build 190228 Rel.72265n
I didn't see Automatic Device Rebooting in the manual I have. Maybe it's a newer function. Is there any chance you get blackouts up there? That should be the only thing to cause a reboot. A line fault causing a reconnection and a new ip address should be handled by DDNS.
There must be lots of people using DDNS but I've not seen any posts raising this issue.
Last resort is to use another brand of router in place of the Archer if you don't use the VOIP phone service from TPG.
If the firmware upgrade doesn't fix it and you want to keep the router, you will have to investigate the router's log for any clues. You can also check the account usage in "My Account" to see if there are reconnects.
Is the router time sync'ed to a network time server so the times are correct? This will help when examining the router log.
When you get back there, save the router's log file on your computer so you have something to compare later.
I don't know what might be recorded on the log. Type=All and Level=Debug will show most info. You will have to experiment a bit. Reboot the router and see what messages come up. Save that log. Turn the router off/on and let it reconnect and save that log. You might simulate a line connection fault by pulling out the cable between NBN box and wall socket. Compare these new logs to the original log so you can account for the router's activities.
Hi again david64.
Visited the property this weekend and tried some of the things you suggested.
Attached is the router log after clearing the log 0n 24-10-20 and the firmware version.
Not being familiar with networking i do not realy follow what the logs mean but feel free to take a look to see if there is an issue obvious to you.
One thing i noticed during the stay was that our kodi streaming box would stop streaming (freeze) then restart after a short time on multiple occasions.
2016-01-01 11:00:35 [5] System: DSL training G.994
2016-01-01 11:00:44 [5] DHCPD: Recv DISCOVER from 60:09:C3:78:A75
2016-01-01 11:00:44 [5] DHCPD: Send OFFER with ip 192.168.1.100
2016-01-01 11:00:44 [5] DHCPD: Recv REQUEST from 60:09:C3:78:A75
2016-01-01 11:00:44 [5] DHCPD: Wrong Server id or request an invalid ip
2016-01-01 11:00:44 [5] DHCPD: Send NAK
2016-01-01 11:00:48 [5] DHCPD: Recv DISCOVER from 60:09:C3:78:A75
2016-01-01 11:00:48 [5] DHCPD: Send OFFER with ip 192.168.1.101
2016-01-01 11:00:48 [5] DHCPD: Recv REQUEST from 60:09:C3:78:A75
2016-01-01 11:00:48 [5] DHCPD: Send ACK to 192.168.1.101
2016-01-01 11:00:51 [5] System: DSL training G.993 started
2016-01-01 11:01:06 [5] DHCPD: Recv DISCOVER from 24:18:1D:9B:AA:BD
2016-01-01 11:01:06 [5] DHCPD: Send OFFER with ip 192.168.1.102
2016-01-01 11:01:06 [5] DHCPD: Recv REQUEST from 24:18:1D:9B:AA:BD
2016-01-01 11:01:06 [5] DHCPD: Send ACK to 192.168.1.102
2016-01-01 11:03:25 [5] System: DSL training G.993 channel analysis
2016-01-01 11:03:26 [5] System: DSL link up
2016-01-01 11:03:31 [6] PPP: ppp1 sent [PADI Host-Uniq(0x00000c9d)]
2016-01-01 11:03:31 [6] PPP: ppp1 sent [LCP ConfReq id=0x1 <mru 1480> <magic 0x225239f7>]
2016-01-01 11:03:31 [6] PPP: ppp1 rcvd [LCP ConfReq id=0x1 <mru 1492> <auth pap> <magic 0x994000b7>]
2016-01-01 11:03:31 [6] PPP: ppp1 sent [LCP ConfAck id=0x1 <mru 1492> <auth pap> <magic 0x994000b7>]
2016-01-01 11:03:31 [6] PPP: ppp1 rcvd [LCP ConfNak id=0x1 <mru 1492>]
2016-01-01 11:03:31 [6] PPP: ppp1 sent [LCP ConfReq id=0x2 <mru 1492> <magic 0x225239f7>]
2016-01-01 11:03:31 [6] PPP: ppp1 rcvd [LCP ConfAck id=0x2 <mru 1492> <magic 0x225239f7>]
2016-01-01 11:03:31 [6] PPP: ppp1 sent [LCP EchoReq id=0x0 magic=0x225239f7]
2016-01-01 11:03:31 [6] PPP: ppp1 sent [PAP AuthReq id=0x1 user="lironis1945@tpg.com.au" password=<hidden>]
2016-01-01 11:03:31 [6] PPP: ppp1 rcvd [LCP EchoRep id=0x0 magic=0x994000b7]
2016-01-01 11:03:32 [6] PPP: ppp1 rcvd [PAP AuthAck id=0x1 ""]
2016-01-01 11:03:32 [6] PPP: ppp1 sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
2016-01-01 11:03:32 [6] PPP: ppp1 rcvd [IPCP ConfReq id=0x1 <addr 10.20.25.233>]
2016-01-01 11:03:32 [6] PPP: ppp1 sent [IPCP ConfAck id=0x1 <addr 10.20.25.233>]
2016-01-01 11:03:32 [6] PPP: ppp1 rcvd [IPCP ConfNak id=0x1 <addr 123.243.114.216> <ms-dns1 203.12.160.35> <ms-dns2 203.12.16
2016-01-01 11:03:32 [6] PPP: ppp1 sent [IPCP ConfReq id=0x2 <addr 123.243.114.216> <ms-dns1 203.12.160.35> <ms-dns2 203.12.16
2016-01-01 11:03:32 [6] PPP: ppp1 rcvd [IPCP ConfAck id=0x2 <addr 123.243.114.216> <ms-dns1 203.12.160.35> <ms-dns2 203.12.16
2016-01-01 11:03:33 [5] VoIP: enable SIP stack due to intf(123.243.114.216) is up.
2020-10-25 08:00:33 [6] VoIP: get ip(172.26.0.17) for domain(uni-v1.tpg.com.au)
2020-10-25 08:00:33 [6] VoIP: get ip(172.26.0.97) for domain(uni-v1.tpg.com.au)
2020-10-25 08:00:33 [6] VoIP: get ip(172.26.0.82) for domain(uni-v1.tpg.com.au)
2020-10-25 08:00:33 [6] VoIP: get ip(172.26.0.1) for domain(uni-v1.tpg.com.au)
2020-10-25 08:00:33 [6] VoIP: get ip(172.26.0.65) for domain(uni-v1.tpg.com.au)
2020-10-25 08:00:33 [6] VoIP: get ip(172.26.0.34) for domain(uni-v1.tpg.com.au)
2020-10-25 08:00:33 [6] VoIP: get ip(172.26.0.33) for domain(uni-v1.tpg.com.au)
2020-10-25 08:00:33 [6] VoIP: get ip(172.26.0.98) for domain(uni-v1.tpg.com.au)
2020-10-25 08:00:33 [6] VoIP: get ip(172.26.0.81) for domain(uni-v1.tpg.com.au)
2020-10-25 08:00:33 [6] VoIP: Register to server address 172.26.0.34:5060
2020-10-25 08:00:35 [6] VoIP: get ip(172.26.0.17) for domain(uni-v1.tpg.com.au)
2020-10-25 08:00:35 [6] VoIP: get ip(172.26.0.97) for domain(uni-v1.tpg.com.au)
2020-10-25 08:00:35 [6] VoIP: get ip(172.26.0.82) for domain(uni-v1.tpg.com.au)
2020-10-25 08:00:35 [6] VoIP: get ip(172.26.0.1) for domain(uni-v1.tpg.com.au)
2020-10-25 08:00:35 [6] VoIP: get ip(172.26.0.65) for domain(uni-v1.tpg.com.au)
2020-10-25 08:00:35 [6] VoIP: get ip(172.26.0.34) for domain(uni-v1.tpg.com.au)
2020-10-25 08:00:35 [6] VoIP: get ip(172.26.0.33) for domain(uni-v1.tpg.com.au)
2020-10-25 08:00:35 [6] VoIP: get ip(172.26.0.98) for domain(uni-v1.tpg.com.au)
2020-10-25 08:00:35 [6] VoIP: get ip(172.26.0.81) for domain(uni-v1.tpg.com.au)
2020-10-25 09:54:04 [5] DHCPD: Recv DISCOVER from 6C:C7:EC:B9:32:69
2020-10-25 09:54:04 [5] DHCPD: Send OFFER with ip 192.168.1.103
2020-10-25 09:54:04 [5] DHCPD: Recv REQUEST from 6C:C7:EC:B9:32:69
2020-10-25 09:54:04 [5] DHCPD: Wrong Server id or request an invalid ip
2020-10-25 09:54:04 [5] DHCPD: Send NAK
2020-10-25 09:54:04 [5] DHCPD: Recv DISCOVER from 6C:C7:EC:B9:32:69
2020-10-25 09:54:04 [5] DHCPD: Send OFFER with ip 192.168.1.104
2020-10-25 09:54:04 [5] DHCPD: Recv REQUEST from 6C:C7:EC:B9:32:69
2020-10-25 09:54:05 [5] DHCPD: Send ACK to 192.168.1.104
2020-10-25 10:00:25 [6] VoIP: Register to server address 172.26.0.97:5060
2020-10-25 11:00:21 [6] VoIP: Register to server address 172.26.0.97:5060
2020-10-25 11:21:02 [5] System: LAN2 link down
2020-10-25 12:00:15 [6] VoIP: Register to server address 172.26.0.97:5060
2020-10-25 12:26:18 [5] DHCPD: Recv DISCOVER from 24:18:1D:9B:AA:BD
2020-10-25 12:26:18 [5] DHCPD: Send OFFER with ip 192.168.1.102
2020-10-25 12:26:18 [5] DHCPD: Recv REQUEST from 24:18:1D:9B:AA:BD
2020-10-25 12:26:18 [5] DHCPD: Send ACK to 192.168.1.102
2020-10-25 12:26:19 [5] DHCPD: Recv DISCOVER from 6C:C7:EC:B9:32:69
2020-10-25 12:26:19 [5] DHCPD: Send OFFER with ip 192.168.1.104
2020-10-25 12:26:19 [5] DHCPD: Recv REQUEST from 6C:C7:EC:B9:32:69
2020-10-25 12:26:19 [5] DHCPD: Send ACK to 192.168.1.104
2020-10-25 12:28:39 [5] System: LAN2 link up 100 mbps
2020-10-25 12:28:51 [5] System: LAN2 link down
2020-10-25 12:28:54 [5] System: LAN2 link up 100 mbps
2020-10-25 12:29:10 [5] System: LAN2 link down
2020-10-25 12:29:12 [5] System: LAN2 link up 100 mbps
2020-10-25 12:29:18 [5] DHCPD: Recv DISCOVER from 00:03:AC:32:27:94
2020-10-25 12:29:18 [5] DHCPD: Send OFFER with ip 192.168.1.105
2020-10-25 12:29:18 [5] DHCPD: Recv REQUEST from 00:03:AC:32:27:94
2020-10-25 12:29:18 [5] DHCPD: Send ACK to 192.168.1.105
2020-10-25 12:29:18 [5] System: LAN2 link down
2020-10-25 13:00:10 [6] VoIP: Register to server address 172.26.0.97:5060
2020-10-25 13:00:10 [6] VoIP: Register to server address 172.26.0.97:5060
2020-10-25 14:00:06 [6] VoIP: Register to server address 172.26.0.97:5060
2020-10-25 14:10:39 [5] System: LAN2 link up 100 mbps
2020-10-25 14:10:52 [5] System: LAN2 link down
2020-10-25 14:10:55 [5] System: LAN2 link up 100 mbps
2020-10-25 14:11:10 [5] System: LAN2 link down
2020-10-25 14:11:12 [5] System: LAN2 link up 100 mbps
2020-10-25 14:11:22 [5] DHCPD: Recv DISCOVER from 00:03:AC:32:27:94
2020-10-25 14:11:22 [5] DHCPD: Send OFFER with ip 192.168.1.105
2020-10-25 14:11:22 [5] DHCPD: Recv REQUEST from 00:03:AC:32:27:94
2020-10-25 14:11:22 [5] DHCPD: Send ACK to 192.168.1.105
2020-10-25 14:11:57 [5] DHCPD: Recv DISCOVER from 60:09:C3:78:A75
2020-10-25 14:11:57 [5] DHCPD: Send OFFER with ip 192.168.1.101
2020-10-25 14:11:58 [5] DHCPD: Recv REQUEST from 60:09:C3:78:A75
2020-10-25 14:11:58 [5] DHCPD: Send ACK to 192.168.1.101
2020-10-25 14:26:28 [5] System: LAN2 link down
2020-10-25 14:26:32 [5] System: LAN2 link up 100 mbps
2020-10-25 14:26:45 [5] System: LAN2 link down
2020-10-25 14:26:48 [5] System: LAN2 link up 100 mbps
2020-10-25 14:26:56 [5] System: LAN2 link down
2020-10-25 14:26:59 [5] System: LAN2 link up 100 mbps
2020-10-25 14:27:02 [5] DHCPD: Recv DISCOVER from 00:03:AC:32:27:94
2020-10-25 14:27:02 [5] DHCPD: Send OFFER with ip 192.168.1.105
2020-10-25 14:27:02 [5] DHCPD: Recv REQUEST from 00:03:AC:32:27:94
2020-10-25 14:27:02 [5] DHCPD: Send ACK to 192.168.1.105
2020-10-25 14:27:12 [5] DHCPD: Recv DISCOVER from 60:09:C3:78:A75
2020-10-25 14:27:12 [5] DHCPD: Send OFFER with ip 192.168.1.101
2020-10-25 14:27:12 [5] DHCPD: Recv REQUEST from 60:09:C3:78:A75
2020-10-25 14:27:13 [5] DHCPD: Send ACK to 192.168.1.101
2020-10-25 14:29:37 [5] System: LAN2 link down
2020-10-25 14:29:41 [5] System: LAN2 link up 100 mbps
2020-10-25 14:29:54 [5] System: LAN2 link down
2020-10-25 14:29:57 [5] System: LAN2 link up 100 mbps
2020-10-25 14:30:22 [5] System: LAN2 link down
2020-10-25 14:30:24 [5] System: LAN2 link up 100 mbps
2020-10-25 14:30:29 [5] DHCPD: Recv DISCOVER from 00:03:AC:32:27:94
2020-10-25 14:30:29 [5] DHCPD: Send OFFER with ip 192.168.1.105
2020-10-25 14:30:29 [5] DHCPD: Recv REQUEST from 00:03:AC:32:27:94
2020-10-25 14:30:30 [5] DHCPD: Send ACK to 192.168.1.105
2020-10-25 14:31:06 [5] DHCPD: Recv DISCOVER from 60:09:C3:78:A75
2020-10-25 14:31:06 [5] DHCPD: Send OFFER with ip 192.168.1.101
2020-10-25 14:31:06 [5] DHCPD: Recv REQUEST from 60:09:C3:78:A75
2020-10-25 14:31:07 [5] DHCPD: Send ACK to 192.168.1.101
2020-10-25 14:36:07 [5] System: LAN2 link down
2020-10-25 14:39:21 [5] DHCPD: Recv REQUEST from E8:9A:8F:F4:E7:43
2020-10-25 14:39:22 [5] DHCPD: Send ACK to 192.168.1.107
2020-10-25 14:40:10 [5] DHCPD: Recv INFORM from E8:9A:8F:F4:E7:43
Hi Marko67.
This is from a recent post:
Current firmware version 0.1.0 0.9.1 v5006.0 Build 180828 Rel.56416n Hardware version Archer VR1600v v1 00000000.
You should make a new post asking for firmware update. Include the info that the settings you make are not being saved when router restarts (reboot or power off/on).
What device is on LAN2? It has trouble staying up. Is that the kodi box?
The "discover,offer,request,ack" is the normal way a device gets an ip address from the router. The router has a value for the lease time of ip addresses; the device has to renew its lease before that time expires. But there is more of this activity than there should be. Default time is 1440 minutes (24 hours).
The devices with addresses dot 105 and dot 101 are being affected together, which is strange.
It might be useful to assign a fixed ip address to each camera; an address outside the range of addresses in the dynamic pool.
If the cameras are wifi types, how far from the router are they? Do they use 2.4G or 5G? Any chance of wifi interference from neighbours?
Thank you david64,
All cameras are connected via LAN cables to an NVR which is connected in turn directly to the router via LAN cable (have assigned a fixed ip address for the NVR). A solar inverter is also connected directly to the router to allow remote monitoring.
All other hard wired devices in the house connect to a 8 port ethernet switch which is also connected directly to the router. From your comment above re addresses dot 105 and dot 101 being affected together it looks like the ethernet switch may be the cause of the droppouts but could this account for the remainder of the arratic behaviour exhibited by the router?
Hi Marko67.
What is the fixed ip you have for the NVR? Is it outside the dynamic pool? Inverter should be fixed also. Same deal.
If LAN2 is as bad as shown in the log, can you do without the switch for a short while? Just connect directly to router and see what happens. You can connect inverter, NVR, kodi plus one other device. Could the last two connect with wifi?
Is there a spare port on the router that you can connect the switch? Check the cable. If switch is any distance from the router, any electrical interference? Unless the switch is faulty. Don't know what would make it drop out like that.
Hi again david64
Not too sure what is meant by dynamic pool.
Im not at the property at this time so just going from memory.
Cannot connect directly to the router because it is tucked away (hidden) with the NVR away from the below wired devices.
The NVR was set by me to 192.168.1.110, i fixed this using the binding setting in the router.
The solar inverter is 192.168.1.108 again i fixed this using the router's binding setting.
Both of these connected directly to the router.
The third connection on the router is to the switch (about 12m away in the games room).
Connected directly to switch located in other rooms are 2 x kodi boxes, 1 x gaming console, 1 x PC.
Electrical interference could be an issue because all the ethernet outlets are installed right next to power points at all locations.
This set up has worked fine for me for the last 3-4 years, issues have only started in the last 4-5 months so the switch itself would seem to be the most likey culprit. The switch was repurposed from an older install and is very old, approx 10yo, so i think this should be replaced as a matter of course, will look for a replacement today.
Of greater urgency for me is the issue of self deleting settings, I have started a new thread requesting a firmware upgrade as you suggested, hopefully i will get a positive response soon.
Thanks again david64 for taking the time to help, i have learned quite a lot from these short chats
Hi Marko67.
Do you also use port forwarding to access the inverter and NVR from internet? When the firmware is upgraded, all your settings might be cleared (port forwarding, DDNS and reservations).
The dynamic pool is used for devices where the ip address is irrelevant. Fixed ip addresses should be allocated outside the range of the pool. Default pool is 100 to 199.
(Go to Advanced > Network > LAN Settings page and select IPv4. Specify the IP Address Pool, the start address and end address must be on the same subnet with LAN IP. The modem router will assign addresses within this specified range to its clients. It is from 192.168.1.100 to 192.168.1.199 by default.)