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. [PATCH 0/2] Fixes for stringop-overflow reports (Daniel Wagner)
2. [PATCH 1/2] vpn: Do not use invalid pointer for logging
(Daniel Wagner)
3. [PATCH 2/2] wireguard: Fix struct sockaddr usage (Daniel Wagner)
4. Unable to scan wifi connman 1.38 (Michael Nazzareno Trimarchi)
5. Technical services ([email protected])
6. Technical services ([email protected])
7. paul wililam ([email protected])
8. Fwd: connman wifi disconnect problem (KeithG)
9. Re: connman wifi disconnect problem (KeithG)
----------------------------------------------------------------------
Date: Fri, 9 Oct 2020 09:40:27 +0200
From: Daniel Wagner <[email protected]>
Subject: [PATCH 0/2] Fixes for stringop-overflow reports
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Message-ID: <[email protected]>
Denis reported a couple of errors from gcc. Fix them.
Daniel Wagner (2):
vpn: Do not use invalid pointer for logging
wireguard: Fix struct sockaddr usage
vpn/plugins/wireguard.c | 47 ++++++++++++++++++++++-------------------
vpn/vpn-config.c | 2 +-
2 files changed, 26 insertions(+), 23 deletions(-)
--
2.28.0
------------------------------
Date: Fri, 9 Oct 2020 09:40:28 +0200
From: Daniel Wagner <[email protected]>
Subject: [PATCH 1/2] vpn: Do not use invalid pointer for logging
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Message-ID: <[email protected]>
The host pointer is NULL, so don't try print the host name. While at
it also add some help to user what is wrong.
---
vpn/vpn-config.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/vpn/vpn-config.c b/vpn/vpn-config.c
index 34a1144d0e03..301243b5cc17 100644
--- a/vpn/vpn-config.c
+++ b/vpn/vpn-config.c
@@ -252,7 +252,7 @@ static int load_provider(GKeyFile *keyfile, const char
*group,
DBG("provider identifier %s", id);
} else {
- DBG("invalid values host %s domain %s", host, domain);
+ DBG("invalid configuration: no host specified");
err = -EINVAL;
goto err;
}
--
2.28.0
------------------------------
Date: Fri, 9 Oct 2020 09:40:29 +0200
From: Daniel Wagner <[email protected]>
Subject: [PATCH 2/2] wireguard: Fix struct sockaddr usage
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Message-ID: <[email protected]>
wg_dns_reresolve_cb() tries to read 16 bytes from the addr variable in
case of IPv6 but struct sockaddr has size of 8 bytes. Introduce a
helper struct containing IPv4 and IPv6 sockaddr as superset of all IP
based sockaddr.
This helper struct is identically to the 'union endpoint' in
wireguard.h. But we don't want to touch this header file as it is 100%
copy from the upstream WireGuard project.
Fixes: 90592f7a5835 ("wireguard: Regular reresolve endpoint address")
---
vpn/plugins/wireguard.c | 47 ++++++++++++++++++++++-------------------
1 file changed, 25 insertions(+), 22 deletions(-)
diff --git a/vpn/plugins/wireguard.c b/vpn/plugins/wireguard.c
index 536adbf15b6d..7541dd6e36bb 100644
--- a/vpn/plugins/wireguard.c
+++ b/vpn/plugins/wireguard.c
@@ -59,6 +59,14 @@ struct wireguard_info {
int reresolve_id;
};
+struct sockaddr_u {
+ union {
+ struct sockaddr sa;
+ struct sockaddr_in sin;
+ struct sockaddr_in6 sin6;
+ };
+};
+
static int parse_key(const char *str, wg_key key)
{
unsigned char *buf;
@@ -126,7 +134,7 @@ static int parse_allowed_ips(const char *allowed_ips,
wg_peer *peer)
return 0;
}
-static int parse_endpoint(const char *host, const char *port, struct sockaddr
*addr)
+static int parse_endpoint(const char *host, const char *port, struct
sockaddr_u *addr)
{
struct addrinfo hints;
struct addrinfo *result, *rp;
@@ -246,24 +254,17 @@ static char *get_ifname(void)
return NULL;
}
-static bool sockaddr_cmp_addr(struct sockaddr *a, struct sockaddr *b)
+static bool sockaddr_cmp_addr(struct sockaddr_u *a, struct sockaddr_u *b)
{
- if (a->sa_family != b->sa_family)
+ if (a->sa.sa_family != b->sa.sa_family)
return false;
- if (a->sa_family == AF_INET) {
- struct sockaddr_in *a4 = (struct sockaddr_in *)a;
- struct sockaddr_in *b4 = (struct sockaddr_in *)b;
-
- return !memcmp(a4, b4, sizeof(struct sockaddr_in));
- } else if (a->sa_family == AF_INET6) {
- struct sockaddr_in6 *a6 = (struct sockaddr_in6 *)a;
- struct sockaddr_in6 *b6 = (struct sockaddr_in6 *)b;
-
- return !memcmp(a6->sin6_addr.s6_addr,
- b6->sin6_addr.s6_addr,
- sizeof(a6->sin6_addr.s6_addr));
- }
+ if (a->sa.sa_family == AF_INET)
+ return !memcmp(&a->sin, &b->sin, sizeof(struct sockaddr_in));
+ else if (a->sa.sa_family == AF_INET6)
+ return !memcmp(a->sin6.sin6_addr.s6_addr,
+ b->sin6.sin6_addr.s6_addr,
+ sizeof(a->sin6.sin6_addr.s6_addr));
return false;
}
@@ -271,8 +272,8 @@ static bool sockaddr_cmp_addr(struct sockaddr *a, struct
sockaddr *b)
static gboolean wg_dns_reresolve_cb(gpointer user_data)
{
struct wireguard_info *info = user_data;
+ struct sockaddr_u addr;
int err;
- struct sockaddr addr;
DBG("");
@@ -281,14 +282,15 @@ static gboolean wg_dns_reresolve_cb(gpointer user_data)
if (err)
return TRUE;
- if (sockaddr_cmp_addr(&addr, &info->peer.endpoint.addr))
+ if (sockaddr_cmp_addr(&addr,
+ (struct sockaddr_u *)&info->peer.endpoint.addr))
return TRUE;
- if (addr.sa_family == AF_INET)
- memcpy(&info->peer.endpoint.addr, &addr,
+ if (addr.sa.sa_family == AF_INET)
+ memcpy(&info->peer.endpoint.addr, &addr.sin,
sizeof(info->peer.endpoint.addr4));
else
- memcpy(&info->peer.endpoint.addr, &addr,
+ memcpy(&info->peer.endpoint.addr, &addr.sin6,
sizeof(info->peer.endpoint.addr6));
DBG("Endpoint address has changed, udpate WireGuard device");
@@ -382,7 +384,8 @@ static int wg_connect(struct vpn_provider *provider,
option = "51820";
gateway = vpn_provider_get_string(provider, "Host");
- err = parse_endpoint(gateway, option, &info->peer.endpoint.addr);
+ err = parse_endpoint(gateway, option,
+ (struct sockaddr_u *)&info->peer.endpoint.addr);
if (err)
goto done;
--
2.28.0
------------------------------
Date: Fri, 9 Oct 2020 11:09:16 +0200
From: Michael Nazzareno Trimarchi <[email protected]>
Subject: Unable to scan wifi connman 1.38
To: connman <[email protected]>
Message-ID:
<CAOf5uw=W-7MgM4N=mxfv8fekxt0bvhpz9un5he1mpnqfajp...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi all
Where can I start to debug?
connmand[4715]: plugins/wifi.c:interface_state() wifi (nil) interface state 2
connmand[4715]: gsupplicant/supplicant.c:interface_property() state disconnected
(2)
connmand[4715]: gsupplicant/supplicant.c:signal_name_owner_changed()
connmand[4715]: src/technology.c:scan() technology 0xaaab04769d50 request from :
1.61
connmand[4715]: src/device.c:connman_device_request_scan() device 0xaaab0476ea00
err -67
connmand[4715]: src/technology.c:reply_scan_pending() technology 0xaaab04769d50
err -67
connmand[4715]: src/technology.c:reply_scan_pending() reply to :1.61
connmand[4715]: src/device.c:device_pending_reset() device 0xaaab0476ea00
rfkill is unblocked
power is powered.
I'm using wpa_supplicant
Michael
--
Michael Nazzareno Trimarchi
Amarula Solutions BV
COO Co-Founder
Cruquiuskade 47 Amsterdam 1018 AM NL
T. +31(0)851119172
M. +39(0)3479132170
[`as] https://www.amarulasolutions.com
------------------------------
Date: Fri, 09 Oct 2020 09:41:01 -0000
From: [email protected]
Subject: Technical services
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
??Open the web browser and visit McAfee.com/activate. ??Sign in to your McAfee
Account. ??Enter 25 Digit Mcafee Product key to Activate it.
[url=http://mcafeecomactivate.live/]Mcafee.com/Activate[/url]
Visit Support.brother.com and enter your printer Model to download Brother
Printer Drivers. Install it & Begin with your Printing.
[url=http://brotherprinterdrivers.live/]Brother Printer Drivers[/url]
Netgear Extender Not Working?Try to open www.mywifiext.net to setup of WiFi
Extender. Check out the steps for WiFi extender Configuration.
[url=http://mywifiextenders.net/]MywifiExt[/url]
------------------------------
Date: Fri, 09 Oct 2020 09:41:58 -0000
From: [email protected]
Subject: Technical services
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
??Open the web browser and visit McAfee.com/activate. ??Sign in to your McAfee
Account. ??Enter 25 Digit Mcafee Product key to Activate it.
[url=http://mcafeecomactivate.live/]Mcafee.com/Activate[/url]
Visit Support.brother.com and enter your printer Model to download Brother
Printer Drivers. Install it & Begin with your Printing.
[url=http://brotherprinterdrivers.live/]Brother Printer Drivers[/url]
Netgear Extender Not Working?Try to open www.mywifiext.net to setup of WiFi
Extender. Check out the steps for WiFi extender Configuration.
[url=http://mywifiextenders.net/]MywifiExt[/url]
------------------------------
Date: Fri, 09 Oct 2020 09:42:24 -0000
From: [email protected]
Subject: paul wililam
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Open the web browser and visit McAfee.com/activate.Sign in to your McAfee
Account.Enter 25 Digit Mcafee Product key to Activate it.
http://mcafeecomactivate.live/
Visit Support.brother.com and enter your printer Model to download Brother
Printer Drivers. Install it & Begin with your Printing.
http://brotherprinterdrivers.live/
My name is Paul william. I work as a Technical Specialist at mywifiext. I will
be glad to help you out with any sort of information related to any technical
difficulty.
http://mywifiextenders.net/
------------------------------
Date: Fri, 9 Oct 2020 11:56:47 -0500
From: KeithG <[email protected]>
Subject: Fwd: connman wifi disconnect problem
To: [email protected]
Message-ID:
<CAG17S_MsafhRNWY0L+ULWto559dVHUwr=23czuvmkmcjpdu...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="0000000000002d971d05b13fd6ff"
--0000000000002d971d05b13fd6ff
Content-Type: text/plain; charset="UTF-8"
Sorry, Sent this off list and meant to send it to the list
--0000000000002d971d05b13fd6ff
Content-Type: text/html; charset="UTF-8"
<div dir="ltr">Sorry, Sent this off list and meant to send it to the
list<br></div>
--0000000000002d971d05b13fd6ff--
------------------------------
Date: Fri, 9 Oct 2020 12:17:49 -0500
From: KeithG <[email protected]>
Subject: Re: connman wifi disconnect problem
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Message-ID:
<CAG17S_P3S5FMS1izXPzOF7Zrj=x48za3o1hulb8tttszrmx...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="0000000000007c3b3205b140216b"
--0000000000007c3b3205b140216b
Content-Type: text/plain; charset="UTF-8"
On Fri, Oct 9, 2020 at 10:57 AM KeithG <[email protected]> wrote:
>
>
> On Wed, Oct 7, 2020 at 5:30 PM KeithG <[email protected]> wrote:
>
>>
>>
>> On Wed, Oct 7, 2020 at 1:15 AM Daniel Wagner <[email protected]> wrote:
>>
>>> On Tue, Oct 06, 2020 at 09:01:54AM -0500, KeithG wrote:
>>> > As I see it, there are still 3 strange things going on:
>>> > 1) the latest git will not grab an ipv4 address. I will revert that
>>> commit
>>> > and try this again. Probably have time later this week.
>>>
>>> Yes, please. It's the only commit which modified anything around DHCP.
>>>
>>> > 2) the IPv6 online check still always fails (though it has a valid
>>> ipv4 and
>>> > ipv6 address) I can connect to ipv6 addresses via ping/curl/wget and I
>>> can
>>> > connect to it via ssh with its ipv6 address. I currently disable the
>>> online
>>> > check and the link shows as AR and not AO.
>>>
>>> I've still not setup an IPv6 network for testing, thus it's hard to test.
>>>
>>> > 3) (most confounding) I am using a setting for wpa_supplicant which
>>> seems
>>> > to work to get iwd to reconnect when the router goes down then back up.
>>> > This setting is supposed to only work with wpa_supplicant. I am leery
>>> of
>>> > calling this 'fixed' on my end as it is not supposed to work.
>>>
>>> Are you referring to BackgroundScanning? This doesn't do anything for
>>> iwd. There is literally no code in ConnMan's core nor in the iwd plugin
>>> looking at this variable.
>>>
>>> > On this, I wonder if it would reconnect if connman actually forced the
>>> iwd
>>> > config setting to AutoConnect=true. Currently when connman is
>>> controlling
>>> > iwd, the iwd config looks like this:
>>> >
>>> > [Security]
>>> > PreSharedKey=xxxxxx
>>> > Passphrase=password
>>> >
>>> > [Settings]
>>> > AutoConnect=false
>>> >
>>> > I cannot edit the AutoConnect to be 'true' because connman is
>>> controlling
>>> > it and resets it every time I try to edit it. But, without the
>>> > BacgroundScan setting in main.conf, iwd never gets a trigger to scan
>>> after
>>> > it has lost the connection and, therefore will never reconnect when the
>>> > SSID reappears. When I use systemd-networkd and iwd, I can edit this
>>> iwd
>>> > setting to true and it always reconnects. wpa_supplicant is not
>>> installed.
>>>
>>> As I explained, ConnMan is disabling iwd's AutoConnect. When to connect
>>> to a network is ConnMan's decision not iwd.
>>>
>>> ConnMan doesn't need to tell iwd when to scan. The BackgroundScanning
>>> knob was added to ConnMan because wpa_supplicant is only doing have of
>>> the job. Please have a look at one of Marcel Holtmann's iwd
>>> presentation, e.g.
>>>
>>> https://www.youtube.com/watch?v=QIqT2obSPDk
>>
>>
>> Daniel,
>>
>> I appreciate the link. Interesting.
>>
>> It appeared to me that flag set them to always connect, but it was more
>> complicated than that and part of that was my impatience. I think I was
>> just not waiting long enough for it to scan.
>>
>> I have made things really simple and have set up a spare router so I do
>> not upset the family. I have a keyboard and a small display connected to
>> the rpi so I can interact with it directly and tail the log. I am running
>> the latest connman-git r23 with the dhcp patch reverted (so it grabs an
>> ipv4 address) and iwd 1.9
>>
>> main.conf only has
>> AllowHostnameUpdates = false
>> connman.service exec line is:
>>
>> ExecStart=/usr/bin/connmand -n --nodnsproxy -d plugins/iwd.c
>>
>> If I boot it always connects. If I power down the radio on the router it
>> will reconnect eventually.
>> I did notice one time I got a 'Service state machine inconsistency
>> detected' but it did reconnect after this error.
>>
>> If I turn off the radio on the router then back on, I get a lag ~4
>> minutes before it rescans. It will re-scan and re-connects. I did this
>> again and it took 13 minutes. I did it again and it took ~14 minutes. It
>> seems like it is on a schedule to trigger the scan at ~15 minutes? The 14+
>> minute wait for a rescan seems like a long time to me. Then I did it again
>> and it was almost immediate. Is there any way to control this? My phone
>> rescans almost immediately every time and reconnects.
>>
>> Keith
>>
>
> Daniel et al,
>
> The previous test was on an RPi. I repeated the test on a Dell Laptop with
> a Broadcom card running Arch Linux, iwd 1.9 and the latest connman with the
> DHCP patch reverted (same as above).
> On this I waited over 25 minutes after the SSID was back on and a rescan
> was never triggered. What mechanism triggers the scan? dbus? If so, how is
> that done. I ask as there must be something awry with Arch. If it is
> useful, I grabbed the journal -u connman over this as well as
> monitor-connman and monitor-iwd. I see nothing noteworthy in them. It is
> clear that the radio goes away and that connman does the housekeeping to
> wipe the IP addresses and then waits. When the radio comes back nothing
> happens. connmanctl services shows AutoConnect=true.
>
> I repeated the test but with systemd/iwd and it reconnects almost
> immediately after the SSID appears.
>
> This is the end of the monitor-iwd:
> {Station} [/net/connman/iwd/0/4] Scanning = False
> {Station} [/net/connman/iwd/0/4] State = connecting
> {Station} [/net/connman/iwd/0/4] ConnectedNetwork =
> /net/connman/iwd/0/4/4f70656e5772745f3530_psk
> {Network} [/net/connman/iwd/0/4/4f70656e5772745f3530_psk] Connected = True
> {Station} [/net/connman/iwd/0/4] State = connected
> {KnownNetwork} [/net/connman/iwd/4f70656e5772745f3530_psk]
> LastConnectedTime = 2020-10-09T14:58:56Z
>
> The iwd journal is interesting, though:
> $ journalctl -u iwd -f
> -- Logs begin at Wed 2020-10-07 08:34:24 CDT. --
> Oct 09 09:11:42 keith-dell iwd[389]: Bands: 2.4 GHz 5 GHz
> Oct 09 09:11:42 keith-dell iwd[389]: Ciphers: CCMP TKIP
> Oct 09 09:11:42 keith-dell iwd[389]: Supported iftypes: ad-hoc
> station ap
> Oct 09 09:11:47 keith-dell iwd[389]: hardware_rekey not supported
> Oct 09 09:24:09 keith-dell iwd[389]: Received Deauthentication event,
> reason: 3, from_ap: true
> Oct 09 09:24:09 keith-dell iwd[389]: Connected BSS not in scan results
> Oct 09 09:24:09 keith-dell iwd[389]: authentication timed out
> Oct 09 09:49:24 keith-dell iwd[389]: authentication timed out
> Oct 09 09:56:42 keith-dell iwd[389]: Received Deauthentication event,
> reason: 3, from_ap: false
> Oct 09 09:58:13 keith-dell iwd[389]: Received Deauthentication event,
> reason: 3, from_ap: true
> Oct 09 10:16:35 keith-dell iwd[389]: Received Deauthentication event,
> reason: 3, from_ap: true
> Oct 09 10:17:19 keith-dell iwd[389]: authentication timed out
> Oct 09 10:26:17 keith-dell iwd[389]: Received Deauthentication event,
> reason: 3, from_ap: true
> Oct 09 10:26:36 keith-dell iwd[389]: authentication timed out
> Oct 09 10:28:05 keith-dell iwd[389]: authentication timed out
> Oct 09 10:46:55 keith-dell iwd[389]: Received Deauthentication event,
> reason: 3, from_ap: true
> Oct 09 10:47:14 keith-dell iwd[389]: authentication timed out
> Oct 09 10:48:42 keith-dell iwd[389]: authentication timed out
>
> 9:24:09 I turned off the router and back on in maybe a minute. Connman was
> controlling the interface. It never reconnected. Even after a 'connmanctl
> scan wifi'. I restarted the connman service and it reconnected.
>
> I then shut down connman at 9:53 and restarted systemd-networkd and then
> went in iwctl and set the SSID to AutoConnect and connected. at 9:58 I ran
> the test and it reconnected. I ran it again at 10:16 and it reconnected. I
> tested again and it would not reconnect until I re-scanned. I tried this
> again and even though the network shows in the scan it will not reconnect.
> No amount of scanning will get it to reconnect. Restart the iwd service and
> it immediately connects.
>
> It appears that there is some strange stuff going on with iwd 1.9... Is
> the 'authentication timed out' an indicator of something wrong?
>
>
I went and did these same tests on my other laptop with an intel card
instead of a broadcom card. there is a slight difference.
When I use systemd-networkd controlling the network, it reconnects, every
time, immediately no matter how long I wait nor how often I power down then
up the SSID. It does seem that iwd works better with the intel card instead
of the broadcom.
With connman, I get the same result as on the other laptop. If connman is
controlling the interface and I power down the SSID, connman clears the
interface, but when I power back up, it never reconnects. It does not seem
to make any difference if I run connman 1.38 or the current connman-git
with the reverted DHCP patch. It does not seem to make any difference if I
run iwd 1.9 nor if I run the latest iwd git.
The configuration flags for connman are:
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var \
--bindir=/usr/bin \
--sbindir=/usr/bin \
--with-systemdunitdir=/usr/lib/systemd/system \
--enable-pptp \
--enable-openconnect \
--enable-vpnc \
--enable-openvpn \
--enable-polkit \
--enable-client \
--enable-nmcompat \
--enable-test \
--enable-pie \
--enable-iwd
I'm at a loss as to why this is inconsistent.
--0000000000007c3b3205b140216b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Fri, Oct 9, 2020 at 10:57 AM Keith=
G <<a href=3D"mailto:[email protected]";>[email protected]</a>> wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Wed, Oct 7, 2020 at 5:30 PM KeithG <<a href=
=3D"mailto:[email protected]"; target=3D"_blank">[email protected]</a>>=
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Wed, Oct 7, 2020 at 1:15 AM Daniel Wagner =
<<a href=3D"mailto:[email protected]"; target=3D"_blank">[email protected]</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tu=
e, Oct 06, 2020 at 09:01:54AM -0500, KeithG wrote:<br>
> As I see it, there are still 3 strange things going on:<br>
> 1) the latest git will not grab an ipv4 address. I will revert that co=
mmit<br>
> and try this again. Probably have time later this week.<br>
<br>
Yes, please. It's the only commit which modified anything around DHCP.<=
br>
<br>
> 2) the IPv6 online check still always fails (though it has a valid ipv=
4 and<br>
> ipv6 address) I can connect to ipv6 addresses via ping/curl/wget and I=
can<br>
> connect to it via ssh with its ipv6 address. I currently disable the o=
nline<br>
> check and the link shows as AR and not AO.<br>
<br>
I've still not setup an IPv6 network for testing, thus it's hard to=
test.<br>
<br>
> 3) (most confounding) I am using a setting for wpa_supplicant which se=
ems<br>
> to work to get iwd to reconnect when the router goes down then back up=
.<br>
> This setting is supposed to only work with wpa_supplicant. I am leery =
of<br>
> calling this 'fixed' on my end as it is not supposed to work.<=
br>
<br>
Are you referring to BackgroundScanning? This doesn't do anything for<b=
r>
iwd. There is literally no code in ConnMan's core nor in the iwd plugin=
<br>
looking at this variable.<br>
<br>
> On this, I wonder if it would reconnect if connman actually forced the=
iwd<br>
> config setting to AutoConnect=3Dtrue. Currently when connman is contro=
lling<br>
> iwd, the iwd config looks like this:<br>
> <br>
> [Security]<br>
> PreSharedKey=3Dxxxxxx<br>
> Passphrase=3Dpassword<br>
> <br>
> [Settings]<br>
> AutoConnect=3Dfalse<br>
> <br>
> I cannot edit the AutoConnect to be 'true' because connman is =
controlling<br>
> it and resets it every time I try to edit it. But, without the<br>
> BacgroundScan setting in main.conf, iwd never gets a trigger to scan a=
fter<br>
> it has lost the connection and, therefore will never reconnect when th=
e<br>
> SSID reappears. When I use systemd-networkd and iwd, I can edit this i=
wd<br>
> setting to true and it always reconnects. wpa_supplicant is not instal=
led.<br>
<br>
As I explained, ConnMan is disabling iwd's AutoConnect. When to connect=
<br>
to a network is ConnMan's decision not iwd.<br>
<br>
ConnMan doesn't need to tell iwd when to scan. The BackgroundScanning<b=
r>
knob was added to ConnMan because wpa_supplicant is only doing have of<br>
the job. Please have a look at one of Marcel Holtmann's iwd<br>
presentation, e.g.<br>
<br>
=C2=A0 <a href=3D"https://www.youtube.com/watch?v=3DQIqT2obSPDk"; rel=3D"nor=
eferrer" target=3D"_blank">https://www.youtube.com/watch?v=3DQIqT2obSPDk</a=
></blockquote><div><br></div><div>Daniel,</div><div><br></div><div>I apprec=
iate the link. Interesting. <br></div><div><br></div><div>It appeared to me=
that flag set them to always connect, but it was more complicated than tha=
t and part of that was my impatience.=20
I think I was just not waiting long enough for it to scan.=20
</div><div><br></div><div>I have made things really simple and have set up =
a spare router so I do not upset the family. I have a keyboard and a small =
display connected to the rpi so I can interact with it directly and tail th=
e log. I am running the latest connman-git r23 with the dhcp patch reverted=
(so it grabs an ipv4 address) and iwd 1.9<br></div><div><br></div><div>mai=
n.conf only has <br></div><div>AllowHostnameUpdates =3D false</div><div>con=
nman.service exec line is:</div><div><br></div><div>ExecStart=3D/usr/bin/co=
nnmand -n --nodnsproxy -d plugins/iwd.c<br></div><div><br></div><div>If I b=
oot it always connects. If I power down the radio on the router it will rec=
onnect eventually.</div><div>I did notice one time I got a 'Service sta=
te machine inconsistency detected' but it did reconnect after this erro=
r.<br></div><div><br></div><div>If I turn off the radio on the router then =
back on, I get a lag ~4 minutes before it rescans. It will re-scan and re-c=
onnects. I did this again and it took 13 minutes. I did it again and it too=
k=C2=A0 ~14 minutes. It seems like it is on a schedule to trigger the scan =
at ~15 minutes? The 14+ minute wait for a rescan seems like a long time to =
me.
Then I did it again and it was almost immediate. Is there any way to contro=
l this?
My phone rescans almost immediately every time and reconnects.<br></div><d=
iv><br></div><div>Keith<br></div></div></div></blockquote><div><br></div><d=
iv>Daniel et al,</div><div><br></div><div>The previous test was on an RPi. =
I repeated the test on a Dell Laptop with a Broadcom card running Arch Linu=
x, iwd 1.9 and the latest connman with the DHCP patch reverted (same as abo=
ve). <br></div><div>On this I waited over 25 minutes after the SSID was bac=
k on and a rescan was never triggered. What mechanism triggers the scan? db=
us? If so, how is that done. I ask as there must be something awry with Arc=
h. If it is useful, I grabbed the journal -u connman over this as well as m=
onitor-connman and monitor-iwd. I see nothing noteworthy in them. It is cle=
ar that the radio goes away and that connman does the housekeeping to wipe =
the IP addresses and then waits. When the radio comes back nothing happens.=
connmanctl services shows AutoConnect=3Dtrue. <br></div><div><br></div><di=
v>I repeated the test but with systemd/iwd and it reconnects almost immedia=
tely after the SSID appears. <br></div><div><br></div><div>This is the end =
of the monitor-iwd:</div><div>{Station} [/net/connman/iwd/0/4] Scanning =3D=
False<br>{Station} [/net/connman/iwd/0/4] State =3D connecting<br>{Station=
} [/net/connman/iwd/0/4] ConnectedNetwork =3D /net/connman/iwd/0/4/4f70656e=
5772745f3530_psk<br>{Network} [/net/connman/iwd/0/4/4f70656e5772745f3530_ps=
k] Connected =3D True<br>{Station} [/net/connman/iwd/0/4] State =3D connect=
ed<br>{KnownNetwork} [/net/connman/iwd/4f70656e5772745f3530_psk] LastConnec=
tedTime =3D 2020-10-09T14:58:56Z</div><div><br></div><div>The iwd journal i=
s interesting, though:</div><div>$ journalctl -u iwd -f<br>-- Logs begin at=
Wed 2020-10-07 08:34:24 CDT. --<br>Oct 09 09:11:42 keith-dell iwd[389]: =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bands: 2.4 GHz 5 GHz<br>Oct 09 09:11:42 keith-d=
ell iwd[389]: =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ciphers: CCMP TKIP<br>Oct 09 09:1=
1:42 keith-dell iwd[389]: =C2=A0 =C2=A0 =C2=A0 =C2=A0 Supported iftypes: ad=
-hoc station ap<br>Oct 09 09:11:47 keith-dell iwd[389]: hardware_rekey not =
supported<br>Oct 09 09:24:09 keith-dell iwd[389]: Received Deauthentication=
event, reason: 3, from_ap: true<br>Oct 09 09:24:09 keith-dell iwd[389]: Co=
nnected BSS not in scan results<br>Oct 09 09:24:09 keith-dell iwd[389]: aut=
hentication timed out<br>Oct 09 09:49:24 keith-dell iwd[389]: authenticatio=
n timed out<br>Oct 09 09:56:42 keith-dell iwd[389]: Received Deauthenticati=
on event, reason: 3, from_ap: false<br>Oct 09 09:58:13 keith-dell iwd[389]:=
Received Deauthentication event, reason: 3, from_ap: true</div><div>Oct 09=
10:16:35 keith-dell iwd[389]: Received Deauthentication event, reason: 3, =
from_ap: true<br>Oct 09 10:17:19 keith-dell iwd[389]: authentication timed =
out</div><div>Oct 09 10:26:17 keith-dell iwd[389]: Received Deauthenticatio=
n event, reason: 3, from_ap: true<br>Oct 09 10:26:36 keith-dell iwd[389]: a=
uthentication timed out<br>Oct 09 10:28:05 keith-dell iwd[389]: authenticat=
ion timed out<br>Oct 09 10:46:55 keith-dell iwd[389]: Received Deauthentica=
tion event, reason: 3, from_ap: true<br>Oct 09 10:47:14 keith-dell iwd[389]=
: authentication timed out<br>Oct 09 10:48:42 keith-dell iwd[389]: authenti=
cation timed out</div><div><br></div><div>9:24:09 I turned off the router a=
nd back on in maybe a minute. Connman was controlling the interface. It nev=
er reconnected. Even after a 'connmanctl scan wifi'. I restarted th=
e connman service and it reconnected. <br></div><div><br></div><div>I then =
shut down connman at 9:53 and restarted systemd-networkd and then went in i=
wctl and set the SSID to AutoConnect and connected. at 9:58 I ran the test =
and it reconnected. I ran it again at 10:16 and it reconnected. I tested ag=
ain and it would not reconnect until I re-scanned. I tried this again and e=
ven though the network shows in the scan it will not reconnect. No amount o=
f scanning will get it to reconnect. Restart the iwd service and it immedia=
tely connects.=C2=A0 <br></div><div><br></div><div>It appears that there is=
some strange stuff going on with iwd 1.9... Is the 'authentication tim=
ed out' an indicator of something wrong? <br></div><div><br></div></div=
></div></blockquote><div><br></div><div>I went and did these same tests on =
my other laptop with an intel card instead of a broadcom card. there is a s=
light difference.</div><div>When I use systemd-networkd controlling the net=
work, it reconnects, every time, immediately no matter how long I wait nor =
how often I power down then up the SSID. It does seem that iwd works better=
with the intel card instead of the broadcom.<br></div><div>With connman, I=
get the same result as on the other laptop. If connman is controlling the =
interface and I power down the SSID, connman clears the interface, but when=
I power back up, it never reconnects. It does not seem to make any differe=
nce if I run connman 1.38 or the current connman-git with the reverted DHCP=
patch. It does not seem to make any difference if I run iwd 1.9 nor if I r=
un the latest iwd git. <br></div><div><br></div><div>The configuration flag=
s for connman are:</div><div>
<pre><code class=3D"gmail-hljs"> ./configure --prefix=3D/usr --sysconfdir=
=3D/etc --localstatedir=3D/var \
--bindir=3D/usr/bin \
--sbindir=3D/usr/bin \
--with-systemdunitdir=3D/usr/lib/systemd/system \
--enable-pptp \
--enable-openconnect \
--enable-vpnc \
--enable-openvpn \
--enable-polkit \
--enable-client \
--enable-nmcompat \
--enable-test \
--enable-pie \
--enable-iwd</code></pre>
</div><div>I'm at a loss as to why this is inconsistent.<br></div></div=
></div>
--0000000000007c3b3205b140216b--
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 60, Issue 10
***************************************
