DHCP: Repeat DHCP discovery on timeout

It is a bad practice to have DHCP discovery without timeout
and retries. In case discovery packet gets lost boot stucks.

Beside this there is an interesting phenomena on some systems.
A few first DHCP discovery packets sent on boot get lost in some cases.

This started to happen from time to time on my KVM system and almost
every time on my Xen system after installing recent Fedora Core updates.
Packet leaves VM's interface but never arrives to bridge interface.
The packet itself built properly and arrives to DHCP server just fine
after a few retransmissions.

Most probably this phenomena is a bug (or limitation) in the current
Linux bridge version so this patch is actually a work-around, but
since in general case it is a good idea to have DHCP timeouts/retries
it worth to have it anyway.

Signed-off-by: Dmitry Fleytman <dmitry@daynix.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

core/dhcp.cc

@@ -574,16 +574,23 @@ namespace dhcp {
         _dhcp_thread = new sched::thread([&] { dhcp_worker_fn(); });
         _dhcp_thread->start();
 
-        // Send discover packets!
-        for (auto &it: _universe) {
-            it.second->discover();
-        }
+        do {
+            // Send discover packets!
+            for (auto &it: _universe) {
+                it.second->discover();
+            }
 
-        if (wait) {
-            dhcp_i("Waiting for IP...");
-            _waiter = sched::thread::current();
-            sched::thread::wait_until([&]{ return _have_ip; });
-        }
+            if (wait) {
+                dhcp_i("Waiting for IP...");
+                _waiter = sched::thread::current();
+
+                sched::timer t(*sched::thread::current());
+                u64 cur_time = clock::get()->time();
+                t.set(cur_time + 3_s);
+
+                sched::thread::wait_until([&]{ return _have_ip || t.expired(); });
+            }
+        } while (!_have_ip && wait);
     }
 
     void dhcp_worker::dhcp_worker_fn()