Bug. UrBackup Restore CD 2.3.1 and errors: "ERROR: Connection timeout" and “The server stopped responding”. Full report and solution

[Dmitrius7]

Server: UrBackup 2.4.12, debian 10.3 64bit / Linux 4.19.0-8-amd64).
Restore from: urbackup_restore_2.3.1.iso
The MAC address of this PC is 22:B6:48:87:8F:ED

I want to restore image backup to new clean PC. For it I boot from urbackup_restore_2.3.1.iso

Errors: “ERROR: Connection timeout” and “The server stopped responding”.

Full report and solution:

Select keymap

Confirm

Log in

Select computer

Select date and volume

Select drive to which I want to restore

Confirm

The process is started

Check it in the web.

Check it again, It looks like normal

Then after few minutes the restore process in web interface disappeared.

And on the client (UrBackup Restore CD) errors:

• ERROR: Connection timeout
• ERROR: Read Timeout.
  
  

And after few time we have error “The server stopped responding”!

It looks like network problem. I did a few tests and the problem was related with dhcp lease time.

Full test:
Reboot PC and start again UrBackup Restore CD.
Watch on the router dhcp status and leases, and check ping.

As we see the client (UrBackup Restore CD) got IP 192.168.0.176 by DHCP server and expires after 04 min 14 sec.

Ping 192.168.0.176 is normal.

Then start backup again.

Check again.

Check again after 10 sec.
Lease time was expired, normally PC have to got IP again but it don’t do it .
The process of restore was stopped.

Then I changed lease time on the router to 24 hours, reboot pc and start restore again.
It worked fine! Restore was successful!

Result report and solution:

If the client (UrBackup Restore CD) got IP by DHCP server and lease time of IP address expired, the host computer instead of re-get ip address (renew) don’t do it! And host lose connection with server.

The solution is to change lease time on the router for example to 24 hours.

As I understand to fix this issue in UrBackup Restore CD have to re-get ip address (renew).

I hope my report helps and developers fix it.

[uroni]

Please use CTRL + ALT + F2, then sudo -i + journalctl -u wicd to have a look at the network config log.

[Dmitrius7]

Client got IP address at 23:56.
Watch ping. Ping still is Ok.
Watch sudo -i + journalctl -u wicd

Wait when ping will be lost.
Now ping is lost.

Watch sudo -i + journalctl -u wicd
As I see nothing changed.

Check ifconfig. There is no IP address.

Try to restart networking, check ifconfig and journalctl -u wicd

Still there is no IP address. The log don’t have new strings.

As I understand host don’t re-get ip address (renew).

[uroni]

Perhaps a bug with dhclient then (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1093803 https://bugzilla.redhat.com/show_bug.cgi?id=1093803 , you should check the system time before and after lease). This bug should be reported to either wicd, debian, dhclient…

[Dmitrius7]

I will check it tomorrow.

[Dmitrius7]

You were right!

dhclient doesn’t RENEW at proper moment when system time shifts back.
I checked it with the lastest version isc-dhcp-client 4.4.2 (22 January 2020) but it still doesn’t work.

In my case I use proxmox virtualization platform. Hypervisor sets BIOS time to the local time (UTC +3)!

The operating system starts up with time 18:21 (UTC +3), then interfaces are being brought up by usage of dhclient, then goes NTP synchronization - and time goes back on three hours and becomes 15:21. With short leases, it leads to the bringing ifaces down. For this test lease time at the router 1 minute (usually I use 10 minutes).

Technically dhcp-client is not broken, it just wait a time when it has to renew IP address, in my case:

• 18:21:48 dhclient [926] : bount to 192.168.0.176 -- renewal in 26 seconds.

• so dhclient will renew IP address at 18:22:14

• then time shifts back to 15:21:48 (shifts back 3 hours earlier)

• after minute system time is 15:22:48 and dhclient don’t renew IP, because it have to do it at 18:22:14.

• dhclient doesn’t know that the time shifts back and will receive ip address at 18:22:14 (not after 26 seconds, but after 3 hours). (I tested it).

It is not bug of UrBackup. I will report to isc-dhcp-client’s developers.

[Dmitrius7]

The problem has been known for several years, but even in the latest version from 22 January 2020 it has not been fixed.

I reported to isc-dhcp-client’s developers (link https://gitlab.isc.org/isc-projects/dhcp/-/issues/99).

As I understand for now the single solution is to change lease time on the router for a long time for example 24 hours.

[Dominic_Boisvert]

Static addressing within dhcp scope and good gateway+subnet worked fine in urbackup gui.