[connman] Don't treat counters for cellular services differently.

Previously only the usage statistics for available cellular services
were being sent. The reasoning being that the user is only interested
in the usage for the currently inserted SIM card. This is still a valid
use case, however, doing at this level can lead to issues in the UI.

The available cellular service can temporarily disappear during normal
operation of the device. This can happen, for example, due to a change
in cellular technology. If an application requests data counters at
this time and mobile data will not be connected (because it is disabled
or due to a usable WLAN connection) then cellular usage counters will
not be sent to the application.

Always send initial cellular usage data for all known cellular services
and expect applications to only show the desired data.
Merge pull request #111 from amccarthy/master

[connman] Don't treat counters for cellular services differently.
[connman] Only wifi has hidden property. Fix crash
when wired using pre provisioned configurations.
Merge pull request #113 from lpotter/21717

[connman] Only wifi has hidden property. Fix crash
plugins: Dummy bluetooth plugin for rfkill setup

The bluetooth_legacy plugin only registers a bluetooth device when
bluetoothd has started up and indicated that an adapter is present;
and only at that time will connman set BT rfkill according to saved
settings.

This means that the intended behaviour of having connmand start before
bluetoothd and have rfkill set up before BT adapter is accessed does
not work. By implementing a dummy bluetooth driver we can initialize
bluetooth technology in connman and set rfkill to desired value
actually before bluetoothd starts up.

As a prerequisite, connmand has to wait for a HCI adapter to be present
in the system; otherwise setting up rfkill for BT won't work. This is
achieved by implementing a service that waits for an adapter to appear
outside connmand.

[connman] plugins: Dummy bluetooth plugin for rfkill setup
Fix the version on configure.ac
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 #115 from tigeli/version

[connman] Fix the version on configure.ac
Merge pull request #114 from hmallat/bt-rfkill-initialization

plugins: Dummy bluetooth plugin for rfkill setup
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
Revert "device: Make sure the device is up and running before enabling it"

This reverts commit a7a5b1698098f0cac5e244979c045b13eca67ad9.
Merge pull request #117 from hmallat/upstream-device-up-patch-revert

Revert "device: Make sure the device is up and running before enabling i...
[connman] Rever code which breaks telephony