dhcpv6: Check if network is already disconnected in DAD reply

It is possible that the network is disconnected while we are
waiting DAD (Duplicate Address Detection) to finish.
DAD is done quite fast (timeout is 1 sec) so this is quite
unlikely to trigger but possible as seen by this valgrind
report. Because the network disappeared while waiting DAD
reply, the network pointer is set to NULL and we must
not access it.

connmand[4345]: src/dhcpv6.c:dad_reply() user 0x530d540 reply (nil) len 0 address 2001:db8:dd:bf:b71c:19ad:e6f5:7a93 index 3 data 0x530d540
connmand[4345]: src/dhcpv6.c:dad_reply() DAD succeed for 2001:db8:dd:bf:b71c:19ad:e6f5:7a93
connmand[4345]: src/network.c:dhcpv6_callback() status 1
connmand[4345]: src/network.c:connman_network_set_error() network (nil) error 2
==4345== Invalid write of size 1
==4345==    at 0x80853D9: connman_network_set_error (network.c:1365)
==4345==    by 0x80855DF: dhcpv6_callback (network.c:398)
==4345==    by 0x80A9987: dad_reply (dhcpv6.c:807)
==4345==    by 0x80A06AA: ns_timeout_cb (inet.c:1852)
==4345==    by 0x4D63DDAF: g_timeout_dispatch (gmain.c:3882)
==4345==    by 0x4D63D0BA: g_main_context_dispatch (gmain.c:2539)
==4345==    by 0x4D63D45F: g_main_context_iterate.isra.21 (gmain.c:3146)
==4345==    by 0x4D63D8C2: g_main_loop_run (gmain.c:3340)
==4345==    by 0x80542B2: main (main.c:688)
==4345==  Address 0x38 is not stack'd, malloc'd or (recently) free'd
==4345==
gdhcp: Request an actual IP address when rebinding

We need to specify a requested IP address when our DHCP client state
is REBINDING as well as REQUESTING and REBOOTING; or else we end up
sending a DHCP request for 0.0.0.0, which generally just gets ignored.
dhcpv6: Fix timer calculation

Take into account the current and starting time when computing the
next timeout. When T2 has elapsed, rebind should start immediately.

Thanks to Dan Williams for reporting this.
dhcpv6: Use proper default values fot T1 and T2

If T1 or T2 are not set by the server, use the recommended default
DHCPv6 server values 0.5 and 0.8. See RFC 3315, section 22.4.

Thanks to Dan Williams for reporting this issue.
dhcp: Fix crash when switching networks

Sometimes while switching network dhcp_initialize() fails because
interface is not up and hence dhcp->dhcp_client remains NULL. Here we
don't check return type of dhcp_initialize() and go on to call function
g_dhcp_client_start() and crash occurs.

Below trace is obtained when connman crashes:
connmand[19034]: Aborting (signal 11) [/usr/local/sbin/connmand]
connmand[19034]: ++++++++ backtrace ++++++++
connmand[19034]: #0  0xb7630f38 in /lib/i386-linux-gnu/libpthread.so.0
connmand[19034]: #1  0x8055a22 in debug() at client.c:0
connmand[19034]: #2  0x8058837 in g_dhcp_client_start() at polkit.c:0
connmand[19034]: #3  0x80a4772 in __connman_dhcp_start() at polkit.c:0
connmand[19034]: #4  0x8082a80 in set_connected.part.8() at network.c:0
connmand[19034]: #5  0x8082f7f in connman_network_set_connected() at
??:0
connmand[19034]: #6  0x805f921 in eth_network_connect() at ethernet.c:0
connmand[19034]: #7  0x8082dc3 in __connman_network_connect() at
polkit.c:0
connmand[19034]: #8  0x808e7e4 in __connman_service_connect() at
polkit.c:0
connmand[19034]: #9  0x808eef0 in auto_connect_service() at service.c:0
connmand[19034]: #10 0x808efde in run_auto_connect() at service.c:0
connmand[19034]: #11 0xb76cea3f in /lib/i386-linux-gnu/libglib-2.0.so.0
connmand[19034]: #12 0xb76cdd46 in /lib/i386-linux-gnu/libglib-2.0.so.0
connmand[19034]: #13 0xb76ce0e5 in /lib/i386-linux-gnu/libglib-2.0.so.0
connmand[19034]: #14 0xb76ce52b in /lib/i386-linux-gnu/libglib-2.0.so.0
connmand[19034]: #15 0x80544cd in main() at polkit.c:0
connmand[19034]: #16 0xb739b4d3 in /lib/i386-linux-gnu/libc.so.6
connmand[19034]: +++++++++++++++++++++++++++
AUTHORS: Mention Slava's, Aaron's and Saurav's contributions
agent: The reply of the error callback might be NULL

This fixes a crash when calling connman_agent_cancel(), where
agent_finalize_pending() is called with a NULL reply which is then used
in the callback.
device: Make sure the device is up and running before enabling it

It can happen that, after a unproper ConnMan exit, a device is still up.
Once ConnMan is restarted cleanup_devices() will put this device down.
But then, it will never set it up again.

04:08:45 connmand[254]: src/device.c:__connman_device_init()
04:08:45 connmand[254]: src/inet.c:__connman_inet_get_address_netmask() index 2
04:08:45 connmand[254]: src/device.c:cleanup_devices() cleaning up wlan0 index 2
(...)
04:08:45 connmand[254]: wlan0 {newlink} index 2 operstate 2 <DOWN>
(...)
04:08:45 connmand[254]: plugins/wifi.c:wifi_newlink() index 2 flags 36866 change 0
04:08:45 connmand[254]: src/technology.c:__connman_technology_add_device() device 0x35e8a8 type WiFi
04:08:45 connmand[254]: src/technology.c:technology_get() type 3
04:08:45 connmand[254]: src/technology.c:technology_find() type 3
04:08:45 connmand[254]: src/device.c:__connman_device_enable() device 0x35e8a8

Reported by Richard Röjfors <richard.rojfors@gmail.com>
Merge pull request #116 from tigeli/upstream

[connman] Upstream patches for possible crashes, various dhcp issues and to make sure device is up before enabling it