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: connman wifi disconnect problem (KeithG)
----------------------------------------------------------------------
Date: Fri, 9 Oct 2020 15:25:34 -0500
From: KeithG <[email protected]>
Subject: Re: connman wifi disconnect problem
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Message-ID:
<cag17s_p5qffeeeupsroquypvymkpnl1hfa49tq5nx_7fo6t...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="000000000000e3ad2e05b142c028"
--000000000000e3ad2e05b142c028
Content-Type: text/plain; charset="UTF-8"
On Fri, Oct 9, 2020 at 12:17 PM KeithG <[email protected]> wrote:
>
>
> 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.
>
I ran across a post that pointed to a newer firmware blob from
broadcom/cypress and tried it on the RPi.
It now works some of the time. This is the first time I have been able to
get it to reconnect with connman controlling things for the first time.
I am trying to characterize when it works versus when it does not work. So
far, all I can see is that when it works, the monitor-iwd script shows
Scanning = False then Scanning = True then it sees the SSID it then
connects. When it doesn't work, it shows Scanning = False then it never
re-scans. When it ceases reconnecting, I can restart iwd, it will connect,
but it will not reconnect when the router is power cycled until I reboot.
If I restart connman it will connect> I did get it to reconnect once, but
not again. It is like something gets stuck which stops iwd from re
scanning. Does iwd need to be running before connman or vice versa?
Keith
--000000000000e3ad2e05b142c028
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 12:17 PM 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 Fri, Oct 9, 2020 at 10:57 AM 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 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 Wag=
ner <<a href=3D"mailto:[email protected]"; target=3D"_blank">[email protected]<=
/a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">O=
n Tue, 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> ./configure --prefix=3D/usr --sysconfdir=3D/etc --localstatedi=
r=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></blockquote><div><br></div><div>I ran across a post that pointed to=
a newer firmware blob from broadcom/cypress and tried it on the RPi. <br><=
/div><div><br></div><div>It now works some of the time. This is the first t=
ime I have been able to get it to reconnect with connman controlling things=
for the first time.=C2=A0 <br></div><div><br></div><div>I am trying to cha=
racterize when it works versus when it does not work. So far, all I can see=
is that when it works, the monitor-iwd script shows Scanning =3D False the=
n Scanning =3D True then it sees the SSID it then connects. When it doesn&#=
39;t work, it shows Scanning =3D False then it never re-scans. When it ceas=
es reconnecting, I can restart iwd, it will connect, but it will not reconn=
ect when the router is power cycled until I reboot. If I restart connman it=
will connect> I did get it to reconnect once, but not again. It is like=
something gets stuck which stops iwd from re scanning. Does iwd need to be=
running before connman or vice versa?</div><div><br></div><div>Keith<br></=
div></div></div>
--000000000000e3ad2e05b142c028--
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 60, Issue 11
***************************************
