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. [PATCH 1/2] service: Initialize order for VPN services
(Slava Monich)
2. [PATCH 2/2] service: Remove __connman_service_get_order()
(Slava Monich)
3. Re: [PATCH 0/7] ACD & valgrind cleanups (Daniel Wagner)
4. Re: [PATCH] ipconfig: Incase of Manual IP Configuration,
saving Gateway information during network switch (Daniel Wagner)
5. Re: [PATCH] plugins: ethernet: get rid of truncate warning
(Daniel Wagner)
6. Re: [PATCH] plugins: ethernet: get rid of truncate warning
(Daniel Wagner)
7. Re: [PATCH v2] plugins: ethernet: get rid of truncate warning
(Daniel Wagner)
8. Re: [PATCH] p2p: 'scan p2p' causes stop autoscan even after
scan p2p finishes (Daniel Wagner)
9. Re: [PATCH] consmetics: remove redundant returns at the end
of functions that return void (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Wed, 29 Aug 2018 17:43:10 +0300
From: Slava Monich <[email protected]>
To: [email protected]
Subject: [PATCH 1/2] service: Initialize order for VPN services
Message-ID: <[email protected]>
If the default value of do_split_routing is 0 (false) then
according to set_split_routing() the default order for VPN
services should be 10. If the whole structure is zeroed on
initialization, do_split_routing and order for VPN services
were left in inconsistent state.
---
src/service.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/service.c b/src/service.c
index 326bfa3..ea1a1ea 100644
--- a/src/service.c
+++ b/src/service.c
@@ -7350,6 +7350,7 @@ __connman_service_create_from_provider(struct
connman_provider *provider)
return NULL;
service->type = CONNMAN_SERVICE_TYPE_VPN;
+ service->order = service->do_split_routing ? 0 : 10;
service->provider = connman_provider_ref(provider);
service->autoconnect = false;
service->favorite = true;
--
1.9.1
------------------------------
Message: 2
Date: Wed, 29 Aug 2018 17:43:11 +0300
From: Slava Monich <[email protected]>
To: [email protected]
Subject: [PATCH 2/2] service: Remove __connman_service_get_order()
Message-ID: <[email protected]>
It doesn't do anything that's not done by set_split_routing()
and its return value was never used.
---
src/connman.h | 1 -
src/service.c | 30 ------------------------------
2 files changed, 31 deletions(-)
diff --git a/src/connman.h b/src/connman.h
index 34fdcb1..aeead52 100644
--- a/src/connman.h
+++ b/src/connman.h
@@ -700,7 +700,6 @@ bool __connman_service_is_connected_state(struct
connman_service *service,
const char *__connman_service_get_ident(struct connman_service *service);
const char *__connman_service_get_path(struct connman_service *service);
const char *__connman_service_get_name(struct connman_service *service);
-unsigned int __connman_service_get_order(struct connman_service *service);
enum connman_service_state __connman_service_get_state(struct connman_service
*service);
struct connman_network *__connman_service_get_network(struct connman_service
*service);
enum connman_service_security __connman_service_get_security(struct
connman_service *service);
diff --git a/src/service.c b/src/service.c
index ea1a1ea..84d849c 100644
--- a/src/service.c
+++ b/src/service.c
@@ -5265,9 +5265,6 @@ int __connman_service_set_favorite_delayed(struct
connman_service *service,
service->favorite = favorite;
- if (!delay_ordering)
- __connman_service_get_order(service);
-
favorite_changed(service);
if (!delay_ordering) {
@@ -6981,33 +6978,6 @@ enum connman_service_state
__connman_service_get_state(struct connman_service *s
return service->state;
}
-unsigned int __connman_service_get_order(struct connman_service *service)
-{
- unsigned int order = 0;
-
- if (!service)
- return 0;
-
- service->order = 0;
-
- if (!service->favorite)
- return 0;
-
- if (service == service_list->data)
- order = 1;
-
- if (service->type == CONNMAN_SERVICE_TYPE_VPN &&
- !service->do_split_routing) {
- service->order = 10;
- order = 10;
- }
-
- DBG("service %p name %s order %d split %d", service, service->name,
- order, service->do_split_routing);
-
- return order;
-}
-
static enum connman_service_type convert_network_type(struct connman_network
*network)
{
enum connman_network_type type = connman_network_get_type(network);
--
1.9.1
------------------------------
Message: 3
Date: Wed, 29 Aug 2018 20:01:30 +0200
From: Daniel Wagner <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [PATCH 0/7] ACD & valgrind cleanups
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Patchhes applied.
------------------------------
Message: 4
Date: Wed, 29 Aug 2018 20:34:15 +0200
From: Daniel Wagner <[email protected]>
To: [email protected], "[email protected]"
<[email protected]>
Cc: AMIT KUMAR JAISWAL <[email protected]>
Subject: Re: [PATCH] ipconfig: Incase of Manual IP Configuration,
saving Gateway information during network switch
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Rahul,
On 08/27/2018 11:29 AM, Rahul Jain wrote:
> Dear Daniel,
>
>
> Please find my inputs for your question:-
> [Q]Does the initial network have a proper configuration, that is it contains
> a valid gateway? If so why is it missing when we reach
> __connman_ipfconfig_save()? Do we call __connman_ipconfig_save() too late?
>
> [A] Scenario:
> 1. User configured manual IP configuration in wired network with valid
> details (IP, Gateway, DNS etc)
>>> Yes, wired network has proper configuration and connection was successful.
>
> 2. Now, user switches from wired to wireless and wireless connection
> successful.
>>> As during wired network disconnection,
>>> __connman_connection_gateway_remove() will be called with type 3 (IPv4 +
>>> IPv6), where do_ipv4 = do_ipv6 = true; -> g_hash_table_remove(gateway_hash,
>>> service); -> remove_gateway() will make gateway null.
static void remove_gateway(gpointer user_data)
{
struct gateway_data *data = user_data;
DBG("gateway ipv4 %p ipv6 %p", data->ipv4_gateway, data->ipv6_gateway);
if (data->ipv4_gateway) {
g_free(data->ipv4_gateway->gateway);
g_free(data->ipv4_gateway->vpn_ip);
g_free(data->ipv4_gateway->vpn_phy_ip);
g_free(data->ipv4_gateway);
}
if (data->ipv6_gateway) {
g_free(data->ipv6_gateway->gateway);
g_free(data->ipv6_gateway->vpn_ip);
g_free(data->ipv6_gateway->vpn_phy_ip);
g_free(data->ipv6_gateway);
}
connman_service_unref(data->service);
g_free(data);
}
remove_gateway frees the allocated resources of the type
'struct gateway_data' and not anything of 'struct connman_ipaddress', see
struct connman_ipconfig {
[...]
struct connman_ipaddress *address;
[..]
};
int __connman_ipconfig_save(struct connman_ipconfig *ipconfig,
GKeyFile *keyfile, const char *identifier, const char *prefix)
{
[...]
key = g_strdup_printf("%sgateway", prefix);
if (ipconfig->address->gateway)
g_key_file_set_string(keyfile, identifier,
key, ipconfig->address->gateway);
else
g_key_file_remove_key(keyfile, identifier, key, NULL);
[...]
}
I am confused how you get from remove_gateway() to __connman_ipconfig_save()
Maybe you could post the gdb backtrace trace like below.
(gdb) bt
#0 __connman_ipconfig_save (ipconfig=0x73a1e0, keyfile=0x70d780,
identifier=0x72b470
"wifi_7cd1c3dd9023_5468726f6174776f62626c6572204d616e67726f7665_managed_ieee8021x",
prefix=0x4ac135 "IPv4.") at src/ipconfig.c:2261
#1 0x0000000000447104 in service_save (service=0x739f10) at src/service.c:715
#2 0x000000000044d6ad in service_complete (service=0x739f10) at
src/service.c:3816
#3 0x00000000004509e0 in report_error_cb (user_context=0x739f10, retry=false,
user_data=0x0)
at src/service.c:5413
#4 0x0000000000458a89 in report_error_reply (reply=0x71fd20,
user_data=0x71c610) at src/agent.c:369
#5 0x000000000045816b in agent_finalize_pending (agent=0x71be50,
reply=0x71fd20) at src/agent.c:121
#6 0x0000000000458470 in agent_receive_message (call=0x735bc0,
user_data=0x71be50) at src/agent.c:208
#7 0x00007ffff788660a in complete_pending_call_and_unlock
(connection=0x70a600, pending=0x735bc0,
message=<optimized out>) at ../../dbus/dbus-connection.c:2332
#8 0x00007ffff7889f7f in dbus_connection_dispatch (connection=0x70a600)
at ../../dbus/dbus-connection.c:4653
#9 0x0000000000498dba in message_dispatch (data=0x70a600) at
gdbus/mainloop.c:72
#10 0x00007ffff7b0b597 in g_idle_dispatch (source=0x74e450, callback=0x498d99
<message_dispatch>,
user_data=0x70a600) at gmain.c:5486
#11 0x00007ffff7b0eb97 in g_main_dispatch (context=0x7097e0) at gmain.c:3142
#12 g_main_context_dispatch (context=context@entry=0x7097e0) at gmain.c:3795
#13 0x00007ffff7b0ef40 in g_main_context_iterate (context=0x7097e0,
block=block@entry=1,
dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3868
#14 0x00007ffff7b0f252 in g_main_loop_run (loop=0x6fe040) at gmain.c:4064
#15 0x000000000043a431 in main (argc=1, argv=0x7fffffffe418) at src/main.c:863
Anyway, I tried to get to the
g_key_file_remove_key(keyfile, identifier, key, NULL);
line with your description of the setup. In my case, the gateway was
still valid and therefore saved into config file.
> Immediately, when service_save()->__connman_ipconfig_save() is called for
> wired service,at that time, as gateway is null, so valid gateway which was
> stored already inside /var/lib/connman will be deleted.
> As per your question, yes __connman_ipconfig_save is being called after
> __connman_connection_gateway_remove().
>
>
>
> 3. Now, user switches from wireless to wired.
>>> As stored profile inside /var/lib/connman doesn't have gateway, so wired
>>> connection will fail.
>
> Please let us know your opinion.
After my short testing I can't verify your statement. Sure, I might have tested
something else but from your reasoning I can't really follow your arguments.
I think it would help if you could post the backtrace how you end up at that
place and the gateway info was already cleared
Thanks,
Daniel
------------------------------
Message: 5
Date: Wed, 29 Aug 2018 20:37:43 +0200
From: Daniel Wagner <[email protected]>
To: Marcus Folkesson <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] plugins: ethernet: get rid of truncate warning
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Marcus,
On 08/27/2018 02:32 PM, Marcus Folkesson wrote:
> The buffer will never be truncated in reality, but it is the only
> warning during compile... so get rid of it.
I suppose this is a very new gcc?
>
> The ethtool_cmd.phy_address used as dsaport is an __u8, so a `char` is
> sufficient.
>
> Use `char` as dsaport to not make snprintf nervous about truncating
> something.
>
> Warning:
> ----------------------->8-----------------------------------
>
> plugins/ethernet.c: In function ?ethernet_newlink?:
> plugins/ethernet.c:208:52: warning: ?__builtin___snprintf_chk? output may be
> truncated before the last format character [-Wformat-truncation=]
> snprintf(group, sizeof(group), "p%02x_%03x_cable", dsaport, vid);
> ^
> In file included from /usr/include/stdio.h:862,
> from plugins/ethernet.c:31:
> /usr/include/bits/stdio2.h:64:10: note: ?__builtin___snprintf_chk? output
> between 14 and 17 bytes into a destination of size 16
> return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> __bos (__s), __fmt, __va_arg_pack ());
> ----------------------->8-----------------------------------
>
> Signed-off-by: Marcus Folkesson <[email protected]>
Patch applied. I dropped the SoB because we don't do it here.
Thanks,
Daniel
------------------------------
Message: 6
Date: Wed, 29 Aug 2018 20:38:42 +0200
From: Daniel Wagner <[email protected]>
To: Marcus Folkesson <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] plugins: ethernet: get rid of truncate warning
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
> Patch applied. I dropped the SoB because we don't do it here.
Argh, just saw v2. Luckily haven't pushed yet. huuu lucky me :)
------------------------------
Message: 7
Date: Wed, 29 Aug 2018 20:39:50 +0200
From: Daniel Wagner <[email protected]>
To: Marcus Folkesson <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH v2] plugins: ethernet: get rid of truncate warning
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Marcus,
On 08/27/2018 02:49 PM, Marcus Folkesson wrote:
> The buffer will never be truncated in reality, but it is the only
> warning during compile... so get rid of it.
>
> Increase group buffer size to not make snprintf nervous about truncating
> something.
Applied this one.
Thanks,
Daniel
------------------------------
Message: 8
Date: Wed, 29 Aug 2018 20:44:38 +0200
From: Daniel Wagner <[email protected]>
To: Vasyl Vavrychuk <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] p2p: 'scan p2p' causes stop autoscan even after
scan p2p finishes
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Vasyl,
On 08/28/2018 02:04 AM, Vasyl Vavrychuk wrote:
> ---
> plugins/wifi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/plugins/wifi.c b/plugins/wifi.c
> index ef8f435..abc9b8a 100644
> --- a/plugins/wifi.c
> +++ b/plugins/wifi.c
> @@ -1784,7 +1784,7 @@ static gboolean p2p_find_stop(gpointer data)
> connman_device_set_scanning(device, CONNMAN_SERVICE_TYPE_P2P, false);
>
> connman_device_unref(device);
> - reset_autoscan(device);
> + start_autoscan(device);
>
Could add a couple of lines in the commit message explaining what is
happening and why this fixes it? I have a hard time figuring this from
the commit title. Sorry I am not so deep in the p2p stuff, so I don't
get it from the title only.
Thanks,
Daniel
------------------------------
Message: 9
Date: Wed, 29 Aug 2018 20:47:39 +0200
From: Daniel Wagner <[email protected]>
To: Vasyl Vavrychuk <[email protected]>, [email protected]
Subject: Re: [PATCH] consmetics: remove redundant returns at the end
of functions that return void
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Vasyl,
On 08/28/2018 12:03 PM, Vasyl Vavrychuk wrote:
> Another purpose of this change is making coded to have a same style.
> Previous at some functions there was redundant returns and at some no.
>
> If this returns will be in the end of all void functions it will produce
> a lot of noise while reading code.
Patch applied.
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 34, Issue 19
***************************************
