Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: [PATCH v3 1/5] session: add parameter Service into
createsession call of ConnMan session API (Daniel Wagner)
2. Re: IPv4 Address Conflict Detection support? (Daniel Wagner)
3. Re: [PATCH 0/4] Device blacklisting (Daniel Wagner)
4. Re: Iptables error with rule creation (Daniel Wagner)
5. Re: [PATCH 0/4] Device blacklisting (Patrik Flykt)
6. [PATCH 1/2] service: Set method to AUTO when address is got
through IPv4LL ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Mon, 29 May 2017 21:47:42 +0200
From: Daniel Wagner <[email protected]>
To: [email protected], [email protected]
Cc: Bjoern Thorwirth <[email protected]>,
[email protected]
Subject: Re: [PATCH v3 1/5] session: add parameter Service into
createsession call of ConnMan session API
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
After the colon we start with capital letter. The D-Bus function name is
called CreateSession and finally the Session API is more or less
consistently written with capital letter. Yes, this doesn't sound like a
big deal and I usually would fix it up myself. But there are more things
no okay in this patch.
On 05/22/2017 07:12 AM, [email protected] wrote:
> From: Bjoern Thorwirth <[email protected]>
>
> Extend the session API interface. enable a service differentiation
> for processes run by the same user. allow ConnMan to differentiate between
> bearer
> usage permissions and the respective priorities based on the requested
> service type.
>
> Usually calling process that implements the session API is identified by the
> user ID
> as it is runs. All processes of the same user share the same list of allowed
> bearers,
> and the same priority for choosing between available bearers is applied.
>
> This extension allows processes to select a service context
> for which the routing decision is made.
This commit message should explain why this change is necessary at the
first thing. I would make the second paragraph as the first one.
Since this is an official D-Bus API I want to have proper written commit
message for this. Please take the time to write one.
> ---
> doc/session-api.txt | 11 +++++++++++
> include/session.h | 1 +
> src/session.c | 17 +++++++++++++++++
> 3 files changed, 29 insertions(+)
>
> diff --git a/doc/session-api.txt b/doc/session-api.txt
> index e8da522..a449af2 100644
> --- a/doc/session-api.txt
> +++ b/doc/session-api.txt
> @@ -205,3 +205,14 @@ Settings string State [readonly]
> a default route. When the source IP rule is enabled,
> an application can select which session/interface to
> send traffic on, using bind-before-connect mechanism.
> +
> + string Service [readonly]
readonly? According the code you can write it too.
> +
> + The service context of the Session.
What does that mean?
> + Usually calling process that implements the session API
> is identified
> + by the user ID as it is runs. All processes of the same
> user share the same list of
> + allowed bearers, and the same priority for choosing
> between available
> + bearers is applied.
> + This parameter can be used to implement service context
> dependent behavior
> + In session_policy_local.c. It should be supplied with
> the ?dict Settings? parameter
> + supplied with CreateSession() call from within the
> manager-api.
The line are too long. Check the formatting of the whole document.
Also take a closer look how the documentation is written on the rest.
There should also no reference to session_policy.c. You don't have to
explain in detail what is for, e.g listing a example. You should more
details in the session-overview.txt document.
> diff --git a/include/session.h b/include/session.h
> index 5106e88..3b3c53f 100644
> --- a/include/session.h
> +++ b/include/session.h
> @@ -74,6 +74,7 @@ struct connman_session_config {
> GSList *allowed_bearers;
> char *allowed_interface;
> bool source_ip_rule;
> + char *service;
> };
>
> typedef int (* connman_session_config_func_t) (struct connman_session
> *session,
> diff --git a/src/session.c b/src/session.c
> index 9dd183f..2437538 100644
> --- a/src/session.c
> +++ b/src/session.c
> @@ -548,6 +548,7 @@ struct creation_data {
> GSList *allowed_bearers;
> char *allowed_interface;
> bool source_ip_rule;
> + char *service;
> };
>
> static void cleanup_creation_data(struct creation_data *creation_data)
> @@ -557,6 +558,8 @@ static void cleanup_creation_data(struct creation_data
> *creation_data)
>
> if (creation_data->pending)
> dbus_message_unref(creation_data->pending);
> + if (creation_data->service)
> + g_free(creation_data->service);
>
> g_slist_free(creation_data->allowed_bearers);
> g_free(creation_data->allowed_interface);
> @@ -927,6 +930,17 @@ static void append_notify(DBusMessageIter *dict,
> }
>
> if (session->append_all ||
> + info->config.service != info_last->config.service) {
> + char *ifname = info->config.service;
> + if (!ifname)
> + ifname = "";
> + connman_dbus_dict_append_basic(dict, "Service",
> + DBUS_TYPE_STRING,
> + &ifname);
> + info_last->config.service = info->config.service;
> + }
> +
> + if (session->append_all ||
> info->config.source_ip_rule !=
> info_last->config.source_ip_rule) {
> dbus_bool_t source_ip_rule = FALSE;
> if (info->config.source_ip_rule)
> @@ -1474,6 +1488,9 @@ int __connman_session_create(DBusMessage *msg)
>
> connman_session_parse_connection_type(val);
>
> user_connection_type = true;
> + } else if (g_str_equal(key, "Service")) {
> + dbus_message_iter_get_basic(&value, &val);
> + creation_data->service = g_strdup(val);
> } else if (g_str_equal(key, "AllowedInterface")) {
> dbus_message_iter_get_basic(&value, &val);
> creation_data->allowed_interface =
> g_strdup(val);
There is also the connmanctl client, which needs attention.
And then there is also some sort of encoding problem, because git am
complains with:
error: cannot convert from Y to UTF-8
fatal: could not parse patch
A good trick is to send yourself the patch first and then try to apply
it with git am. If that doesn't work don't send it.
Thanks,
Daniel
------------------------------
Message: 2
Date: Mon, 29 May 2017 21:55:56 +0200
From: Daniel Wagner <[email protected]>
To: Dave Berg <[email protected]>, [email protected]
Subject: Re: IPv4 Address Conflict Detection support?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Dave,
On 05/24/2017 12:40 AM, Dave Berg wrote:
> Hello,
>
> Does ConnMan support any type of IPv4 address conflict detection? I searched
> the code, but wasn't able to find anything obvious. I need this functionality
> for DHCP and manual configuration methods.
IIRC, we don't have such code in place. We do it for link local
addresses but not for DHCP.
> RFC5227 (https://tools.ietf.org/html/rfc5227) describes a sequence where a
> client should probe an address with ARP, and not use the address if it's
> already in use on the network.
That make certainly sense.
> Apparently udhcpc (https://busybox.net/downloads/BusyBox.html) supports this
> functionality through its command line option --arping.
Good for udhcpc. Though ConnMan doesn't make use of udhcpc.
Thanks,
Daniel
------------------------------
Message: 3
Date: Mon, 29 May 2017 22:01:56 +0200
From: Daniel Wagner <[email protected]>
To: Patrik Flykt <[email protected]>, [email protected]
Subject: Re: [PATCH 0/4] Device blacklisting
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Patrik,
On 05/26/2017 12:14 PM, Patrik Flykt wrote:
>
> Hi,
>
> Blacklisting does not work when devices change their interface name,
> but this patch set attempts to fix that. With the following changes
> blacklisting the first interface name should make ConnMan aware of
> the interface when it is renamed and vice versa.
>
> In patch 1/4 the functionality provided by detect.c is merged with
> device.c. The code in detect.c does nothing else, so this simplifies
> dependencies between the files.
>
> Patch 2/4 removes the additional blacklisting done by rtnl.c. This
> additional check will set the device type to unknown, but after that
> the device may get its device and service types set to correct values
> again. This is confusing and will confuse blacklisting later on.
>
> Patch 3/4 adds interface names to newlink and dellink callbacks. As
> the only callbacks are registered for device.c during initialization
> time, it does not matter that trigger_rtnl passes NULL as interface
> name as there will not be any ipdevices at that time.
>
> Patch 4/4 moves the interface blacklist checking to the RTNL newlink
> callback as this callback is the only function in ConnMan that uses
> connman_device_create_from_index where the check was located previously.
> With this the new name of the interface can be checked and the device
> unregistered should the blacklisting entry be only for the renamed
> device name.
>
> As this is a bit difficult to test, I hope to have somebody running
> this during their builds. But if someone feels like it, please test.
The series looks pretty good to me. It easy to follow and makes sense.
Maybe you should decided either to writing rtnl or RTNL everywhere. Just
nitpicking :)
> The code in device.c should see a make-over, it's a bit clunky as it
> is right now. It would be especially useful to colled all interface
> index to interface name mapping into device.c to get rid of an extra
> ioctl where ConnMan code currently maps index numbers to interface
> name strings and/or back. This requires all plugins to submit
> such information and the best approach here probably is to create a
> new function that creates and registers a device into ConnMan's data
> structures. But that's another patch set.
Yep, that is a good plan. Maybe adding to the TODO if you don't have
time to work on it right now?
Thanks,
Daniel
------------------------------
Message: 4
Date: Mon, 29 May 2017 22:10:33 +0200
From: Daniel Wagner <[email protected]>
To: Jeff Gray <[email protected]>, [email protected]
Subject: Re: Iptables error with rule creation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Jeff,
On 05/29/2017 04:17 AM, Jeff Gray wrote:
> I am a new user of connman. The project is an older embedded system that
> is being updated to use it.
>
> Atmel AT91-RM9200 CPU
>
> Linux-2.6.33-7 - older kernel which I can't upgrade due to binary
> drivers. But I can recompile with new modules if needed. I have built
> almost everything in the netfilter area as modules after reading several
> online guides.
Old is for sure not the right term, it is from a different millennium! :)
> buildroot-2017-02 used to build system, so everything is pretty modern
> apart from the kernel.
>
> iptables-1.6.1
>
> connman-1.34
>
>
> Ethernet is working well. I am adding a USB gadget with tethering to
> allow the device to be connected to Windows PCs as a USB device. This
> requires the DHCP server in connman to be run. usb0 is recognized as a
> gadget by connman. Tethering is initiated by sending:
>
> connmanctl tether gadget on
>
>
> After running my tethering command, lsmod shows:
>
> iptable_filter 1184 1
>
> iptable_nat 3573 0
>
> nf_nat 15825 1 iptable_nat
>
> nf_conntrack_ipv4 11680 3 iptable_nat,nf_nat
>
> nf_conntrack 52431 3 iptable_nat,nf_nat,nf_conntrack_ipv4
>
> nf_defrag_ipv4 857 1 nf_conntrack_ipv4
>
> ip_tables 8885 2 iptable_filter,iptable_nat
>
> x_tables 10528 2 iptable_nat,ip_tables
>
> bridge 45118 0
>
> stp 1318 1 bridge
>
> llc 3094 2 bridge,stp
>
> ipv6 221360 12
>
> ohci_hcd 25436 0
>
> cfg80211 116559 0
>
> rfkill 13468 2 cfg80211
>
> g_ether 42777 0
>
> usbcore 151944 2 ohci_hcd
>
>
> Running connmand with --debug=src/iptables.c,src/firewall-iptables.c:
> Bridge firewalling registered
> connmand[336]: Failed to bind UDP listener socket
> connmand[336]: Failed to bind TCP listener socket
> connmand[336]: DHCP server: option_code 1 option_value 255.255.255.0
> connmand[336]: DHCP server: option_code 3 option_value 192.168.0.1
> connmand[336]: DHCP server: option_code 6 option_value 192.168.0.1
> connmand[336]: src/firewall-iptables.c:enable_rule() nat POSTROUTING -s
> 192.168.0.2/24 <http://192.168.0.2/24> -o eth0 -j MASQUERADE
> connmand[336]: src/iptables.c:__connman_iptables_new_chain() -t nat -N
> connman-POSTROUTING
> connmand[336]: src/iptables.c:iptables_init() nat
> ip_tables: (C) 2000-2006 Netfilter Core Team
> nf_conntrack version 0.5.0 (464 buckets, 1856 max)
> CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
> nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or
> sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
> connmand[336]: src/iptables.c:iptables_add_chain() table nat chain
> connman-POSTROUTING
> connmand[336]: src/iptables.c:__connman_iptables_insert() -t nat -I
> POSTROUTING -j connman-POSTROUTING
> connmand[336]: src/iptables.c:iptables_insert_rule() table nat chain
> POSTROUTING
> connmand[336]: src/iptables.c:__connman_iptables_delete_chain() -t nat
> -X connman-POSTROUTING
> connmand[336]: src/iptables.c:iptables_delete_chain() table nat chain
> connman-POSTROUTING
> connmand[336]: Cannot enable NAT -22/Invalid argument
> connmand[336]: Add interface to bridge error No such device
>
> Debugging further I've found that find_chain_head is getting
> a target->data value of "ERROR", so it returns null.
> iptables_insert_rule detects this, so it returns -EINVAL.
>
> I inserted a system() call to dump iptables just before the error & I
> can see that nothing has been defined other than
> defaults. connman-POSTROUTING does not exist (but I'm not sure if it's
> supposed to at this stage).
>
> connmand appears to be working well in other regards. I can run many
> commands & get good results. iptables is also working fine - I can add
> NAT chains & rules without error.
>
> At this stage I'm a bit lost as to where to look. Is it a problem with
> my kernel/modules not being set up properly or in connman config?
The iptables code in ConnMan is known to be not 100% correct on how it
creates the iptables. It seems to okay for modern kernels but that is
just luck. One way around this problem could be to replace the ConnMan
code which creates the iptables with calling iptables shell command.
Obviously there would be some forks involved but that would be the
simplest solution in your situation I suppose. I wouldn't recommend to
spend time figuring out what ConnMan is doing and what the kernel
expects. I spend far too many hours myself on this topic. That's why I
recommend to use the nftable implementation usally but that is probably
not going to fly with 2.6.
HTH,
Daniel
------------------------------
Message: 5
Date: Tue, 30 May 2017 10:08:31 +0300
From: Patrik Flykt <[email protected]>
To: Daniel Wagner <[email protected]>, [email protected]
Subject: Re: [PATCH 0/4] Device blacklisting
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Mon, 2017-05-29 at 22:01 +0200, Daniel Wagner wrote:
> Hi Patrik,
>
> On 05/26/2017 12:14 PM, Patrik Flykt wrote:
> >
> > Hi,
> >
> > Blacklisting does not work when devices change their interface
> > name,
> > but this patch set attempts to fix that. With the following changes
> > blacklisting the first interface name should make ConnMan aware of
> > the interface when it is renamed and vice versa.
> >
> > In patch 1/4 the functionality provided by detect.c is merged with
> > device.c. The code in detect.c does nothing else, so this
> > simplifies
> > dependencies between the files.
> >
> > Patch 2/4 removes the additional blacklisting done by rtnl.c. This
> > additional check will set the device type to unknown, but after
> > that
> > the device may get its device and service types set to correct
> > values
> > again. This is confusing and will confuse blacklisting later on.
> >
> > Patch 3/4 adds interface names to newlink and dellink callbacks. As
> > the only callbacks are registered for device.c during
> > initialization
> > time, it does not matter that trigger_rtnl passes NULL as interface
> > name as there will not be any ipdevices at that time.
> >
> > Patch 4/4 moves the interface blacklist checking to the RTNL
> > newlink
> > callback as this callback is the only function in ConnMan that uses
> > connman_device_create_from_index where the check was located
> > previously.
> > With this the new name of the interface can be checked and the
> > device
> > unregistered should the blacklisting entry be only for the renamed
> > device name.
> >
> > As this is a bit difficult to test, I hope to have somebody running
> > this during their builds. But if someone feels like it, please
> > test.
>
> The series looks pretty good to me. It easy to follow and makes
> sense.
>
> Maybe you should decided either to writing rtnl or RTNL everywhere.
> Just?nitpicking :)
Yes, I'll fix... :-)
> > The code in device.c should see a make-over, it's a bit clunky as
> > it
> > is right now. It would be especially useful to colled all interface
> > index to interface name mapping into device.c to get rid of an
> > extra
> > ioctl where ConnMan code currently maps index numbers to interface
> > name strings and/or back. This requires all plugins to submit
> > such information and the best approach here probably is to create a
> > new function that creates and registers a device into ConnMan's
> > data
> > structures. But that's another patch set.
>
> Yep, that is a good plan. Maybe adding to the TODO if you don't have?
> time to work on it right now?
Let's see. I have at least one low hanging fruit done, but it might be
better to update the existing TODO entry. trigger_rtnl() is now limping
along in patch 3/4, as it does not know the interface name, so that is
to be fixed.
I have a person/project that should verify this all works properly, but
more blacklist testing both ways would be nice...
Cheers,
Patrik
------------------------------
Message: 6
Date: Tue, 30 May 2017 10:14:12 +0000
From: [email protected]
To: [email protected]
Subject: [PATCH 1/2] service: Set method to AUTO when address is got
through IPv4LL
Message-ID:
<1496139253-13988-1-git-send-email-jose.blanquicet-melen...@magnetimarelli.com>
From: Jose Blanquicet <[email protected]>
When DHCP fails and ConnMan obtains an address through IPv4LL, the method
stored/notified for that service must be "auto" instead of "dhcp" as has
been done so far. This patch aims to fix that misleading.
However, after a disconnection from a service with "auto" as IPv4 method,
ConnMan should use DHCP by first when user tries to reconnects or
auto-connect starts on that service. Same reasoning applies after a
power-cycle, i.e. when ConnMan starts up and reads "auto" as method from
the settings file, it should also use DHCP by first and only if it fails
then IPv4LL should be used.
The IPv4.Configuration is also set to "auto" in order to allow user to ask
ConnMan to try to get an address through DHCP at any time by manually
setting this property to "dhcp". On the other hand, "auto" cannot be set
by users from D-Bus API, as it has been so far.
---
src/connman.h | 2 ++
src/dhcp.c | 37 ++++++++++++++++++++++++++++++++++++-
src/ipconfig.c | 18 ++++++++++++++----
src/network.c | 13 ++++++++++++-
src/service.c | 9 +++++++++
5 files changed, 73 insertions(+), 6 deletions(-)
diff --git a/src/connman.h b/src/connman.h
index ce4d82e..21b7080 100644
--- a/src/connman.h
+++ b/src/connman.h
@@ -680,6 +680,8 @@ struct connman_ipconfig *__connman_service_get_ip6config(
struct connman_service *service);
struct connman_ipconfig *__connman_service_get_ipconfig(
struct connman_service *service, int family);
+void __connman_service_notify_ipv4_configuration(
+ struct connman_service *service);
bool __connman_service_is_connected_state(struct connman_service *service,
enum connman_ipconfig_type type);
const char *__connman_service_get_ident(struct connman_service *service);
diff --git a/src/dhcp.c b/src/dhcp.c
index 54fb64e..e797ae1 100644
--- a/src/dhcp.c
+++ b/src/dhcp.c
@@ -435,6 +435,7 @@ static void lease_available_cb(GDHCPClient *dhcp_client,
gpointer user_data)
{
struct connman_dhcp *dhcp = user_data;
GList *option = NULL;
+ enum connman_ipconfig_method old_method;
char *address, *netmask = NULL, *gateway = NULL;
const char *c_address, *c_gateway;
unsigned char prefixlen, c_prefixlen;
@@ -486,8 +487,24 @@ static void lease_available_cb(GDHCPClient *dhcp_client,
gpointer user_data)
} else if (prefixlen != c_prefixlen)
ip_change = true;
+ old_method = __connman_ipconfig_get_method(dhcp->ipconfig);
__connman_ipconfig_set_method(dhcp->ipconfig,
CONNMAN_IPCONFIG_METHOD_DHCP);
+
+ /*
+ * Notify IPv4.Configuration's method moved back to DHCP.
+ *
+ * This is the case ConnMan initially set an address by using
+ * IPv4LL because DHCP failed but now we got an address from DHCP.
+ */
+ if (old_method == CONNMAN_IPCONFIG_METHOD_AUTO) {
+ struct connman_service *service =
+ connman_service_lookup_from_network(dhcp->network);
+
+ if (service)
+ __connman_service_notify_ipv4_configuration(service);
+ }
+
if (ip_change) {
__connman_ipconfig_set_local(dhcp->ipconfig, address);
__connman_ipconfig_set_prefixlen(dhcp->ipconfig, prefixlen);
@@ -509,6 +526,7 @@ done:
static void ipv4ll_available_cb(GDHCPClient *ipv4ll_client, gpointer user_data)
{
struct connman_dhcp *dhcp = user_data;
+ enum connman_ipconfig_method old_method;
char *address, *netmask;
unsigned char prefixlen;
@@ -519,8 +537,25 @@ static void ipv4ll_available_cb(GDHCPClient
*ipv4ll_client, gpointer user_data)
prefixlen = connman_ipaddress_calc_netmask_len(netmask);
+ old_method = __connman_ipconfig_get_method(dhcp->ipconfig);
__connman_ipconfig_set_method(dhcp->ipconfig,
- CONNMAN_IPCONFIG_METHOD_DHCP);
+ CONNMAN_IPCONFIG_METHOD_AUTO);
+
+ /*
+ * Notify IPv4.Configuration's method is AUTO now.
+ *
+ * This is the case DHCP failed thus ConnMan used IPv4LL to get an
+ * address. Set IPv4.Configuration method to AUTO allows user to
+ * ask for a DHCP address by setting the method again to DHCP.
+ */
+ if (old_method == CONNMAN_IPCONFIG_METHOD_DHCP) {
+ struct connman_service *service =
+ connman_service_lookup_from_network(dhcp->network);
+
+ if (service)
+ __connman_service_notify_ipv4_configuration(service);
+ }
+
__connman_ipconfig_set_local(dhcp->ipconfig, address);
__connman_ipconfig_set_prefixlen(dhcp->ipconfig, prefixlen);
__connman_ipconfig_set_gateway(dhcp->ipconfig, NULL);
diff --git a/src/ipconfig.c b/src/ipconfig.c
index bae988c..272925a 100644
--- a/src/ipconfig.c
+++ b/src/ipconfig.c
@@ -1762,13 +1762,13 @@ void __connman_ipconfig_append_ipv4(struct
connman_ipconfig *ipconfig,
switch (ipconfig->method) {
case CONNMAN_IPCONFIG_METHOD_UNKNOWN:
case CONNMAN_IPCONFIG_METHOD_OFF:
- case CONNMAN_IPCONFIG_METHOD_AUTO:
return;
case CONNMAN_IPCONFIG_METHOD_FIXED:
append_addr = ipconfig->address;
break;
+ case CONNMAN_IPCONFIG_METHOD_AUTO:
case CONNMAN_IPCONFIG_METHOD_MANUAL:
case CONNMAN_IPCONFIG_METHOD_DHCP:
append_addr = ipconfig->system;
@@ -2222,6 +2222,19 @@ int __connman_ipconfig_load(struct connman_ipconfig
*ipconfig,
g_free(key);
break;
+ case CONNMAN_IPCONFIG_METHOD_AUTO:
+
+ if (ipconfig->type != CONNMAN_IPCONFIG_TYPE_IPV4)
+ break;
+
+ /*
+ * If the last used method for IPv4 was AUTO then we
+ * try first DHCP. We will try also to use the last
+ * used DHCP address, if exits.
+ */
+ __connman_ipconfig_set_method(ipconfig,
+ CONNMAN_IPCONFIG_METHOD_DHCP);
+
case CONNMAN_IPCONFIG_METHOD_DHCP:
key = g_strdup_printf("%sDHCP.LastAddress", prefix);
@@ -2233,9 +2246,6 @@ int __connman_ipconfig_load(struct connman_ipconfig
*ipconfig,
g_free(key);
break;
-
- case CONNMAN_IPCONFIG_METHOD_AUTO:
- break;
}
return 0;
diff --git a/src/network.c b/src/network.c
index 5b7ef55..a5b7d78 100644
--- a/src/network.c
+++ b/src/network.c
@@ -172,6 +172,8 @@ static void dhcp_success(struct connman_network *network)
if (err < 0)
goto err;
+ __connman_service_save(service);
+
return;
err:
@@ -647,10 +649,19 @@ static void set_disconnected(struct connman_network
*network)
switch (ipv4_method) {
case CONNMAN_IPCONFIG_METHOD_UNKNOWN:
case CONNMAN_IPCONFIG_METHOD_OFF:
- case CONNMAN_IPCONFIG_METHOD_AUTO:
case CONNMAN_IPCONFIG_METHOD_FIXED:
case CONNMAN_IPCONFIG_METHOD_MANUAL:
break;
+ case CONNMAN_IPCONFIG_METHOD_AUTO:
+ /*
+ * If the current method is AUTO then next time we
+ * try first DHCP. DHCP also needs to be stopped
+ * in this case because if we fell in AUTO means
+ * that DHCP was launched for IPv4 but it failed.
+ */
+ __connman_ipconfig_set_method(ipconfig_ipv4,
+ CONNMAN_IPCONFIG_METHOD_DHCP);
+ __connman_service_notify_ipv4_configuration(service);
case CONNMAN_IPCONFIG_METHOD_DHCP:
__connman_dhcp_stop(ipconfig_ipv4);
break;
diff --git a/src/service.c b/src/service.c
index d9c1907..73832f8 100644
--- a/src/service.c
+++ b/src/service.c
@@ -1988,6 +1988,15 @@ static void ipv4_configuration_changed(struct
connman_service *service)
service);
}
+void __connman_service_notify_ipv4_configuration(
+ struct connman_service *service)
+{
+ if (!service)
+ return;
+
+ ipv4_configuration_changed(service);
+}
+
static void ipv6_configuration_changed(struct connman_service *service)
{
if (!allow_property_changed(service))
--
1.9.1
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 19, Issue 16
***************************************
