Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe 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 00/11] Update iwd plugin (Daniel Wagner)
2. [PATCH 0/2] Wireguard improvments (Daniel Wagner)
3. [PATCH 1/2] wireguard: Set listen port flag in device flags
(Daniel Wagner)
4. [PATCH 2/2] wireguard: Add PresharedKey feature (Daniel Wagner)
5. Re: Why connmand consume such higher CPU resource? (JH)
6. Re: Why connmand consume such higher CPU resource? (Daniel Wagner)
----------------------------------------------------------------------
Date: Fri, 17 Jan 2020 09:12:15 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH v3 00/11] Update iwd plugin
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
All patches applied.
There are still things to fix/improve but I'll do this on top of this
series.
------------------------------
Date: Fri, 17 Jan 2020 09:35:11 +0100
From: Daniel Wagner <[email protected]>
Subject: [PATCH 0/2] Wireguard improvments
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Message-ID: <[email protected]>
A few bunch of improvements for wireguard. Currently I can't test
wireguard because my setup is broken. Out of tree code is a hassle...
Daniel Wagner (2):
wireguard: Set listen port flag in device flags
wireguard: Add PresharedKey feature
doc/vpn-config-format.txt | 1 +
vpn/plugins/wireguard.c | 10 +++++++++-
2 files changed, 10 insertions(+), 1 deletion(-)
--
2.24.1
------------------------------
Date: Fri, 17 Jan 2020 09:35:12 +0100
From: Daniel Wagner <[email protected]>
Subject: [PATCH 1/2] wireguard: Set listen port flag in device flags
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Message-ID: <[email protected]>
WGDEVICE_HAS_LISTEN_PORT should be set on the info->device.flags and
not info->peer.flags.
Fixes cb2870b865ff ("wireguard: Make the ListenPort optional")
---
vpn/plugins/wireguard.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/vpn/plugins/wireguard.c b/vpn/plugins/wireguard.c
index 5ad87b43bc31..b90e158a8bfe 100644
--- a/vpn/plugins/wireguard.c
+++ b/vpn/plugins/wireguard.c
@@ -264,7 +264,7 @@ static int wg_connect(struct vpn_provider *provider,
if (option) {
char *end;
info->device.listen_port = g_ascii_strtoull(option, &end, 10);
- info->peer.flags |= WGDEVICE_HAS_LISTEN_PORT;
+ info->device.flags |= WGDEVICE_HAS_LISTEN_PORT;
}
option = vpn_provider_get_string(provider, "WireGuard.PrivateKey");
--
2.24.1
------------------------------
Date: Fri, 17 Jan 2020 09:35:13 +0100
From: Daniel Wagner <[email protected]>
Subject: [PATCH 2/2] wireguard: Add PresharedKey feature
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Message-ID: <[email protected]>
Add missing PresharedKey parsing option. Many VPN providers hand out
configurations with PSK.
Reported by Christian Hewitt
---
doc/vpn-config-format.txt | 1 +
vpn/plugins/wireguard.c | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/doc/vpn-config-format.txt b/doc/vpn-config-format.txt
index 34d4227702fc..12ac7b73c765 100644
--- a/doc/vpn-config-format.txt
+++ b/doc/vpn-config-format.txt
@@ -284,6 +284,7 @@ WireGuard VPN supports following options
WireGuard.ListPort Local listen port (optional)
WireGuard.PrivateKey Private key of interface
WireGuard.PublicKey Public key of peer
+ WireGuard.PresharedKey Preshared key of peer (optional)
WireGuard.AllowedIPs See Cryptokey Routing
WireGuard.EndpointPort Endpoint listen port (optional)
WireGuard.PersistentKeepalive Keep alive in seconds (optional)
diff --git a/vpn/plugins/wireguard.c b/vpn/plugins/wireguard.c
index b90e158a8bfe..61d259507342 100644
--- a/vpn/plugins/wireguard.c
+++ b/vpn/plugins/wireguard.c
@@ -285,6 +285,14 @@ static int wg_connect(struct vpn_provider *provider,
if (err)
goto done;
+ option = vpn_provider_get_string(provider, "WireGuard.PresharedKey");
+ if (option) {
+ info->peer.flags |= WGPEER_HAS_PRESHARED_KEY;
+ err = parse_key(option, info->peer.preshared_key);
+ if (err)
+ goto done;
+ }
+
option = vpn_provider_get_string(provider, "WireGuard.AllowedIPs");
if (!option) {
DBG("WireGuard.AllowedIPs is missing");
--
2.24.1
------------------------------
Date: Fri, 17 Jan 2020 21:14:15 +1100
From: JH <[email protected]>
Subject: Re: Why connmand consume such higher CPU resource?
To: Daniel Wagner <[email protected]>
Cc: connman <[email protected]>
Message-ID:
<CAA=hcWRuzUHkqEsH2Wo1CwAV-9=kf5saapebgssxvprg8m+...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi Daniel,
On 1/17/20, Daniel Wagner <[email protected]> wrote:
> No it's not a new feature. Local link support is in since the early days of
> ConnMan.
I have been running 1.35 for a year, we never got the local link if
the WiFi was not able to be connected.
> You get a newer kernel, you get newer libraries (glibc, glib, ...)
> and usually a slightly modified configuration caused due to the
> updated of all components. So it's a complete new system.
Not a new kernel, let me make it clear, it is the same kernel for both
1.35 and 1.37, glibc, glib more have new versions, but I don't think
the network configuration would be modified.
>> Attached log debug file set up CONNMAN_DHCP_DEBUG=1 and
>> > CONNMAN_DHCPV6_DEBUG=1.
>
> connmand[9133]: DHCP index 3: sending DHCP discover request
> connmand[9133]: DHCP index 3: sending DHCP discover request
> connmand[9133]: DHCP index 3: sending DHCP discover request
> connmand[9133]: DHCP index 3: sending DHCP discover request
> connmand[9133]: DHCP index 3: sending DHCP discover request
>
> As you can see ConnMan is sending the DHCP requests but never sees a
> DHCP respond frame. The Linux networking stack usually works fine, so
> should at what the networking driver is doing.
So that was the problem, that no DHCP response caused failure of WiFi
IP address, right? I'll do an investigation and debug to check why
there was no DHCP response.
Another question, does connman manage DHCP lease time? How can I
configure DHCP lease time for much longer?
Thank you.
Kind regards,
- jh
------------------------------
Date: Fri, 17 Jan 2020 11:27:54 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: Why connmand consume such higher CPU resource?
To: JH <[email protected]>
Cc: connman <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Fri, Jan 17, 2020 at 09:14:15PM +1100, JH wrote:
> On 1/17/20, Daniel Wagner <[email protected]> wrote:
> > No it's not a new feature. Local link support is in since the early days of
> > ConnMan.
> I have been running 1.35 for a year, we never got the local link if
> the WiFi was not able to be connected.
If ConnMan doesn't get an DHCP lease it always does IPv4LL when the
interface is up and running. Maybe you disconnected before the IPv4LL
state machine was triggered.
> > You get a newer kernel, you get newer libraries (glibc, glib, ...)
> > and usually a slightly modified configuration caused due to the
> > updated of all components. So it's a complete new system.
>
> Not a new kernel, let me make it clear, it is the same kernel for both
> 1.35 and 1.37, glibc, glib more have new versions, but I don't think
> the network configuration would be modified.
I don't think the libraries are the source of the problem. There is a
change in the kernel/driver behavoir as I read the logs. Maybe new
firmware?
> > As you can see ConnMan is sending the DHCP requests but never sees a
> > DHCP respond frame. The Linux networking stack usually works fine, so
> > should at what the networking driver is doing.
>
> So that was the problem, that no DHCP response caused failure of WiFi
> IP address, right? I'll do an investigation and debug to check why
> there was no DHCP response.
Yes, you should see a DCHP response frame.
> Another question, does connman manage DHCP lease time? How can I
> configure DHCP lease time for much longer?
Not sure what you mean here. The lease time is defined by the DHCP
server. ConnMan is usally just the DHCP client unless you tether the
uplink connection. In this case, ConnMan will act as DHCP server for
the network it creates.
gdhcp/server.c:#define DEFAULT_DHCP_LEASE_SEC (8*60*60)
gdhcp/server.c: dhcp_server->lease_seconds = DEFAULT_DHCP_LEASE_SEC;
The current hard coded lease time as server is 8 hours.
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 51, Issue 22
***************************************
