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] firewall-nftables: fix some typos in comments
(Daniel Wagner)
2. Re: dhcp-server-test and dhcp-test demoes error (Daniel Wagner)
3. [PATCH] gdhcp: Fix wrong initialization of listener_watch
(Daniel Wagner)
4. Re: Problem when creating a connman-vpn provider with dbus
net.connman.vpn.Manager.Create (Daniel Wagner)
5. Re: [PATCH] vpn: Handle stale task completions (Daniel Wagner)
6. Re: scan starts automatically on device enable even if
BackgroundScanning=false (Daniel Wagner)
7. Re: scan starts automatically on device enable even if
BackgroundScanning=false (Vasyl Vavrychuk)
8. Re: scan starts automatically on device enable even if
BackgroundScanning=false (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Mon, 16 Apr 2018 21:02:42 +0200
From: Daniel Wagner <[email protected]>
To: Andr? Draszik <[email protected]>, [email protected]
Subject: Re: [PATCH] firewall-nftables: fix some typos in comments
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Andr?,
On 04/11/2018 02:04 PM, Andr? Draszik wrote:
> From: Andr? Draszik <[email protected]>
Patch applied.
Thanks,
Daniel
------------------------------
Message: 2
Date: Mon, 16 Apr 2018 21:45:45 +0200
From: Daniel Wagner <[email protected]>
To: "[email protected]" <[email protected]>
Cc: connman <[email protected]>
Subject: Re: dhcp-server-test and dhcp-test demoes error
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi,
On 03/27/2018 05:03 AM, [email protected] wrote:
>
> Dear?Daniel,
> i?am?now?studying?the?source?code?of?connman?and?learn?some
> test?demoes?about?"dhcp-server-test/dhcp-test"?in?the?directory?of?tools.
I am not sure if all of those tools actually work correctly. They are usually
some sort of prototypes for features we were working on. So it might be
that they don't do what you expect or only work partially.
> firstly,?type?"ip?link"?i?get:
>
> 1:?lo:?<LOOPBACK,UP,LOWER_UP>?mtu?65536?qdisc?noqueue?state?UNKNOWN?mode?DEFAULT?group?default?qlen?1000
> ????link/loopback?00:00:00:00:00:00?brd?00:00:00:00:00:00
> 2:?enp4s0f2:?<BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP>?mtu?1500?qdisc?pfifo_fast?state?UP?mode?DEFAULT?group?default?qlen?1000
> ????link/ether?40:16:7e:44:76:e5?brd?ff:ff:ff:ff:ff:ff
> 3:?wlp3s0:?<NO-CARRIER,BROADCAST,MULTICAST,DYNAMIC,UP>?mtu?1500?qdisc?mq?state?DOWN?mode?DORMANT?group?default?qlen?1000
> ????link/ether?54:35:30:27:99:ff?brd?ff:ff:ff:ff:ff:ff
> 5:?vmnet1:?<BROADCAST,MULTICAST,UP,LOWER_UP>?mtu?1500?qdisc?pfifo_fast?state?UNKNOWN?mode?DEFAULT?group?default?qlen?1000
> ????link/ether?00:50:56:c0:00:01?brd?ff:ff:ff:ff:ff:ff
> 6:?vmnet8:?<BROADCAST,MULTICAST,UP,LOWER_UP>?mtu?1500?qdisc?pfifo_fast?state?UNKNOWN?mode?DEFAULT?group?default?qlen?1000
> ????link/ether?00:50:56:c0:00:08?brd?ff:ff:ff:ff:ff:ff
> 7:?wlx7cdd90caf78b:?<NO-CARRIER,BROADCAST,MULTICAST,DYNAMIC,UP>?mtu?1500?qdisc?mq?state?DOWN?mode?DORMANT?group?default?qlen?1000
> ????link/ether?7c:dd:90:ca:f7:8b?brd?ff:ff:ff:ff:ff:ff
>
> then,
> test@ubuntu:/connman/tools$?./dhcp-server-test?2
> Create?DHCP?server?for?interface?2
> DHCP:?option_code?1?option_value?255.255.0.0
> DHCP:?option_code?3?option_value?192.168.0.2
> DHCP:?option_code?6?option_value?192.168.0.3
> Start?DHCP?Server?operation
You propably need to setup the interface to 192.168.0.3 to get the DHCP
server correctly.
> and?,open another terminal,
> test@ubuntu:/connman/tools$?./dhcp-test?2
> Create?DHCP?client?for?interface?2
> Start?DHCP?operation
You this tool needs to run on the other end of the interface. If you want to
play
with these tools, I suppose using a tun/tap device is better.
>
> and,?my?ifconfig?info?are:
> enp4s0f2??Link?encap:Ethernet??HWaddr?40:16:7e:44:76:e5
> ??????????inet?addr:192.168.1.100??Bcast:192.168.1.255??Mask:255.255.255.0
> ??????????inet6?addr:?fe80::4216:7eff:fe44:76e5/64?Scope:Link
> ??????????UP?BROADCAST?RUNNING?MULTICAST?DYNAMIC??MTU:1500??Metric:1
> ??????????RX?packets:296?errors:0?dropped:0?overruns:0?frame:0
> ??????????TX?packets:806?errors:0?dropped:0?overruns:0?carrier:0
> ??????????collisions:0?txqueuelen:1000
> ??????????RX?bytes:106874?(106.8?KB)??TX?bytes:127989?(127.9?KB)
>
> lo????????Link?encap:Local?Loopback
> ??????????inet?addr:127.0.0.1??Mask:255.0.0.0
> ??????????inet6?addr:?::1/128?Scope:Host
> ??????????UP?LOOPBACK?RUNNING??MTU:65536??Metric:1
> ??????????RX?packets:260701?errors:0?dropped:0?overruns:0?frame:0
> ??????????TX?packets:260701?errors:0?dropped:0?overruns:0?carrier:0
> ??????????collisions:0?txqueuelen:1000
> ??????????RX?bytes:24663612?(24.6?MB)??TX?bytes:24663612?(24.6?MB)
>
> vmnet1????Link?encap:Ethernet??HWaddr?00:50:56:c0:00:01
> ??????????inet?addr:192.168.2.1??Bcast:192.168.2.255??Mask:255.255.255.0
> ??????????inet6?addr:?fe80::250:56ff:fec0:1/64?Scope:Link
> ??????????UP?BROADCAST?RUNNING?MULTICAST??MTU:1500??Metric:1
> ??????????RX?packets:0?errors:0?dropped:0?overruns:0?frame:0
> ??????????TX?packets:130?errors:0?dropped:0?overruns:0?carrier:0
> ??????????collisions:0?txqueuelen:1000
> ??????????RX?bytes:0?(0.0?B)??TX?bytes:0?(0.0?B)
>
> vmnet8????Link?encap:Ethernet??HWaddr?00:50:56:c0:00:08
> ??????????inet?addr:172.16.194.1??Bcast:172.16.194.255??Mask:255.255.255.0
> ??????????inet6?addr:?fe80::250:56ff:fec0:8/64?Scope:Link
> ??????????UP?BROADCAST?RUNNING?MULTICAST??MTU:1500??Metric:1
> ??????????RX?packets:0?errors:0?dropped:0?overruns:0?frame:0
> ??????????TX?packets:129?errors:0?dropped:0?overruns:0?carrier:0
> ??????????collisions:0?txqueuelen:1000
> ??????????RX?bytes:0?(0.0?B)??TX?bytes:0?(0.0?B)
>
> wlp3s0????Link?encap:Ethernet??HWaddr?54:35:30:27:99:ff
> ??????????UP?BROADCAST?MULTICAST?DYNAMIC??MTU:1500??Metric:1
> ??????????RX?packets:0?errors:0?dropped:0?overruns:0?frame:0
> ??????????TX?packets:0?errors:0?dropped:0?overruns:0?carrier:0
> ??????????collisions:0?txqueuelen:1000
> ??????????RX?bytes:0?(0.0?B)??TX?bytes:0?(0.0?B)
>
> wlx7cdd90caf78b?Link?encap:Ethernet??HWaddr?7c:dd:90:ca:f7:8b
> ??????????UP?BROADCAST?MULTICAST?DYNAMIC??MTU:1500??Metric:1
> ??????????RX?packets:0?errors:0?dropped:0?overruns:0?frame:0
> ??????????TX?packets:0?errors:0?dropped:0?overruns:0?carrier:0
> ??????????collisions:0?txqueuelen:1000
> ??????????RX?bytes:0?(0.0?B)??TX?bytes:0?(0.0?B)
>
> i?think?if?the?demoes?is?right,?my?ip?address?of?enp4s0f2?will?be?changed,
> so?what?wrong?about?that??is?that?connmand?MUST?be?run?
I don't think so. The really need to ends of an ethernet connection to
get these two tools working. It will not work if you use it
on the same interface.
Something along this here:
# ip link add name br0 type bridge
# ip link set bridge_name up
# ip tuntap add tap0 mode tap
# ip tuntap add tap1 mode tap
# ip link set tap0 master br0
# ip link set tap1 master br0
# ip addr add 192.168.0.3/24 dev tap0
...
5
Probably not all correct but you get the idea
> and?i?interrupt?the?process?of?dhcp-server-test,?and?get?the
> error?"(process:8715):?GLib-CRITICAL?**:?Source?ID?4294967295?was?not?found?when?attempting?to?remove?it
> "??how?to?avoid?this?problem?
This indicates a bug in the dhcp-server-test program. We try to
cleanup a resource which is already gone.
(gdb) signal SIGTERM
Continuing with signal SIGTERM.
Breakpoint 2, g_log (log_domain=log_domain@entry=0x7ffff7b56fae "GLib",
log_level=log_level@entry=G_LOG_LEVEL_CRITICAL,
format=format@entry=0x7ffff7b5e808 "Source ID %u was not found when
attempting to remove it")
at gmessages.c:1399
1399 {
(gdb) bt
#0 g_log (log_domain=log_domain@entry=0x7ffff7b56fae "GLib",
log_level=log_level@entry=G_LOG_LEVEL_CRITICAL,
format=format@entry=0x7ffff7b5e808 "Source ID %u was not found when
attempting to remove it")
at gmessages.c:1399
#1 0x00007ffff7b0d8ac in g_source_remove (tag=4294967295) at gmain.c:2351
#2 0x000000000040b1f5 in g_dhcp_server_stop (dhcp_server=0x616490) at
gdhcp/server.c:847
#3 0x000000000040b24a in g_dhcp_server_unref (dhcp_server=0x616490) at
gdhcp/server.c:864
#4 0x000000000040b869 in main (argc=2, argv=0x7fffffffdd88) at
tools/dhcp-server-test.c:118
If you look at definition of listener_watch you can see it is declared as
guint and we initialize it to -1 which is clearly wrong.
diff --git a/gdhcp/server.c b/gdhcp/server.c
index b6b58788200e..85405f193fe3 100644
--- a/gdhcp/server.c
+++ b/gdhcp/server.c
@@ -396,7 +396,7 @@ GDHCPServer *g_dhcp_server_new(GDHCPType type,
dhcp_server->ref_count = 1;
dhcp_server->ifindex = ifindex;
dhcp_server->listener_sockfd = -1;
- dhcp_server->listener_watch = -1;
+ dhcp_server->listener_watch = 0;
dhcp_server->listener_channel = NULL;
dhcp_server->save_lease_func = NULL;
dhcp_server->debug_func = NULL;
Patch in the works.
Thanks,
Daniel
------------------------------
Message: 3
Date: Mon, 16 Apr 2018 21:49:58 +0200
From: Daniel Wagner <[email protected]>
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Subject: [PATCH] gdhcp: Fix wrong initialization of listener_watch
Message-ID: <[email protected]>
listener_watch is of type unsigned integer. So initializing it
to -1 means we always try to remove the source and we get a
warning by Glib
(gdb) bt
#0 g_log (log_domain=log_domain@entry=0x7ffff7b56fae "GLib",
log_level=log_level@entry=G_LOG_LEVEL_CRITICAL,
format=format@entry=0x7ffff7b5e808 "Source ID %u was not found when
attempting to remove it")
at gmessages.c:1399
#1 0x00007ffff7b0d8ac in g_source_remove (tag=4294967295) at gmain.c:2351
#2 0x000000000040b1f5 in g_dhcp_server_stop (dhcp_server=0x616490) at
gdhcp/server.c:847
#3 0x000000000040b24a in g_dhcp_server_unref (dhcp_server=0x616490) at
gdhcp/server.c:864
#4 0x000000000040b869 in main (argc=2, argv=0x7fffffffdd88) at
tools/dhcp-server-test.c:118
---
gdhcp/server.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gdhcp/server.c b/gdhcp/server.c
index b6b58788200e..85405f193fe3 100644
--- a/gdhcp/server.c
+++ b/gdhcp/server.c
@@ -396,7 +396,7 @@ GDHCPServer *g_dhcp_server_new(GDHCPType type,
dhcp_server->ref_count = 1;
dhcp_server->ifindex = ifindex;
dhcp_server->listener_sockfd = -1;
- dhcp_server->listener_watch = -1;
+ dhcp_server->listener_watch = 0;
dhcp_server->listener_channel = NULL;
dhcp_server->save_lease_func = NULL;
dhcp_server->debug_func = NULL;
--
2.14.3
------------------------------
Message: 4
Date: Mon, 16 Apr 2018 22:06:58 +0200
From: Daniel Wagner <[email protected]>
To: Thomas Achleitner <[email protected]>,
[email protected]
Subject: Re: Problem when creating a connman-vpn provider with dbus
net.connman.vpn.Manager.Create
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Thomas,
On 04/12/2018 08:54 AM, Thomas Achleitner wrote:
> I may have found a bug when creating a vpn provider with DBus.
>
> The first time i create a connection the provider will not contain the
> vpn type specific configuration (e.g. OpenVPN.ConfigFile)
Not sure if I understand you right. What do you mean with 'vpn type'? Do
you mean the OpenVPN.DeviceType (tap or tun)? Or is OpenVPN.ConfigFile
missing?
> The configuration seems correct and the connection is set up,
> net.connman.vpn.Connection.GetProperties contains the etries
>
> ????? dict entry(
> ???????? string "OpenVPN.ConfigFile"
> ???????? variant???????????? string "/media/card/openvpn/openvpn.conf"
> ????? )
> ????? dict entry(
> ???????? string "OpenVPN.DeviceType"
> ???????? variant???????????? string "tap"
> ????? )
>
> but the providerfile looks like
>
> ??? [vpn_sspcdn_a_net_vpn_sspcdn_a_net]
> ??? ??? Name=Test VPN
> ??? ??? Type=openvpn
> ??? ??? Host=vpn.sspcdn-a.net
> ??? ??? VPN.Domain=sspcdn-a.net
The config code might be case sensitive. I would write 'OpenVPN' for the
Type just to be on the safe side...
> If i call dbus net.connman.vpn.Manager.Create a second time the
> information gets added to the provider file correctily.
>
> connman-vpnd debug output of the first call
I don't see anything obviously wrong. Though I haven't spend a lot of
time with the VPN code.
Thanks,
Daniel
------------------------------
Message: 5
Date: Mon, 16 Apr 2018 22:15:03 +0200
From: Daniel Wagner <[email protected]>
To: Slava Monich <[email protected]>, [email protected]
Subject: Re: [PATCH] vpn: Handle stale task completions
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Slava,
On 04/13/2018 05:11 PM, Slava Monich wrote:
> The task may die after we have already started the new one
Can elaborate a bit here? It is really hard to figure out what is
happening. I suppose it is a race somewhere.
Thanks,
Daniel
> ---
> vpn/plugins/vpn.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/vpn/plugins/vpn.c b/vpn/plugins/vpn.c
> index aeb01d6..10548aa 100644
> --- a/vpn/plugins/vpn.c
> +++ b/vpn/plugins/vpn.c
> @@ -133,6 +133,10 @@ void vpn_died(struct connman_task *task, int exit_code,
> void *user_data)
> if (!data)
> goto vpn_exit;
>
> + /* The task may die after we have already started the new one */
> + if (data->task != task)
> + goto done;
> +
> state = data->state;
>
> stop_vpn(provider);
> @@ -172,6 +176,7 @@ vpn_exit:
> g_free(data);
> }
>
> +done:
> connman_task_destroy(task);
> }
>
>
------------------------------
Message: 6
Date: Mon, 16 Apr 2018 22:22:08 +0200
From: Daniel Wagner <[email protected]>
To: Vasyl Vavrychuk <[email protected]>, [email protected]
Subject: Re: scan starts automatically on device enable even if
BackgroundScanning=false
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Vasyl,
On 04/13/2018 10:04 PM, Vasyl Vavrychuk wrote:
> Documentation on BackgroundScanning says
>
> When BackgroundScanning is false, ConnMan will not perform any scan
> regardless of wifi is connected or not, unless it is requested by
> the user through a D-Bus call.
>
> but code in connman_device_set_powered thinks other way. It starts
> scan after device power enable.
The BackgroundScanning variable is supposed to by honored in
plugins/wifi.c. Unfortunately, the scanning logic is not simple. I
wouldn't be surprised that there are still bugs in there. Do see scans
when BackgroundScanning is false?
Thanks,
Daniel
------------------------------
Message: 7
Date: Mon, 16 Apr 2018 23:29:37 +0300
From: Vasyl Vavrychuk <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: scan starts automatically on device enable even if
BackgroundScanning=false
Message-ID:
<CAGj4m+65E11n8ZFROS4rGBTuvW15mFNyRGJy=CxN1=opko=m...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
>> Documentation on BackgroundScanning says
>>
>> When BackgroundScanning is false, ConnMan will not perform any scan
>> regardless of wifi is connected or not, unless it is requested by
>> the user through a D-Bus call.
>>
>> but code in connman_device_set_powered thinks other way. It starts
>> scan after device power enable.
>
>
> The BackgroundScanning variable is supposed to by honored in plugins/wifi.c.
> Unfortunately, the scanning logic is not simple. I wouldn't be surprised
> that there are still bugs in there. Do see scans when BackgroundScanning is
> false?
Actually I am talking about different thing. I do not see any scan
scheduled by wifi.c plugin by itself if BackgroundScanning is false.
What I see is that connman_device_set_powered issue scan upon every
power on. Plugin can not (or should not) distinguish this scan from
user requested scans.
So this should be solved on the device.c level if we want.
I am not sure that it is a problem form user stand point. That is just
my observation.
------------------------------
Message: 8
Date: Mon, 16 Apr 2018 22:37:37 +0200
From: Daniel Wagner <[email protected]>
To: Vasyl Vavrychuk <[email protected]>
Cc: [email protected]
Subject: Re: scan starts automatically on device enable even if
BackgroundScanning=false
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 04/16/2018 10:29 PM, Vasyl Vavrychuk wrote:
>>> Documentation on BackgroundScanning says
>>>
>>> When BackgroundScanning is false, ConnMan will not perform any scan
>>> regardless of wifi is connected or not, unless it is requested by
>>> the user through a D-Bus call.
>>>
>>> but code in connman_device_set_powered thinks other way. It starts
>>> scan after device power enable.
>>
>>
>> The BackgroundScanning variable is supposed to by honored in plugins/wifi.c.
>> Unfortunately, the scanning logic is not simple. I wouldn't be surprised
>> that there are still bugs in there. Do see scans when BackgroundScanning is
>> false?
>
> Actually I am talking about different thing. I do not see any scan
> scheduled by wifi.c plugin by itself if BackgroundScanning is false.
>
> What I see is that connman_device_set_powered issue scan upon every
> power on. Plugin can not (or should not) distinguish this scan from
> user requested scans.
> So this should be solved on the device.c level if we want.
I digged into the history of this scan call. It seems to exist since the
early days. The code base as evolved quite a lot since then.
> I am not sure that it is a problem form user stand point. That is just
> my observation.
It might be that we don't need it anymore. At least the initial commit
leads to this conclusion 9b05cebe93ad ("Add support for automatic
connection policy"). Though I am a bit hesitant to remove it without
proper testing.
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 30, Issue 19
***************************************
