8:18 a.m.
I have been trying to diagnose a problem I am having with my RPis. I am
using iwd and connman to manage my ethernet connectivity. What I have
noticed is that after a while, sometimes, connectivity stops and I cannot
reconnect except after a reboot. I have seen this on RPi3's more so than
with RPi1/2. I have only noticed it with wlan0 and not with ethernet.
From the journal, it looks like the network goes down (wlan0), connman
quickly notes it is down and pulls the ip address and sets the interface
down and then avahi identifies that it is down. It is interesting that
sometime before this, the ipv4 address was withdrawn. I am running an
openWRT router (other side of the DHCP equation) and this RPI MAC has a
reserved ipv4 address on the router.
If I restart connman on the RPi, it will not regain connectivity on ipv4 or
ipv6 on wlan0. If I reboot the router and then restart connman on the RPi,
it will not regain connectivity. I have to power cycle the RPI to get it to
connect again. If I plug in the ethernet cable, it grabs an address
immediately and everything is back, but it will still not reconnect over
wifi. I must reboot the RPi to get it to reconnect. I will see if I can
figure out how to have journal log more info on connman...
Any idea what this could be? I will flash the router with ddwrt and see if
it is the router.
In my /etc/connman/main.conf, I have this:
[General]
FallbackNameservers = 8.8.8.8,8.8.4.4
DefaultAutoConnectTechnologies = ethernet,wifi
PreferredTechnologies = ethernet,wifi
AllowHostnameUpdates = false
SingleConnectedTechnology = true
AlwaysConnectedTechnologies = ethernet,wifi
AutoConnectRoamingServices = true
The journal shows this:
Jun 20 18:02:19 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
Jun 20 18:02:20 rune64 systemd[1]: dbus-org.freedesktop.timedate1.service:
Succeeded.
Jun 20 18:02:35 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
Jun 20 18:02:39 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
... lots of these 'not responding'...
Jun 20 18:07:54 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
Jun 20 18:07:55 rune64 avahi-daemon[6529]: Withdrawing address record for
2601:241:4200:255:ba27:ebff:fe52:ccd0 on wlan0.
Jun 20 18:07:55 rune64 connmand[259]: wlan0 {del} address
2601:241:4200:255:ba27:ebff:fe52:ccd0/64 label (null)
Jun 20 18:07:55 rune64 avahi-daemon[6529]: Leaving mDNS multicast group on
interface wlan0.IPv6 with address 2601:241:4200:255:ba27:ebff:fe52:ccd0.
Jun 20 18:07:55 rune64 avahi-daemon[6529]: Joining mDNS multicast group on
interface wlan0.IPv6 with address fdcb:9d61:70f3:0:ba27:ebff:fe52:ccd0.
Jun 20 18:07:57 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
Jun 20 18:08:10 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
Jun 20 18:08:13 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
Jun 20 18:08:14 rune64 connmand[259]: wlan0 {del} route 2601:241:4200:255::
gw :: scope 0 <UNIVERSE>
2:01 a.m.
Hi Keith,
its only a assumption, but it could be a firmware problem.
We had also issues with connman and wifi but not on raspi. In our case it was a cypress
chipset.
Regards
Jan
From: KeithG <ys3al35l(a)gmail.com>
Sent: Sunday, June 21, 2020 5:19 PM
To: connman(a)lists.01.org
Subject: connman wifi disconnect problem
I have been trying to diagnose a problem I am having with my RPis. I am using iwd and
connman to manage my ethernet connectivity. What I have noticed is that after a while,
sometimes, connectivity stops and I cannot reconnect except after a reboot. I have seen
this on RPi3's more so than with RPi1/2. I have only noticed it with wlan0 and not
with ethernet.
From the journal, it looks like the network goes down (wlan0), connman quickly notes it is
down and pulls the ip address and sets the interface down and then avahi identifies that
it is down. It is interesting that sometime before this, the ipv4 address was withdrawn. I
am running an openWRT router (other side of the DHCP equation) and this RPI MAC has a
reserved ipv4 address on the router.
If I restart connman on the RPi, it will not regain connectivity on ipv4 or ipv6 on wlan0.
If I reboot the router and then restart connman on the RPi, it will not regain
connectivity. I have to power cycle the RPI to get it to connect again. If I plug in the
ethernet cable, it grabs an address immediately and everything is back, but it will still
not reconnect over wifi. I must reboot the RPi to get it to reconnect. I will see if I can
figure out how to have journal log more info on connman...
Any idea what this could be? I will flash the router with ddwrt and see if it is the
router.
In my /etc/connman/main.conf, I have this:
[General]
FallbackNameservers = 8.8.8.8,8.8.4.4
DefaultAutoConnectTechnologies = ethernet,wifi
PreferredTechnologies = ethernet,wifi
AllowHostnameUpdates = false
SingleConnectedTechnology = true
AlwaysConnectedTechnologies = ethernet,wifi
AutoConnectRoamingServices = true
The journal shows this:
Jun 20 18:02:19 rune64 kernel: nfs: server 192.168.2.198 not responding, timed out
Jun 20 18:02:20 rune64 systemd[1]: dbus-org.freedesktop.timedate1.service: Succeeded.
Jun 20 18:02:35 rune64 kernel: nfs: server 192.168.2.198 not responding, timed out
Jun 20 18:02:39 rune64 kernel: nfs: server 192.168.2.198 not responding, timed out
... lots of these 'not responding'...
Jun 20 18:07:54 rune64 kernel: nfs: server 192.168.2.198 not responding, timed out
Jun 20 18:07:55 rune64 avahi-daemon[6529]: Withdrawing address record for
2601:241:4200:255:ba27:ebff:fe52:ccd0 on wlan0.
Jun 20 18:07:55 rune64 connmand[259]: wlan0 {del} address
2601:241:4200:255:ba27:ebff:fe52:ccd0/64 label (null)
Jun 20 18:07:55 rune64 avahi-daemon[6529]: Leaving mDNS multicast group on interface
wlan0.IPv6 with address 2601:241:4200:255:ba27:ebff:fe52:ccd0.
Jun 20 18:07:55 rune64 avahi-daemon[6529]: Joining mDNS multicast group on interface
wlan0.IPv6 with address fdcb:9d61:70f3:0:ba27:ebff:fe52:ccd0.
Jun 20 18:07:57 rune64 kernel: nfs: server 192.168.2.198 not responding, timed out
Jun 20 18:08:10 rune64 kernel: nfs: server 192.168.2.198 not responding, timed out
Jun 20 18:08:13 rune64 kernel: nfs: server 192.168.2.198 not responding, timed out
Jun 20 18:08:14 rune64 connmand[259]: wlan0 {del} route 2601:241:4200:255:: gw :: scope 0
<UNIVERSE>
6:17 a.m.
Jan,
Good call. I just built this for my architecture (aarch64) and installed
it. Will see if there is any improvement.
Thanks,
Keith
On Mon, Jun 22, 2020 at 4:01 AM Ryll, Jan (GED-SDD2) <Jan.Ryll(a)bshg.com>
wrote:
Hi Keith,
its only a assumption, but it could be a firmware problem.
We had also issues with connman and wifi but not on raspi. In our case it
was a cypress chipset.
Regards
Jan
*From:* KeithG <ys3al35l(a)gmail.com>
*Sent:* Sunday, June 21, 2020 5:19 PM
*To:* connman(a)lists.01.org
*Subject:* connman wifi disconnect problem
I have been trying to diagnose a problem I am having with my RPis. I am
using iwd and connman to manage my ethernet connectivity. What I have
noticed is that after a while, sometimes, connectivity stops and I cannot
reconnect except after a reboot. I have seen this on RPi3's more so than
with RPi1/2. I have only noticed it with wlan0 and not with ethernet.
From the journal, it looks like the network goes down (wlan0), connman
quickly notes it is down and pulls the ip address and sets the interface
down and then avahi identifies that it is down. It is interesting that
sometime before this, the ipv4 address was withdrawn. I am running an
openWRT router (other side of the DHCP equation) and this RPI MAC has a
reserved ipv4 address on the router.
If I restart connman on the RPi, it will not regain connectivity on ipv4
or ipv6 on wlan0. If I reboot the router and then restart connman on the
RPi, it will not regain connectivity. I have to power cycle the RPI to get
it to connect again. If I plug in the ethernet cable, it grabs an address
immediately and everything is back, but it will still not reconnect over
wifi. I must reboot the RPi to get it to reconnect. I will see if I can
figure out how to have journal log more info on connman...
Any idea what this could be? I will flash the router with ddwrt and see if
it is the router.
In my /etc/connman/main.conf, I have this:
[General]
FallbackNameservers = 8.8.8.8,8.8.4.4
DefaultAutoConnectTechnologies = ethernet,wifi
PreferredTechnologies = ethernet,wifi
AllowHostnameUpdates = false
SingleConnectedTechnology = true
AlwaysConnectedTechnologies = ethernet,wifi
AutoConnectRoamingServices = true
The journal shows this:
Jun 20 18:02:19 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
Jun 20 18:02:20 rune64 systemd[1]: dbus-org.freedesktop.timedate1.service:
Succeeded.
Jun 20 18:02:35 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
Jun 20 18:02:39 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
... lots of these 'not responding'...
Jun 20 18:07:54 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
Jun 20 18:07:55 rune64 avahi-daemon[6529]: Withdrawing address record for
2601:241:4200:255:ba27:ebff:fe52:ccd0 on wlan0.
Jun 20 18:07:55 rune64 connmand[259]: wlan0 {del} address
2601:241:4200:255:ba27:ebff:fe52:ccd0/64 label (null)
Jun 20 18:07:55 rune64 avahi-daemon[6529]: Leaving mDNS multicast group on
interface wlan0.IPv6 with address 2601:241:4200:255:ba27:ebff:fe52:ccd0.
Jun 20 18:07:55 rune64 avahi-daemon[6529]: Joining mDNS multicast group on
interface wlan0.IPv6 with address fdcb:9d61:70f3:0:ba27:ebff:fe52:ccd0.
Jun 20 18:07:57 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
Jun 20 18:08:10 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
Jun 20 18:08:13 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
Jun 20 18:08:14 rune64 connmand[259]: wlan0 {del} route
2601:241:4200:255:: gw :: scope 0 <UNIVERSE>
8:44 a.m.
On Mon, Jun 22, 2020 at 8:17 AM KeithG <ys3al35l(a)gmail.com> wrote:
Jan,
Good call. I just built this for my architecture (aarch64) and installed
it. Will see if there is any improvement.
Thanks,
Keith
On Mon, Jun 22, 2020 at 4:01 AM Ryll, Jan (GED-SDD2) <Jan.Ryll(a)bshg.com>
wrote:
> Hi Keith,
>
>
>
> its only a assumption, but it could be a firmware problem.
>
> We had also issues with connman and wifi but not on raspi. In our case it
> was a cypress chipset.
>
>
>
> Regards
>
> Jan
>
>
>
>
>
> *From:* KeithG <ys3al35l(a)gmail.com>
> *Sent:* Sunday, June 21, 2020 5:19 PM
> *To:* connman(a)lists.01.org
> *Subject:* connman wifi disconnect problem
>
>
>
> I have been trying to diagnose a problem I am having with my RPis. I am
> using iwd and connman to manage my ethernet connectivity. What I have
> noticed is that after a while, sometimes, connectivity stops and I cannot
> reconnect except after a reboot. I have seen this on RPi3's more so than
> with RPi1/2. I have only noticed it with wlan0 and not with ethernet.
>
>
>
> From the journal, it looks like the network goes down (wlan0), connman
> quickly notes it is down and pulls the ip address and sets the interface
> down and then avahi identifies that it is down. It is interesting that
> sometime before this, the ipv4 address was withdrawn. I am running an
> openWRT router (other side of the DHCP equation) and this RPI MAC has a
> reserved ipv4 address on the router.
>
>
>
> If I restart connman on the RPi, it will not regain connectivity on ipv4
> or ipv6 on wlan0. If I reboot the router and then restart connman on the
> RPi, it will not regain connectivity. I have to power cycle the RPI to get
> it to connect again. If I plug in the ethernet cable, it grabs an address
> immediately and everything is back, but it will still not reconnect over
> wifi. I must reboot the RPi to get it to reconnect. I will see if I can
> figure out how to have journal log more info on connman...
>
>
>
> Any idea what this could be? I will flash the router with ddwrt and see
> if it is the router.
>
>
>
> In my /etc/connman/main.conf, I have this:
>
> [General]
> FallbackNameservers = 8.8.8.8,8.8.4.4
> DefaultAutoConnectTechnologies = ethernet,wifi
> PreferredTechnologies = ethernet,wifi
> AllowHostnameUpdates = false
> SingleConnectedTechnology = true
> AlwaysConnectedTechnologies = ethernet,wifi
> AutoConnectRoamingServices = true
>
>
>
> The journal shows this:
>
> Jun 20 18:02:19 rune64 kernel: nfs: server 192.168.2.198 not responding,
> timed out
> Jun 20 18:02:20 rune64 systemd[1]:
> dbus-org.freedesktop.timedate1.service: Succeeded.
> Jun 20 18:02:35 rune64 kernel: nfs: server 192.168.2.198 not responding,
> timed out
> Jun 20 18:02:39 rune64 kernel: nfs: server 192.168.2.198 not responding,
> timed out
>
> ... lots of these 'not responding'...
>
> Jun 20 18:07:54 rune64 kernel: nfs: server 192.168.2.198 not responding,
> timed out
> Jun 20 18:07:55 rune64 avahi-daemon[6529]: Withdrawing address record for
> 2601:241:4200:255:ba27:ebff:fe52:ccd0 on wlan0.
> Jun 20 18:07:55 rune64 connmand[259]: wlan0 {del} address
> 2601:241:4200:255:ba27:ebff:fe52:ccd0/64 label (null)
> Jun 20 18:07:55 rune64 avahi-daemon[6529]: Leaving mDNS multicast group
> on interface wlan0.IPv6 with address 2601:241:4200:255:ba27:ebff:fe52:ccd0.
> Jun 20 18:07:55 rune64 avahi-daemon[6529]: Joining mDNS multicast group
> on interface wlan0.IPv6 with address fdcb:9d61:70f3:0:ba27:ebff:fe52:ccd0.
> Jun 20 18:07:57 rune64 kernel: nfs: server 192.168.2.198 not responding,
> timed out
> Jun 20 18:08:10 rune64 kernel: nfs: server 192.168.2.198 not responding,
> timed out
> Jun 20 18:08:13 rune64 kernel: nfs: server 192.168.2.198 not responding,
> timed out
> Jun 20 18:08:14 rune64 connmand[259]: wlan0 {del} route
> 2601:241:4200:255:: gw :: scope 0 <UNIVERSE>
>
I'm still struggling with this and have done a lot of poking at it and
posting Denis off list as well. This is what I 'think' I have learned.
1) iwd as standalone or with systemd-networkd/dhcpch or with NetworkManager
on x64 or on RPIs, all running arch linux, works great at version 1.9. If
the SSID 'goes away' and 'comes back' the computer will reconnect. every
time.
2) NetworkManager works well with iwd and as best I can tell, it will
reconnect via its interaction with iwd.
3) When I run systemd-networkd/dhcpcd with iwd, it is more like it iwd
running standalone as I can edit the /var/lib/iwd/ssid.psk either manually
or through iwctl so that:
[Settings]
AutoConnect=true
In this setup, the computer reconnects at boot *and* when the SSID goes
away and comes back.
4) When connman manages iwd, though, I cannot edit the ssid.psk file and
have it stick. Though it connects every time at boot, it will not reconnect
if the ssid goes away and returns. This is with the headless rpis with
their broadcom cards and with a laptop runnning a full Arch Linux desktop
with an intel wifi card. One other thing I notice is that when it has
disconnected (SSID off then on), the 'connmanctl services' list is
incomplete. It definitely does not show all the currently available ssids
broadcasting. If I type 'connmanctl scan wifi' it will complete a scan
*and* reconnect. It is like connman gets stuck. and stops managing the wifi.
I also note that if the ethernet cable is plugged in on the RPIs then the
device is connected to the wifi ap then the ethernet cable is removed that
all internet connectivity ceases. Both interfaces go down and will not
reconnect requiring a reboot. It is tough for me to really query this as I
see it on my headless rpis and when the connectivity goes away, I have to
reboot to get it back. It did not behave like this with netctl nor does it
behave like this with systemd-networkd.
Also, on the rpis, I have noticed that connman can get into a state where
plugging in the ethernet cable results in nothing. connman will not bring
up the ethernet interface.
We have reworked a php interface from netctl tp work with connman for these
little rpi audio devices and I would love for it to work, but if a headless
device cannot reconnect when the ssid returns, it is a bit useless. Isn't
connman supposed to do this? There are many things I like about connman but
this seems like a basic function that seems to be broken and I am surprised
that I find very little info on it on the internet. The attached log is on
my laptop. I restarted the SSID radio at 10:06 and at 10:20, I did a
'connmanctl scan wifi' when it reconnected. I find this strange as
connman1.38 does not return with a 'scan completed' message but it does
reconnect. I see this behavior on the RPis as well.
I am running connman 1.38 and iwd 1.9 and have tried current gits of both
and also get the same result.
Any help?
Keith
1:15 a.m.
On Sun, Sep 20, 2020 at 10:44:37AM -0500, KeithG wrote:
I'm still struggling with this and have done a lot of poking at
it and
posting Denis off list as well. This is what I 'think' I have learned.
BTW, you should refrain from posting off list questions if it doesn't
contain any secret information (or you were asked to send it privately).
I don't know what you figured out with Denis' help. Open source includes
open discussion.
1) iwd as standalone or with systemd-networkd/dhcpch or with
NetworkManager
on x64 or on RPIs, all running arch linux, works great at version 1.9. If
the SSID 'goes away' and 'comes back' the computer will reconnect. every
time.
2) NetworkManager works well with iwd and as best I can tell, it will
reconnect via its interaction with iwd.
3) When I run systemd-networkd/dhcpcd with iwd, it is more like it iwd
running standalone as I can edit the /var/lib/iwd/ssid.psk either manually
or through iwctl so that:
[Settings]
AutoConnect=true
In this setup, the computer reconnects at boot *and* when the SSID goes
away and comes back.
That means if iwd manages the reconnects all works well.
4) When connman manages iwd, though, I cannot edit the ssid.psk file
and
have it stick. Though it connects every time at boot, it will not reconnect
if the ssid goes away and returns.
This is because ConnMan is taking over the job of managing the
connections and actively disables the AutoConnect in iwd.
This is with the headless rpis with
their broadcom cards and with a laptop runnning a full Arch Linux desktop
with an intel wifi card. One other thing I notice is that when it has
disconnected (SSID off then on), the 'connmanctl services' list is
incomplete. It definitely does not show all the currently available ssids
broadcasting.
Check what the monitor-iwd scripts shows and compare it with the output
from 'connmand -n -d plugins/iwd.c'
If I type 'connmanctl scan wifi' it will complete a scan
*and* reconnect.
Likely the SSID was not seen by ConnMan and that's why it doesn't do a
reconnect. The scan will retrigger the machinery. The output from
monitor-iwd is again a good starting point to see what is missing
between the communication between ConnMan and iwd.
It is like connman gets stuck. and stops managing the wifi.
ConnMan is only reacting to events. If there is no event from iwd to
ConnMan nothing will happen. From your description I think there is
either a missing event or ConnMan ignores an event (would be a bit
surprising but well).
I also note that if the ethernet cable is plugged in on the RPIs then
the
device is connected to the wifi ap then the ethernet cable is removed that
all internet connectivity ceases.
Again ConnMan reacts to events. If the kernel doesn't send a netlink
message, nothing will happen. I would be surprised if ConnMan and the
the generic kernel code have a bug there. So I would look more closely
at what the driver is doing here first.
Both interfaces go down and will not
reconnect requiring a reboot. It is tough for me to really query this as I
see it on my headless rpis and when the connectivity goes away, I have to
reboot to get it back. It did not behave like this with netctl nor does it
behave like this with systemd-networkd.
As far as I know, systemd-networkd uses also udev as input. Maybe this
makes the difference.
Also, on the rpis, I have noticed that connman can get into a state
where
plugging in the ethernet cable results in nothing. connman will not bring
up the ethernet interface.
We have reworked a php interface from netctl tp work with connman for these
little rpi audio devices and I would love for it to work, but if a headless
device cannot reconnect when the ssid returns, it is a bit useless. Isn't
connman supposed to do this?
ConnMan should be able to this modulo bugs.
There are many things I like about connman but
this seems like a basic function that seems to be broken and I am surprised
that I find very little info on it on the internet.
I've tried your scenarios on my hardware and it works. Obviously,
different hardware/driver behave slightly differently and ConnMan might
choke on it.
So the question is why it works with systemd-networkd and not with
ConnMan.
6:59 a.m.
On Mon, Sep 21, 2020 at 3:15 AM Daniel Wagner <wagi(a)monom.org> wrote:
On Sun, Sep 20, 2020 at 10:44:37AM -0500, KeithG wrote:
> I'm still struggling with this and have done a lot of poking at it and
> posting Denis off list as well. This is what I 'think' I have learned.
BTW, you should refrain from posting off list questions if it doesn't
contain any secret information (or you were asked to send it privately).
I don't know what you figured out with Denis' help. Open source includes
open discussion.
> 1) iwd as standalone or with systemd-networkd/dhcpch or with
NetworkManager
> on x64 or on RPIs, all running arch linux, works great at version 1.9. If
> the SSID 'goes away' and 'comes back' the computer will reconnect.
every
> time.
> 2) NetworkManager works well with iwd and as best I can tell, it will
> reconnect via its interaction with iwd.
> 3) When I run systemd-networkd/dhcpcd with iwd, it is more like it iwd
> running standalone as I can edit the /var/lib/iwd/ssid.psk either
manually
> or through iwctl so that:
> [Settings]
> AutoConnect=true
> In this setup, the computer reconnects at boot *and* when the SSID goes
> away and comes back.
That means if iwd manages the reconnects all works well.
> 4) When connman manages iwd, though, I cannot edit the ssid.psk file and
> have it stick. Though it connects every time at boot, it will not
reconnect
> if the ssid goes away and returns.
This is because ConnMan is taking over the job of managing the
connections and actively disables the AutoConnect in iwd.
> This is with the headless rpis with
> their broadcom cards and with a laptop runnning a full Arch Linux desktop
> with an intel wifi card. One other thing I notice is that when it has
> disconnected (SSID off then on), the 'connmanctl services' list is
> incomplete. It definitely does not show all the currently available ssids
> broadcasting.
Check what the monitor-iwd scripts shows and compare it with the output
from 'connmand -n -d plugins/iwd.c'
> If I type 'connmanctl scan wifi' it will complete a scan
> *and* reconnect.
Likely the SSID was not seen by ConnMan and that's why it doesn't do a
reconnect. The scan will retrigger the machinery. The output from
monitor-iwd is again a good starting point to see what is missing
between the communication between ConnMan and iwd.
> It is like connman gets stuck. and stops managing the wifi.
ConnMan is only reacting to events. If there is no event from iwd to
ConnMan nothing will happen. From your description I think there is
either a missing event or ConnMan ignores an event (would be a bit
surprising but well).
> I also note that if the ethernet cable is plugged in on the RPIs then the
> device is connected to the wifi ap then the ethernet cable is removed
that
> all internet connectivity ceases.
Again ConnMan reacts to events. If the kernel doesn't send a netlink
message, nothing will happen. I would be surprised if ConnMan and the
the generic kernel code have a bug there. So I would look more closely
at what the driver is doing here first.
> Both interfaces go down and will not
> reconnect requiring a reboot. It is tough for me to really query this as
I
> see it on my headless rpis and when the connectivity goes away, I have to
> reboot to get it back. It did not behave like this with netctl nor does
it
> behave like this with systemd-networkd.
As far as I know, systemd-networkd uses also udev as input. Maybe this
makes the difference.
> Also, on the rpis, I have noticed that connman can get into a state where
> plugging in the ethernet cable results in nothing. connman will not bring
> up the ethernet interface.
>
> We have reworked a php interface from netctl tp work with connman for
these
> little rpi audio devices and I would love for it to work, but if a
headless
> device cannot reconnect when the ssid returns, it is a bit useless. Isn't
> connman supposed to do this?
ConnMan should be able to this modulo bugs.
> There are many things I like about connman but
> this seems like a basic function that seems to be broken and I am
surprised
> that I find very little info on it on the internet.
I've tried your scenarios on my hardware and it works. Obviously,
different hardware/driver behave slightly differently and ConnMan might
choke on it.
So the question is why it works with systemd-networkd and not with
ConnMan.
I cannot find the monitor-iwd script. I found the monitor-connman script,
but when I try to run the monitor-connman script, I get a gobject error:
$ ./monitor-connman
Traceback (most recent call last):
File "./monitor-connman", line 3, in <module>
import gobject
ModuleNotFoundError: No module named 'gobject'
This is even though I believe that python-gobject is installed and I can
run the hello.py script on this page:
https://pygobject.readthedocs.io/en/latest/getting_started.html
python 3.8.5 and
$ pacman -Q | grep gobject
gobject-introspection 1.66.0-1
gobject-introspection-runtime 1.66.0-1
pygobject-devel 3.36.1-1
python-gobject 3.36.1-1
I am now running on a pretty common dell laptop with an intel wifi card and
get the same behavior. iwd 1.9 connman 1.38. I connected via connman then
powered down the radio on the router then back on then had to reconnect by
typing in teh password. The journal of this event is attached.
I did notice that in order to reconnect on this laptop (Arch Linux x86_64)
that I had to type in the password again though I was just connected before
I turned off the SSID. The journal running /usr/bin/connmand -n -d
plugins/iwd.c:src/service.c though this event is attached.
5:08 p.m.
DAniel,
I am still trying to run the python scripts. I am on arch and finally
figured out I needed to do it this way:
"sudo pip install gobject pygobject" in additon to the pacman -Sy gobject
so Now I get a bit farther:
# ./monitor-connman
Traceback (most recent call last):
File "./monitor-connman", line 85, in <module>
mainloop = gobject.MainLoop()
AttributeError: module 'gobject' has no attribute 'MainLoop'
I am still at a loss as to how to get this running.
On Tue, Sep 22, 2020 at 8:59 AM KeithG <ys3al35l(a)gmail.com> wrote:
On Mon, Sep 21, 2020 at 3:15 AM Daniel Wagner <wagi(a)monom.org> wrote:
> On Sun, Sep 20, 2020 at 10:44:37AM -0500, KeithG wrote:
> > I'm still struggling with this and have done a lot of poking at it and
> > posting Denis off list as well. This is what I 'think' I have learned.
>
> BTW, you should refrain from posting off list questions if it doesn't
> contain any secret information (or you were asked to send it privately).
> I don't know what you figured out with Denis' help. Open source includes
> open discussion.
>
> > 1) iwd as standalone or with systemd-networkd/dhcpch or with
> NetworkManager
> > on x64 or on RPIs, all running arch linux, works great at version 1.9.
> If
> > the SSID 'goes away' and 'comes back' the computer will
reconnect. every
> > time.
> > 2) NetworkManager works well with iwd and as best I can tell, it will
> > reconnect via its interaction with iwd.
> > 3) When I run systemd-networkd/dhcpcd with iwd, it is more like it iwd
> > running standalone as I can edit the /var/lib/iwd/ssid.psk either
> manually
> > or through iwctl so that:
> > [Settings]
> > AutoConnect=true
> > In this setup, the computer reconnects at boot *and* when the SSID goes
> > away and comes back.
>
> That means if iwd manages the reconnects all works well.
>
> > 4) When connman manages iwd, though, I cannot edit the ssid.psk file and
> > have it stick. Though it connects every time at boot, it will not
> reconnect
> > if the ssid goes away and returns.
>
> This is because ConnMan is taking over the job of managing the
> connections and actively disables the AutoConnect in iwd.
>
> > This is with the headless rpis with
> > their broadcom cards and with a laptop runnning a full Arch Linux
> desktop
> > with an intel wifi card. One other thing I notice is that when it has
> > disconnected (SSID off then on), the 'connmanctl services' list is
> > incomplete. It definitely does not show all the currently available
> ssids
> > broadcasting.
>
> Check what the monitor-iwd scripts shows and compare it with the output
> from 'connmand -n -d plugins/iwd.c'
>
> > If I type 'connmanctl scan wifi' it will complete a scan
> > *and* reconnect.
>
> Likely the SSID was not seen by ConnMan and that's why it doesn't do a
> reconnect. The scan will retrigger the machinery. The output from
> monitor-iwd is again a good starting point to see what is missing
> between the communication between ConnMan and iwd.
>
> > It is like connman gets stuck. and stops managing the wifi.
>
> ConnMan is only reacting to events. If there is no event from iwd to
> ConnMan nothing will happen. From your description I think there is
> either a missing event or ConnMan ignores an event (would be a bit
> surprising but well).
>
> > I also note that if the ethernet cable is plugged in on the RPIs then
> the
> > device is connected to the wifi ap then the ethernet cable is removed
> that
> > all internet connectivity ceases.
>
> Again ConnMan reacts to events. If the kernel doesn't send a netlink
> message, nothing will happen. I would be surprised if ConnMan and the
> the generic kernel code have a bug there. So I would look more closely
> at what the driver is doing here first.
>
> > Both interfaces go down and will not
> > reconnect requiring a reboot. It is tough for me to really query this
> as I
> > see it on my headless rpis and when the connectivity goes away, I have
> to
> > reboot to get it back. It did not behave like this with netctl nor does
> it
> > behave like this with systemd-networkd.
>
> As far as I know, systemd-networkd uses also udev as input. Maybe this
> makes the difference.
>
> > Also, on the rpis, I have noticed that connman can get into a state
> where
> > plugging in the ethernet cable results in nothing. connman will not
> bring
> > up the ethernet interface.
> >
> > We have reworked a php interface from netctl tp work with connman for
> these
> > little rpi audio devices and I would love for it to work, but if a
> headless
> > device cannot reconnect when the ssid returns, it is a bit useless.
> Isn't
> > connman supposed to do this?
>
> ConnMan should be able to this modulo bugs.
>
> > There are many things I like about connman but
> > this seems like a basic function that seems to be broken and I am
> surprised
> > that I find very little info on it on the internet.
>
> I've tried your scenarios on my hardware and it works. Obviously,
> different hardware/driver behave slightly differently and ConnMan might
> choke on it.
>
> So the question is why it works with systemd-networkd and not with
> ConnMan.
>
I cannot find the monitor-iwd script. I found the monitor-connman script,
but when I try to run the monitor-connman script, I get a gobject error:
$ ./monitor-connman
Traceback (most recent call last):
File "./monitor-connman", line 3, in <module>
import gobject
ModuleNotFoundError: No module named 'gobject'
This is even though I believe that python-gobject is installed and I can
run the hello.py script on this page:
https://pygobject.readthedocs.io/en/latest/getting_started.html
python 3.8.5 and
$ pacman -Q | grep gobject
gobject-introspection 1.66.0-1
gobject-introspection-runtime 1.66.0-1
pygobject-devel 3.36.1-1
python-gobject 3.36.1-1
I am now running on a pretty common dell laptop with an intel wifi card
and get the same behavior. iwd 1.9 connman 1.38. I connected via connman
then powered down the radio on the router then back on then had to
reconnect by typing in teh password. The journal of this event is
attached.
I did notice that in order to reconnect on this laptop (Arch Linux x86_64)
that I had to type in the password again though I was just connected before
I turned off the SSID. The journal running /usr/bin/connmand -n -d
plugins/iwd.c:src/service.c though this event is attached.
12:17 a.m.
On Tue, Sep 22, 2020 at 08:59:57AM -0500, KeithG wrote:
I cannot find the monitor-iwd script.
This script is part of the iwd sources.
I found the monitor-connman script,
but when I try to run the monitor-connman script, I get a gobject error:
$ ./monitor-connman
Traceback (most recent call last):
File "./monitor-connman", line 3, in <module>
import gobject
ModuleNotFoundError: No module named 'gobject'
The Python support for GLib gobject was always a bit troublesome and it
seems it aged really badly.
This is even though I believe that python-gobject is installed and I
can
run the hello.py script on this page:
https://pygobject.readthedocs.io/en/latest/getting_started.html
python 3.8.5 and
$ pacman -Q | grep gobject
gobject-introspection 1.66.0-1
gobject-introspection-runtime 1.66.0-1
pygobject-devel 3.36.1-1
python-gobject 3.36.1-1
I have the same problem with Python 3 on my distro. It still works with
Python 2. The test script need to use the dynamic version of the GLib
binding. See the other patch.
I am now running on a pretty common dell laptop with an intel wifi
card and
get the same behavior. iwd 1.9 connman 1.38. I connected via connman then
powered down the radio on the router then back on then had to reconnect by
typing in teh password. The journal of this event is attached.
I did notice that in order to reconnect on this laptop (Arch Linux x86_64)
that I had to type in the password again though I was just connected before
I turned off the SSID. The journal running /usr/bin/connmand -n -d
plugins/iwd.c:src/service.c though this event is attached.
I'll try to reproduce it later.
Thanks,
Daniel
5:56 a.m.
Daniel,
I pulled the latest connman and was able to run monitor-connman. The
attached log is what I got when I:
1) stopped connman
2) started connman
3) turned off the radio
4) waited until my phone and other devices were online with that SSID
5) typed 'connmanctl scan wifi' got no return
6) typed ctrl c
7) typed 'connmanctl services'
I noted that after I initiated the scan even though connman reported
nothing, it had already begun the connection and connected. We have noticed
that if we type 'iwctl station wlan0 scan' or, apparently 'connmanctl scan
wifi' that it will initiate and complete a scan. I wonder if the fact that
connman 1.38 never returns with a scan complete message is a hint? The
monitor-connman.txt is what showed in the terminal when I ran the script.
The monitor-connman-journal.txt is what appeared in the journal for u-
connman. At the same time the journalctl -iwd shows this:
Sep 24 07:29:14 keith-dell iwd[405]: Received Deauthentication event,
reason: 3, from_ap: false
Sep 24 07:39:08 keith-dell iwd[405]: Received Deauthentication event,
reason: 3, from_ap: true
Sep 24 07:39:08 keith-dell iwd[405]: Connected BSS not in scan results
Sep 24 07:39:08 keith-dell iwd[405]: authentication timed out
Is there some sort of timing problem?
Keith
On Wed, Sep 23, 2020 at 2:18 AM Daniel Wagner <wagi(a)monom.org> wrote:
On Tue, Sep 22, 2020 at 08:59:57AM -0500, KeithG wrote:
> I cannot find the monitor-iwd script.
This script is part of the iwd sources.
> I found the monitor-connman script,
> but when I try to run the monitor-connman script, I get a gobject error:
>
> $ ./monitor-connman
> Traceback (most recent call last):
> File "./monitor-connman", line 3, in <module>
> import gobject
> ModuleNotFoundError: No module named 'gobject'
The Python support for GLib gobject was always a bit troublesome and it
seems it aged really badly.
> This is even though I believe that python-gobject is installed and I can
> run the hello.py script on this page:
> https://pygobject.readthedocs.io/en/latest/getting_started.html
> python 3.8.5 and
> $ pacman -Q | grep gobject
> gobject-introspection 1.66.0-1
> gobject-introspection-runtime 1.66.0-1
> pygobject-devel 3.36.1-1
> python-gobject 3.36.1-1
I have the same problem with Python 3 on my distro. It still works with
Python 2. The test script need to use the dynamic version of the GLib
binding. See the other patch.
> I am now running on a pretty common dell laptop with an intel wifi card
and
> get the same behavior. iwd 1.9 connman 1.38. I connected via connman then
> powered down the radio on the router then back on then had to reconnect
by
> typing in teh password. The journal of this event is attached.
>
> I did notice that in order to reconnect on this laptop (Arch Linux
x86_64)
> that I had to type in the password again though I was just connected
before
> I turned off the SSID. The journal running /usr/bin/connmand -n -d
> plugins/iwd.c:src/service.c though this event is attached.
I'll try to reproduce it later.
Thanks,
Daniel
6:24 p.m.
On Thu, Sep 24, 2020 at 7:56 AM KeithG <ys3al35l(a)gmail.com> wrote:
Daniel,
I pulled the latest connman and was able to run monitor-connman. The
attached log is what I got when I:
1) stopped connman
2) started connman
3) turned off the radio
4) waited until my phone and other devices were online with that SSID
5) typed 'connmanctl scan wifi' got no return
6) typed ctrl c
7) typed 'connmanctl services'
I noted that after I initiated the scan even though connman reported
nothing, it had already begun the connection and connected. We have noticed
that if we type 'iwctl station wlan0 scan' or, apparently 'connmanctl scan
wifi' that it will initiate and complete a scan. I wonder if the fact that
connman 1.38 never returns with a scan complete message is a hint? The
monitor-connman.txt is what showed in the terminal when I ran the script.
The monitor-connman-journal.txt is what appeared in the journal for u-
connman. At the same time the journalctl -iwd shows this:
Sep 24 07:29:14 keith-dell iwd[405]: Received Deauthentication event,
reason: 3, from_ap: false
Sep 24 07:39:08 keith-dell iwd[405]: Received Deauthentication event,
reason: 3, from_ap: true
Sep 24 07:39:08 keith-dell iwd[405]: Connected BSS not in scan results
Sep 24 07:39:08 keith-dell iwd[405]: authentication timed out
Is there some sort of timing problem?
Keith
On Wed, Sep 23, 2020 at 2:18 AM Daniel Wagner <wagi(a)monom.org> wrote:
> On Tue, Sep 22, 2020 at 08:59:57AM -0500, KeithG wrote:
> > I cannot find the monitor-iwd script.
>
> This script is part of the iwd sources.
>
> > I found the monitor-connman script,
> > but when I try to run the monitor-connman script, I get a gobject error:
> >
> > $ ./monitor-connman
> > Traceback (most recent call last):
> > File "./monitor-connman", line 3, in <module>
> > import gobject
> > ModuleNotFoundError: No module named 'gobject'
>
> The Python support for GLib gobject was always a bit troublesome and it
> seems it aged really badly.
>
> > This is even though I believe that python-gobject is installed and I can
> > run the hello.py script on this page:
> > https://pygobject.readthedocs.io/en/latest/getting_started.html
> > python 3.8.5 and
> > $ pacman -Q | grep gobject
> > gobject-introspection 1.66.0-1
> > gobject-introspection-runtime 1.66.0-1
> > pygobject-devel 3.36.1-1
> > python-gobject 3.36.1-1
>
> I have the same problem with Python 3 on my distro. It still works with
> Python 2. The test script need to use the dynamic version of the GLib
> binding. See the other patch.
>
> > I am now running on a pretty common dell laptop with an intel wifi card
> and
> > get the same behavior. iwd 1.9 connman 1.38. I connected via connman
> then
> > powered down the radio on the router then back on then had to reconnect
> by
> > typing in teh password. The journal of this event is attached.
> >
> > I did notice that in order to reconnect on this laptop (Arch Linux
> x86_64)
> > that I had to type in the password again though I was just connected
> before
> > I turned off the SSID. The journal running /usr/bin/connmand -n -d
> > plugins/iwd.c:src/service.c though this event is attached.
>
> I'll try to reproduce it later.
>
> Thanks,
> Daniel
>
I see this with all my Arch Linux installs. I made a basic install on an
RPi with nothing but the base system and connman and iwd and a few other
programs. When I use connman to manage the wifi interface and run
./monitor-iwd, nothing ever displays even when the wifi goes down. I'd show
the tect capture, but it is blank. When I run systemd-networks/dhcpcd with
iwd, and have the network go down, I get a lot of messages and it
reconnects when the radio comes back online:
# ./monitor-iwd
{Station} [/net/connman/iwd/0/3] State = disconnected
{Network} [/net/connman/iwd/0/3/73706733_psk] Connected = False
{Station} [/net/connman/iwd/0/3] Scanning = True
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/52756e65417564696f4150_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/4154546a435336706932_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/4e4554474541525f455854_open]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/456476656e7475726573_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/4e4554474541523938_psk]
{Removed net.connman.iwd.Network} [/net/connman/iwd/0/3/73706733_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/4d65617374657761_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/456476656e747572657333_psk]
{Removed net.connman.iwd.Network} [/net/connman/iwd/0/3/73706732_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/415454785a4951347761_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/486f757365537461726b3031_psk]
{Removed net.connman.iwd.Network} [/net/connman/iwd/0/3/456c4a656665_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/426964656e486172726973_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/4d4f544f524f4c412d4645304431_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/415454654865544b4932_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/4e4554474541523633_psk]
{Removed net.connman.iwd.Network} [/net/connman/iwd/0/3/48414e4e41_psk]
{Station} [/net/connman/iwd/0/3] Scanning = False
{Station} [/net/connman/iwd/0/3] Scanning = True
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/52756e65417564696f4150_psk]
Name = RuneAudioAP
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network} [/net/connman/iwd/0/3/48414e4e41_psk]
Name = HANNA
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network} [/net/connman/iwd/0/3/456c4a656665_psk]
Name = ElJefe
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/486f757365537461726b3031_psk]
Name = HouseStark01
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/4e4554474541523633_psk]
Name = NETGEAR63
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/456476656e7475726573_psk]
Name = Edventures
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/4e4554474541523938_psk]
Name = NETGEAR98
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/415454654865544b4932_psk]
Name = ATTeHeTKI2
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/4974204275726e73205768656e204950_psk]
Name = It Burns When IP
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network} [/net/connman/iwd/0/3/48414e4e4135_psk]
Name = HANNA5
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/456476656e747572657333_psk]
Name = Edventures3
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Station} [/net/connman/iwd/0/3] Scanning = False
{Station} [/net/connman/iwd/0/3] Scanning = True
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/426964656e486172726973_psk]
Name = BidenHarris
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Station} [/net/connman/iwd/0/3] Scanning = False
{Station} [/net/connman/iwd/0/3] Scanning = True
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/415454785a4951347761_psk]
Name = ATTxZIQ4wa
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/4d4f544f524f4c412d4645304431_psk]
Name = MOTOROLA-FE0D1
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/4e4554474541525f455854_open]
Name = NETGEAR_EXT
Connected = False
Device = /net/connman/iwd/0/3
Type = open
{Station} [/net/connman/iwd/0/3] Scanning = False
{Station} [/net/connman/iwd/0/3] Scanning = True
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/4e4554474541525f455854_open]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/4d4f544f524f4c412d4645304431_psk]
{Removed net.connman.iwd.Network} [/net/connman/iwd/0/3/48414e4e4135_psk]
{Added net.connman.iwd.Network} [/net/connman/iwd/0/3/73706733_psk]
Name = spg3
Connected = True
Device = /net/connman/iwd/0/3
Type = psk
KnownNetwork = /net/connman/iwd/73706733_psk
{Added net.connman.iwd.Network} [/net/connman/iwd/0/3/73706732_psk]
Name = spg2
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/4e4554474541523336_psk]
Name = NETGEAR36
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Station} [/net/connman/iwd/0/3] Scanning = False
{Station} [/net/connman/iwd/0/3] State = connecting
{Station} [/net/connman/iwd/0/3] ConnectedNetwork =
/net/connman/iwd/0/3/73706733_psk
{Network} [/net/connman/iwd/0/3/73706733_psk] Connected = True
{Station} [/net/connman/iwd/0/3] State = connected
{KnownNetwork} [/net/connman/iwd/73706733_psk] LastConnectedTime =
2020-09-28T01:10:45Z
The attached journal shows this for downing the radio when connman was
controlling the network. It ignores it. My guess is there is some strange
setting in Arch Linux which stops this from working when connman is
managing things. What more can I do to help? I see this same behavior on my
arm devices (RPis) and x86_64 full desktop installs.
Keith
3:43 a.m.
On Sun, Sep 27, 2020 at 8:24 PM KeithG <ys3al35l(a)gmail.com> wrote:
On Thu, Sep 24, 2020 at 7:56 AM KeithG <ys3al35l(a)gmail.com> wrote:
> Daniel,
>
> I pulled the latest connman and was able to run monitor-connman. The
> attached log is what I got when I:
> 1) stopped connman
> 2) started connman
> 3) turned off the radio
> 4) waited until my phone and other devices were online with that SSID
> 5) typed 'connmanctl scan wifi' got no return
> 6) typed ctrl c
> 7) typed 'connmanctl services'
>
> I noted that after I initiated the scan even though connman reported
> nothing, it had already begun the connection and connected. We have noticed
> that if we type 'iwctl station wlan0 scan' or, apparently 'connmanctl
scan
> wifi' that it will initiate and complete a scan. I wonder if the fact that
> connman 1.38 never returns with a scan complete message is a hint? The
> monitor-connman.txt is what showed in the terminal when I ran the script.
> The monitor-connman-journal.txt is what appeared in the journal for u-
> connman. At the same time the journalctl -iwd shows this:
>
> Sep 24 07:29:14 keith-dell iwd[405]: Received Deauthentication event,
> reason: 3, from_ap: false
> Sep 24 07:39:08 keith-dell iwd[405]: Received Deauthentication event,
> reason: 3, from_ap: true
> Sep 24 07:39:08 keith-dell iwd[405]: Connected BSS not in scan results
> Sep 24 07:39:08 keith-dell iwd[405]: authentication timed out
>
> Is there some sort of timing problem?
>
> Keith
>
> On Wed, Sep 23, 2020 at 2:18 AM Daniel Wagner <wagi(a)monom.org> wrote:
>
>> On Tue, Sep 22, 2020 at 08:59:57AM -0500, KeithG wrote:
>> > I cannot find the monitor-iwd script.
>>
>> This script is part of the iwd sources.
>>
>> > I found the monitor-connman script,
>> > but when I try to run the monitor-connman script, I get a gobject
>> error:
>> >
>> > $ ./monitor-connman
>> > Traceback (most recent call last):
>> > File "./monitor-connman", line 3, in <module>
>> > import gobject
>> > ModuleNotFoundError: No module named 'gobject'
>>
>> The Python support for GLib gobject was always a bit troublesome and it
>> seems it aged really badly.
>>
>> > This is even though I believe that python-gobject is installed and I
>> can
>> > run the hello.py script on this page:
>> > https://pygobject.readthedocs.io/en/latest/getting_started.html
>> > python 3.8.5 and
>> > $ pacman -Q | grep gobject
>> > gobject-introspection 1.66.0-1
>> > gobject-introspection-runtime 1.66.0-1
>> > pygobject-devel 3.36.1-1
>> > python-gobject 3.36.1-1
>>
>> I have the same problem with Python 3 on my distro. It still works with
>> Python 2. The test script need to use the dynamic version of the GLib
>> binding. See the other patch.
>>
>> > I am now running on a pretty common dell laptop with an intel wifi
>> card and
>> > get the same behavior. iwd 1.9 connman 1.38. I connected via connman
>> then
>> > powered down the radio on the router then back on then had to
>> reconnect by
>> > typing in teh password. The journal of this event is attached.
>> >
>> > I did notice that in order to reconnect on this laptop (Arch Linux
>> x86_64)
>> > that I had to type in the password again though I was just connected
>> before
>> > I turned off the SSID. The journal running /usr/bin/connmand -n -d
>> > plugins/iwd.c:src/service.c though this event is attached.
>>
>> I'll try to reproduce it later.
>>
>> Thanks,
>> Daniel
>>
>
I see this with all my Arch Linux installs. I made a basic install on an
RPi with nothing but the base system and connman and iwd and a few other
programs. When I use connman to manage the wifi interface and run
./monitor-iwd, nothing ever displays even when the wifi goes down. I'd show
the tect capture, but it is blank. When I run systemd-networks/dhcpcd with
iwd, and have the network go down, I get a lot of messages and it
reconnects when the radio comes back online:
# ./monitor-iwd
{Station} [/net/connman/iwd/0/3] State = disconnected
{Network} [/net/connman/iwd/0/3/73706733_psk] Connected = False
{Station} [/net/connman/iwd/0/3] Scanning = True
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/52756e65417564696f4150_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/4154546a435336706932_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/4e4554474541525f455854_open]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/456476656e7475726573_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/4e4554474541523938_psk]
{Removed net.connman.iwd.Network} [/net/connman/iwd/0/3/73706733_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/4d65617374657761_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/456476656e747572657333_psk]
{Removed net.connman.iwd.Network} [/net/connman/iwd/0/3/73706732_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/415454785a4951347761_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/486f757365537461726b3031_psk]
{Removed net.connman.iwd.Network} [/net/connman/iwd/0/3/456c4a656665_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/426964656e486172726973_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/4d4f544f524f4c412d4645304431_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/415454654865544b4932_psk]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/4e4554474541523633_psk]
{Removed net.connman.iwd.Network} [/net/connman/iwd/0/3/48414e4e41_psk]
{Station} [/net/connman/iwd/0/3] Scanning = False
{Station} [/net/connman/iwd/0/3] Scanning = True
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/52756e65417564696f4150_psk]
Name = RuneAudioAP
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network} [/net/connman/iwd/0/3/48414e4e41_psk]
Name = HANNA
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network} [/net/connman/iwd/0/3/456c4a656665_psk]
Name = ElJefe
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/486f757365537461726b3031_psk]
Name = HouseStark01
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/4e4554474541523633_psk]
Name = NETGEAR63
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/456476656e7475726573_psk]
Name = Edventures
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/4e4554474541523938_psk]
Name = NETGEAR98
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/415454654865544b4932_psk]
Name = ATTeHeTKI2
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/4974204275726e73205768656e204950_psk]
Name = It Burns When IP
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network} [/net/connman/iwd/0/3/48414e4e4135_psk]
Name = HANNA5
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/456476656e747572657333_psk]
Name = Edventures3
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Station} [/net/connman/iwd/0/3] Scanning = False
{Station} [/net/connman/iwd/0/3] Scanning = True
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/426964656e486172726973_psk]
Name = BidenHarris
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Station} [/net/connman/iwd/0/3] Scanning = False
{Station} [/net/connman/iwd/0/3] Scanning = True
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/415454785a4951347761_psk]
Name = ATTxZIQ4wa
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/4d4f544f524f4c412d4645304431_psk]
Name = MOTOROLA-FE0D1
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/4e4554474541525f455854_open]
Name = NETGEAR_EXT
Connected = False
Device = /net/connman/iwd/0/3
Type = open
{Station} [/net/connman/iwd/0/3] Scanning = False
{Station} [/net/connman/iwd/0/3] Scanning = True
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/4e4554474541525f455854_open]
{Removed net.connman.iwd.Network}
[/net/connman/iwd/0/3/4d4f544f524f4c412d4645304431_psk]
{Removed net.connman.iwd.Network} [/net/connman/iwd/0/3/48414e4e4135_psk]
{Added net.connman.iwd.Network} [/net/connman/iwd/0/3/73706733_psk]
Name = spg3
Connected = True
Device = /net/connman/iwd/0/3
Type = psk
KnownNetwork = /net/connman/iwd/73706733_psk
{Added net.connman.iwd.Network} [/net/connman/iwd/0/3/73706732_psk]
Name = spg2
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Added net.connman.iwd.Network}
[/net/connman/iwd/0/3/4e4554474541523336_psk]
Name = NETGEAR36
Connected = False
Device = /net/connman/iwd/0/3
Type = psk
{Station} [/net/connman/iwd/0/3] Scanning = False
{Station} [/net/connman/iwd/0/3] State = connecting
{Station} [/net/connman/iwd/0/3] ConnectedNetwork =
/net/connman/iwd/0/3/73706733_psk
{Network} [/net/connman/iwd/0/3/73706733_psk] Connected = True
{Station} [/net/connman/iwd/0/3] State = connected
{KnownNetwork} [/net/connman/iwd/73706733_psk] LastConnectedTime =
2020-09-28T01:10:45Z
The attached journal shows this for downing the radio when connman was
controlling the network. It ignores it. My guess is there is some strange
setting in Arch Linux which stops this from working when connman is
managing things. What more can I do to help? I see this same behavior on my
arm devices (RPis) and x86_64 full desktop installs.
Keith
Daniel,
I woke up this morning and I think I get it now. I need to run monitor-iwd
when I run networkd/dhcpcd and monitor-connman when connman is managing the
connections. Well, with the same process, this is the report from
monitor-connman when connman is managing the interface (I am monitoring it
over ssh by logging into the ethernet IP address):
# ./monitor-connman
{Service} [/net/connman/service/wifi_b827eb52ccd0_73706732_managed_psk]
Strength = 62
{Service}
[/net/connman/service/wifi_b827eb52ccd0_52756e65417564696f4150_managed_psk]
Strength = 56
{Service}
[/net/connman/service/wifi_b827eb52ccd0_415454785a4951347761_managed_psk]
Strength = 22
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523938_managed_psk]
Strength = 21
{Service}
[/net/connman/service/wifi_b827eb52ccd0_44617272656e333231_managed_psk]
Strength = 15
{Service}
[/net/connman/service/wifi_b827eb52ccd0_464249205375727665696c6c616e63652056616e_managed_psk]
Strength = 15
{Service}
[/net/connman/service/wifi_b827eb52ccd0_52756e65417564696f4150_managed_psk]
Strength = 55
{Service}
[/net/connman/service/wifi_b827eb52ccd0_41545458495849537069_managed_psk]
Strength = 34
{Service}
[/net/connman/service/wifi_b827eb52ccd0_486f757365537461726b3031_managed_psk]
Strength = 19
{Service} [/net/connman/service/wifi_b827eb52ccd0_456c4a656665_managed_psk]
Strength = 19
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4154546a435336706932_managed_psk]
Strength = 19
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523938_managed_psk]
Strength = 19
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523633_managed_psk]
Strength = 20
{Service}
[/net/connman/service/wifi_b827eb52ccd0_456476656e747572657333_managed_psk]
Strength = 19
{Service}
[/net/connman/service/wifi_b827eb52ccd0_44617272656e333231_managed_psk]
Strength = 18
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523336_managed_psk]
Strength = 15
*{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
State = association{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] State =
configuration{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Ethernet = {
Method=auto Interface=wlan0 Address=B8:27:EB:52:CC:D0 MTU=1500 }{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Ethernet = {
Method=auto Interface=wlan0 Address=B8:27:EB:52:CC:D0 MTU=1500 }{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Timeservers =
[ ]{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
State = ready{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Favorite =
1{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
Domains = [ ]{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Proxy = {
}{Technology} [/net/connman/technology/wifi] Connected = 1*
*{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
IPv6 = { Method=auto Address=2600:1700:4320:6caf:ba27:ebff:fe52:ccd0
PrefixLength=64 Privacy=disabled }{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Domains = [
griders ]{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Timeservers =
[ ]{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
IPv4 = { Method=dhcp Address=192.168.2.41 Netmask=255.255.255.0 }{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Nameservers =
[ 192.168.2.3 xxxx:xxxx:xxxx:xxxx:ba27:ebff:fe0b:9be6 ]{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Domains = [
]{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
Timeservers = [ ]{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Timeservers =
[ ]{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
State = disconnect{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Domains = [
]{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
Proxy = { }{Technology} [/net/connman/technology/wifi] Connected = 0*
*{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
Timeservers = [ ]{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Timeservers =
[ ]{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
State = idle{Service} [/net/connman/service/ethernet_b827eb079985_cable]
IPv4 = { Method=dhcp Address=192.168.2.193 Netmask=255.255.255.0 }{Service}
[/net/connman/service/ethernet_b827eb079985_cable] IPv4 = { Method=dhcp
Address=192.168.2.193 Netmask=255.255.255.0 Gateway=192.168.2.1 }{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Nameservers =
[ ]*
{Service}
[/net/connman/service/wifi_b827eb52ccd0_41545458495849537069_managed_psk]
Strength = 15
{Service}
[/net/connman/service/wifi_b827eb52ccd0_41545458495849537069_managed_psk]
Strength = 33
{Service}
[/net/connman/service/wifi_b827eb52ccd0_41545458495849537069_managed_psk]
Strength = 37
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523938_managed_psk]
Strength = 25
{Service} [/net/connman/service/wifi_b827eb52ccd0_456c4a656665_managed_psk]
Strength = 22
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523633_managed_psk]
Strength = 24
{Service} [/net/connman/service/wifi_b827eb52ccd0_48414e4e41_managed_psk]
Strength = 19
{Service}
[/net/connman/service/wifi_b827eb52ccd0_415454654865544b4932_managed_psk]
Strength = 15
{Service}
[/net/connman/service/wifi_b827eb52ccd0_464249205375727665696c6c616e63652056616e_managed_psk]
Strength = 17
{Service}
[/net/connman/service/wifi_b827eb52ccd0_41545458495849537069_managed_psk]
Strength = 33
{Service}
[/net/connman/service/wifi_b827eb52ccd0_456476656e7475726573_managed_psk]
Strength = 29
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523633_managed_psk]
Strength = 21
{Service} [/net/connman/service/wifi_b827eb52ccd0_456c4a656665_managed_psk]
Strength = 20
{Service} [/net/connman/service/wifi_b827eb52ccd0_48414e4e41_managed_psk]
Strength = 17
{Service}
[/net/connman/service/wifi_b827eb52ccd0_426964656e486172726973_managed_psk]
Strength = 17
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523336_managed_psk]
Strength = 17
{Service}
[/net/connman/service/wifi_b827eb52ccd0_415454654865544b4932_managed_psk]
Strength = 19
{Service}
[/net/connman/service/wifi_b827eb52ccd0_415454785a4951347761_managed_psk]
Strength = 19
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4154546a435336706932_managed_psk]
Strength = 16
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523938_managed_psk]
Strength = 18
{Service}
[/net/connman/service/wifi_b827eb52ccd0_456476656e747572657333_managed_psk]
Strength = 16
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4d65617374657761_managed_psk]
Strength = 16
{Service}
[/net/connman/service/wifi_b827eb52ccd0_464249205375727665696c6c616e63652056616e_managed_psk]
Strength = 16
{Service}
[/net/connman/service/wifi_b827eb52ccd0_41545458495849537069_managed_psk]
Strength = 36
{Service}
[/net/connman/service/wifi_b827eb52ccd0_456476656e7475726573_managed_psk]
Strength = 30
{Service} [/net/connman/service/wifi_b827eb52ccd0_48414e4e41_managed_psk]
Strength = 20
{Service}
[/net/connman/service/wifi_b827eb52ccd0_415454785a4951347761_managed_psk]
Strength = 23
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523633_managed_psk]
Strength = 19
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4154546a435336706932_managed_psk]
Strength = 18
{Service}
[/net/connman/service/wifi_b827eb52ccd0_456476656e747572657333_managed_psk]
Strength = 19
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523336_managed_psk]
Strength = 15
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523938_managed_psk]
Strength = 17
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4d65617374657761_managed_psk]
Strength = 15
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541525f455854_managed_none]
Strength = 13
*{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
Strength = 44*
{Service} [/net/connman/service/wifi_b827eb52ccd0_73706732_managed_psk]
Strength = 59
{Service}
[/net/connman/service/wifi_b827eb52ccd0_41545458495849537069_managed_psk]
Strength = 37
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523633_managed_psk]
Strength = 21
{Service}
[/net/connman/service/wifi_b827eb52ccd0_456476656e747572657333_managed_psk]
Strength = 20
{Service}
[/net/connman/service/wifi_b827eb52ccd0_464249205375727665696c6c616e63652056616e_managed_psk]
Strength = 17
(while typing this I notice that it scanned again, sees the SSID, but does
not initiate a connection...
I can see in the log when I use the connmanctl interface to connect to the
SSID then I can see it disconnect, then that it scans and 'sees' it again,
but it never re-connects even after it scans again. Looking at the
difference between the monitor-* logs, it looks like connman, somehow does
not recognize that it knows that network.
When I query connman, it looks like it is supposed to autoconnect:
connmanctl> services --properties wifi_b827eb52ccd0_73706733_managed_psk
/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk
Type = wifi
Security = [ psk ]
State = idle
Strength = 45
Favorite = True
Immutable = False
*AutoConnect = True*
Name = spg3
Ethernet = [ Method=auto ]
IPv4 = [ ]
IPv4.Configuration = [ Method=dhcp ]
IPv6 = [ ]
IPv6.Configuration = [ Method=auto, Privacy=disabled ]
Nameservers = [ ]
Nameservers.Configuration = [ ]
Timeservers = [ ]
Timeservers.Configuration = [ ]
Domains = [ ]
Domains.Configuration = [ ]
Proxy = [ ]
Proxy.Configuration = [ ]
mDNS = False
mDNS.Configuration = False
Provider = [ ]
The system:
Arch Linux aarch64 on an RPi, kernel 5.4.65-1-ARCH, iwd 1.9-1, connman
1.38-1
systemd 246.6-1-arch running in system mode. (+PAM +AUDIT -SELINUX -IMA
-APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ
+LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2
default-hierarchy=hybrid)
I get the same response on all Arch Linux systems: armv6 armv7 and x86_64.
Also, if I reboot with nothing connected to the ethernet port, it will
connect to the wifi SSID, but only at boot. If I connect the ethernet cable
then ssh into it and type 'connmanctl scan wifi', the prompt does not
return though the journalctl log shows that it did scan and that it did
'see' the SSID but it will not connect.
Sep 28 10:28:09 gretarune connmand[211]: plugins/iwd.c:object_added()
net.connman.iwd.Network /net/connman/iwd/0/3/73706733_psk
Sep 28 10:28:05 gretarune connmand[211]:
plugins/iwd.c:station_property_change() /net/connman/iwd/0/3 scanning 1
If I restart connman it does reconnect to the SSID (systemctl restart
connman). I tried adding imd.service to the After= line in the
connman.service file and that made no change to the behavior.
My connman.service file:
[Unit]
Description=Connection service
DefaultDependencies=false
Conflicts=shutdown.target
RequiresMountsFor=/var/lib/connman
After=dbus.service network-pre.target systemd-sysusers.service
Before=network.target multi-user.target shutdown.target
Wants=network.target
[Service]
Type=dbus
BusName=net.connman
Restart=on-failure
ExecStart=/usr/bin/connmand -n -d plugins/iwd.c
StandardOutput=null
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW
CAP_SYS_TIME CAP_SYS_MODULE CAP_SYS_ADMIN
ProtectHome=true
ProtectSystem=true
[Install]
WantedBy=multi-user.target
Thanks for any help.
Keith
2:19 p.m.
On Mon, Sep 28, 2020 at 5:43 AM KeithG <ys3al35l(a)gmail.com> wrote:
On Sun, Sep 27, 2020 at 8:24 PM KeithG <ys3al35l(a)gmail.com> wrote:
>
>
> On Thu, Sep 24, 2020 at 7:56 AM KeithG <ys3al35l(a)gmail.com> wrote:
>
>> Daniel,
>>
>> I pulled the latest connman and was able to run monitor-connman. The
>> attached log is what I got when I:
>> 1) stopped connman
>> 2) started connman
>> 3) turned off the radio
>> 4) waited until my phone and other devices were online with that SSID
>> 5) typed 'connmanctl scan wifi' got no return
>> 6) typed ctrl c
>> 7) typed 'connmanctl services'
>>
>> I noted that after I initiated the scan even though connman reported
>> nothing, it had already begun the connection and connected. We have noticed
>> that if we type 'iwctl station wlan0 scan' or, apparently 'connmanctl
scan
>> wifi' that it will initiate and complete a scan. I wonder if the fact that
>> connman 1.38 never returns with a scan complete message is a hint? The
>> monitor-connman.txt is what showed in the terminal when I ran the script.
>> The monitor-connman-journal.txt is what appeared in the journal for u-
>> connman. At the same time the journalctl -iwd shows this:
>>
>> Sep 24 07:29:14 keith-dell iwd[405]: Received Deauthentication event,
>> reason: 3, from_ap: false
>> Sep 24 07:39:08 keith-dell iwd[405]: Received Deauthentication event,
>> reason: 3, from_ap: true
>> Sep 24 07:39:08 keith-dell iwd[405]: Connected BSS not in scan results
>> Sep 24 07:39:08 keith-dell iwd[405]: authentication timed out
>>
>> Is there some sort of timing problem?
>>
>> Keith
>>
>> On Wed, Sep 23, 2020 at 2:18 AM Daniel Wagner <wagi(a)monom.org> wrote:
>>
>>> On Tue, Sep 22, 2020 at 08:59:57AM -0500, KeithG wrote:
>>> > I cannot find the monitor-iwd script.
>>>
>>> This script is part of the iwd sources.
>>>
>>> > I found the monitor-connman script,
>>> > but when I try to run the monitor-connman script, I get a gobject
>>> error:
>>> >
>>> > $ ./monitor-connman
>>> > Traceback (most recent call last):
>>> > File "./monitor-connman", line 3, in <module>
>>> > import gobject
>>> > ModuleNotFoundError: No module named 'gobject'
>>>
>>> The Python support for GLib gobject was always a bit troublesome and it
>>> seems it aged really badly.
>>>
>>> > This is even though I believe that python-gobject is installed and I
>>> can
>>> > run the hello.py script on this page:
>>> > https://pygobject.readthedocs.io/en/latest/getting_started.html
>>> > python 3.8.5 and
>>> > $ pacman -Q | grep gobject
>>> > gobject-introspection 1.66.0-1
>>> > gobject-introspection-runtime 1.66.0-1
>>> > pygobject-devel 3.36.1-1
>>> > python-gobject 3.36.1-1
>>>
>>> I have the same problem with Python 3 on my distro. It still works with
>>> Python 2. The test script need to use the dynamic version of the GLib
>>> binding. See the other patch.
>>>
>>> > I am now running on a pretty common dell laptop with an intel wifi
>>> card and
>>> > get the same behavior. iwd 1.9 connman 1.38. I connected via connman
>>> then
>>> > powered down the radio on the router then back on then had to
>>> reconnect by
>>> > typing in teh password. The journal of this event is attached.
>>> >
>>> > I did notice that in order to reconnect on this laptop (Arch Linux
>>> x86_64)
>>> > that I had to type in the password again though I was just connected
>>> before
>>> > I turned off the SSID. The journal running /usr/bin/connmand -n -d
>>> > plugins/iwd.c:src/service.c though this event is attached.
>>>
>>> I'll try to reproduce it later.
>>>
>>> Thanks,
>>> Daniel
>>>
>>
> I see this with all my Arch Linux installs. I made a basic install on an
> RPi with nothing but the base system and connman and iwd and a few other
> programs. When I use connman to manage the wifi interface and run
> ./monitor-iwd, nothing ever displays even when the wifi goes down. I'd show
> the tect capture, but it is blank. When I run systemd-networks/dhcpcd with
> iwd, and have the network go down, I get a lot of messages and it
> reconnects when the radio comes back online:
> # ./monitor-iwd
> {Station} [/net/connman/iwd/0/3] State = disconnected
> {Network} [/net/connman/iwd/0/3/73706733_psk] Connected = False
> {Station} [/net/connman/iwd/0/3] Scanning = True
> {Removed net.connman.iwd.Network}
> [/net/connman/iwd/0/3/52756e65417564696f4150_psk]
> {Removed net.connman.iwd.Network}
> [/net/connman/iwd/0/3/4154546a435336706932_psk]
> {Removed net.connman.iwd.Network}
> [/net/connman/iwd/0/3/4e4554474541525f455854_open]
> {Removed net.connman.iwd.Network}
> [/net/connman/iwd/0/3/456476656e7475726573_psk]
> {Removed net.connman.iwd.Network}
> [/net/connman/iwd/0/3/4e4554474541523938_psk]
> {Removed net.connman.iwd.Network} [/net/connman/iwd/0/3/73706733_psk]
> {Removed net.connman.iwd.Network}
> [/net/connman/iwd/0/3/4d65617374657761_psk]
> {Removed net.connman.iwd.Network}
> [/net/connman/iwd/0/3/456476656e747572657333_psk]
> {Removed net.connman.iwd.Network} [/net/connman/iwd/0/3/73706732_psk]
> {Removed net.connman.iwd.Network}
> [/net/connman/iwd/0/3/415454785a4951347761_psk]
> {Removed net.connman.iwd.Network}
> [/net/connman/iwd/0/3/486f757365537461726b3031_psk]
> {Removed net.connman.iwd.Network} [/net/connman/iwd/0/3/456c4a656665_psk]
> {Removed net.connman.iwd.Network}
> [/net/connman/iwd/0/3/426964656e486172726973_psk]
> {Removed net.connman.iwd.Network}
> [/net/connman/iwd/0/3/4d4f544f524f4c412d4645304431_psk]
> {Removed net.connman.iwd.Network}
> [/net/connman/iwd/0/3/415454654865544b4932_psk]
> {Removed net.connman.iwd.Network}
> [/net/connman/iwd/0/3/4e4554474541523633_psk]
> {Removed net.connman.iwd.Network} [/net/connman/iwd/0/3/48414e4e41_psk]
> {Station} [/net/connman/iwd/0/3] Scanning = False
> {Station} [/net/connman/iwd/0/3] Scanning = True
> {Added net.connman.iwd.Network}
> [/net/connman/iwd/0/3/52756e65417564696f4150_psk]
> Name = RuneAudioAP
> Connected = False
> Device = /net/connman/iwd/0/3
> Type = psk
> {Added net.connman.iwd.Network} [/net/connman/iwd/0/3/48414e4e41_psk]
> Name = HANNA
> Connected = False
> Device = /net/connman/iwd/0/3
> Type = psk
> {Added net.connman.iwd.Network} [/net/connman/iwd/0/3/456c4a656665_psk]
> Name = ElJefe
> Connected = False
> Device = /net/connman/iwd/0/3
> Type = psk
> {Added net.connman.iwd.Network}
> [/net/connman/iwd/0/3/486f757365537461726b3031_psk]
> Name = HouseStark01
> Connected = False
> Device = /net/connman/iwd/0/3
> Type = psk
> {Added net.connman.iwd.Network}
> [/net/connman/iwd/0/3/4e4554474541523633_psk]
> Name = NETGEAR63
> Connected = False
> Device = /net/connman/iwd/0/3
> Type = psk
> {Added net.connman.iwd.Network}
> [/net/connman/iwd/0/3/456476656e7475726573_psk]
> Name = Edventures
> Connected = False
> Device = /net/connman/iwd/0/3
> Type = psk
> {Added net.connman.iwd.Network}
> [/net/connman/iwd/0/3/4e4554474541523938_psk]
> Name = NETGEAR98
> Connected = False
> Device = /net/connman/iwd/0/3
> Type = psk
> {Added net.connman.iwd.Network}
> [/net/connman/iwd/0/3/415454654865544b4932_psk]
> Name = ATTeHeTKI2
> Connected = False
> Device = /net/connman/iwd/0/3
> Type = psk
> {Added net.connman.iwd.Network}
> [/net/connman/iwd/0/3/4974204275726e73205768656e204950_psk]
> Name = It Burns When IP
> Connected = False
> Device = /net/connman/iwd/0/3
> Type = psk
> {Added net.connman.iwd.Network} [/net/connman/iwd/0/3/48414e4e4135_psk]
> Name = HANNA5
> Connected = False
> Device = /net/connman/iwd/0/3
> Type = psk
> {Added net.connman.iwd.Network}
> [/net/connman/iwd/0/3/456476656e747572657333_psk]
> Name = Edventures3
> Connected = False
> Device = /net/connman/iwd/0/3
> Type = psk
> {Station} [/net/connman/iwd/0/3] Scanning = False
> {Station} [/net/connman/iwd/0/3] Scanning = True
> {Added net.connman.iwd.Network}
> [/net/connman/iwd/0/3/426964656e486172726973_psk]
> Name = BidenHarris
> Connected = False
> Device = /net/connman/iwd/0/3
> Type = psk
> {Station} [/net/connman/iwd/0/3] Scanning = False
> {Station} [/net/connman/iwd/0/3] Scanning = True
> {Added net.connman.iwd.Network}
> [/net/connman/iwd/0/3/415454785a4951347761_psk]
> Name = ATTxZIQ4wa
> Connected = False
> Device = /net/connman/iwd/0/3
> Type = psk
> {Added net.connman.iwd.Network}
> [/net/connman/iwd/0/3/4d4f544f524f4c412d4645304431_psk]
> Name = MOTOROLA-FE0D1
> Connected = False
> Device = /net/connman/iwd/0/3
> Type = psk
> {Added net.connman.iwd.Network}
> [/net/connman/iwd/0/3/4e4554474541525f455854_open]
> Name = NETGEAR_EXT
> Connected = False
> Device = /net/connman/iwd/0/3
> Type = open
> {Station} [/net/connman/iwd/0/3] Scanning = False
> {Station} [/net/connman/iwd/0/3] Scanning = True
> {Removed net.connman.iwd.Network}
> [/net/connman/iwd/0/3/4e4554474541525f455854_open]
> {Removed net.connman.iwd.Network}
> [/net/connman/iwd/0/3/4d4f544f524f4c412d4645304431_psk]
> {Removed net.connman.iwd.Network} [/net/connman/iwd/0/3/48414e4e4135_psk]
> {Added net.connman.iwd.Network} [/net/connman/iwd/0/3/73706733_psk]
> Name = spg3
> Connected = True
> Device = /net/connman/iwd/0/3
> Type = psk
> KnownNetwork = /net/connman/iwd/73706733_psk
> {Added net.connman.iwd.Network} [/net/connman/iwd/0/3/73706732_psk]
> Name = spg2
> Connected = False
> Device = /net/connman/iwd/0/3
> Type = psk
> {Added net.connman.iwd.Network}
> [/net/connman/iwd/0/3/4e4554474541523336_psk]
> Name = NETGEAR36
> Connected = False
> Device = /net/connman/iwd/0/3
> Type = psk
> {Station} [/net/connman/iwd/0/3] Scanning = False
> {Station} [/net/connman/iwd/0/3] State = connecting
> {Station} [/net/connman/iwd/0/3] ConnectedNetwork =
> /net/connman/iwd/0/3/73706733_psk
> {Network} [/net/connman/iwd/0/3/73706733_psk] Connected = True
> {Station} [/net/connman/iwd/0/3] State = connected
> {KnownNetwork} [/net/connman/iwd/73706733_psk] LastConnectedTime =
> 2020-09-28T01:10:45Z
>
> The attached journal shows this for downing the radio when connman was
> controlling the network. It ignores it. My guess is there is some strange
> setting in Arch Linux which stops this from working when connman is
> managing things. What more can I do to help? I see this same behavior on my
> arm devices (RPis) and x86_64 full desktop installs.
>
> Keith
>
>
Daniel,
I woke up this morning and I think I get it now. I need to run monitor-iwd
when I run networkd/dhcpcd and monitor-connman when connman is managing the
connections. Well, with the same process, this is the report from
monitor-connman when connman is managing the interface (I am monitoring it
over ssh by logging into the ethernet IP address):
# ./monitor-connman
{Service} [/net/connman/service/wifi_b827eb52ccd0_73706732_managed_psk]
Strength = 62
{Service}
[/net/connman/service/wifi_b827eb52ccd0_52756e65417564696f4150_managed_psk]
Strength = 56
{Service}
[/net/connman/service/wifi_b827eb52ccd0_415454785a4951347761_managed_psk]
Strength = 22
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523938_managed_psk]
Strength = 21
{Service}
[/net/connman/service/wifi_b827eb52ccd0_44617272656e333231_managed_psk]
Strength = 15
{Service}
[/net/connman/service/wifi_b827eb52ccd0_464249205375727665696c6c616e63652056616e_managed_psk]
Strength = 15
{Service}
[/net/connman/service/wifi_b827eb52ccd0_52756e65417564696f4150_managed_psk]
Strength = 55
{Service}
[/net/connman/service/wifi_b827eb52ccd0_41545458495849537069_managed_psk]
Strength = 34
{Service}
[/net/connman/service/wifi_b827eb52ccd0_486f757365537461726b3031_managed_psk]
Strength = 19
{Service}
[/net/connman/service/wifi_b827eb52ccd0_456c4a656665_managed_psk] Strength
= 19
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4154546a435336706932_managed_psk]
Strength = 19
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523938_managed_psk]
Strength = 19
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523633_managed_psk]
Strength = 20
{Service}
[/net/connman/service/wifi_b827eb52ccd0_456476656e747572657333_managed_psk]
Strength = 19
{Service}
[/net/connman/service/wifi_b827eb52ccd0_44617272656e333231_managed_psk]
Strength = 18
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523336_managed_psk]
Strength = 15
*{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
State = association{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] State =
configuration{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Ethernet = {
Method=auto Interface=wlan0 Address=B8:27:EB:52:CC:D0 MTU=1500 }{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Ethernet = {
Method=auto Interface=wlan0 Address=B8:27:EB:52:CC:D0 MTU=1500 }{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Timeservers =
[ ]{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
State = ready{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Favorite =
1{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
Domains = [ ]{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Proxy = {
}{Technology} [/net/connman/technology/wifi] Connected = 1*
*{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
IPv6 = { Method=auto Address=2600:1700:4320:6caf:ba27:ebff:fe52:ccd0
PrefixLength=64 Privacy=disabled }{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Domains = [
griders ]{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Timeservers =
[ ]{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
IPv4 = { Method=dhcp Address=192.168.2.41 Netmask=255.255.255.0 }{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Nameservers =
[ 192.168.2.3 xxxx:xxxx:xxxx:xxxx:ba27:ebff:fe0b:9be6 ]{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Domains = [
]{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
Timeservers = [ ]{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Timeservers =
[ ]{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
State = disconnect{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Domains = [
]{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
Proxy = { }{Technology} [/net/connman/technology/wifi] Connected = 0*
*{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
Timeservers = [ ]{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Timeservers =
[ ]{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
State = idle{Service} [/net/connman/service/ethernet_b827eb079985_cable]
IPv4 = { Method=dhcp Address=192.168.2.193 Netmask=255.255.255.0 }{Service}
[/net/connman/service/ethernet_b827eb079985_cable] IPv4 = { Method=dhcp
Address=192.168.2.193 Netmask=255.255.255.0 Gateway=192.168.2.1 }{Service}
[/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk] Nameservers =
[ ]*
{Service}
[/net/connman/service/wifi_b827eb52ccd0_41545458495849537069_managed_psk]
Strength = 15
{Service}
[/net/connman/service/wifi_b827eb52ccd0_41545458495849537069_managed_psk]
Strength = 33
{Service}
[/net/connman/service/wifi_b827eb52ccd0_41545458495849537069_managed_psk]
Strength = 37
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523938_managed_psk]
Strength = 25
{Service}
[/net/connman/service/wifi_b827eb52ccd0_456c4a656665_managed_psk] Strength
= 22
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523633_managed_psk]
Strength = 24
{Service} [/net/connman/service/wifi_b827eb52ccd0_48414e4e41_managed_psk]
Strength = 19
{Service}
[/net/connman/service/wifi_b827eb52ccd0_415454654865544b4932_managed_psk]
Strength = 15
{Service}
[/net/connman/service/wifi_b827eb52ccd0_464249205375727665696c6c616e63652056616e_managed_psk]
Strength = 17
{Service}
[/net/connman/service/wifi_b827eb52ccd0_41545458495849537069_managed_psk]
Strength = 33
{Service}
[/net/connman/service/wifi_b827eb52ccd0_456476656e7475726573_managed_psk]
Strength = 29
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523633_managed_psk]
Strength = 21
{Service}
[/net/connman/service/wifi_b827eb52ccd0_456c4a656665_managed_psk] Strength
= 20
{Service} [/net/connman/service/wifi_b827eb52ccd0_48414e4e41_managed_psk]
Strength = 17
{Service}
[/net/connman/service/wifi_b827eb52ccd0_426964656e486172726973_managed_psk]
Strength = 17
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523336_managed_psk]
Strength = 17
{Service}
[/net/connman/service/wifi_b827eb52ccd0_415454654865544b4932_managed_psk]
Strength = 19
{Service}
[/net/connman/service/wifi_b827eb52ccd0_415454785a4951347761_managed_psk]
Strength = 19
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4154546a435336706932_managed_psk]
Strength = 16
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523938_managed_psk]
Strength = 18
{Service}
[/net/connman/service/wifi_b827eb52ccd0_456476656e747572657333_managed_psk]
Strength = 16
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4d65617374657761_managed_psk]
Strength = 16
{Service}
[/net/connman/service/wifi_b827eb52ccd0_464249205375727665696c6c616e63652056616e_managed_psk]
Strength = 16
{Service}
[/net/connman/service/wifi_b827eb52ccd0_41545458495849537069_managed_psk]
Strength = 36
{Service}
[/net/connman/service/wifi_b827eb52ccd0_456476656e7475726573_managed_psk]
Strength = 30
{Service} [/net/connman/service/wifi_b827eb52ccd0_48414e4e41_managed_psk]
Strength = 20
{Service}
[/net/connman/service/wifi_b827eb52ccd0_415454785a4951347761_managed_psk]
Strength = 23
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523633_managed_psk]
Strength = 19
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4154546a435336706932_managed_psk]
Strength = 18
{Service}
[/net/connman/service/wifi_b827eb52ccd0_456476656e747572657333_managed_psk]
Strength = 19
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523336_managed_psk]
Strength = 15
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523938_managed_psk]
Strength = 17
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4d65617374657761_managed_psk]
Strength = 15
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541525f455854_managed_none]
Strength = 13
*{Service} [/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk]
Strength = 44*
{Service} [/net/connman/service/wifi_b827eb52ccd0_73706732_managed_psk]
Strength = 59
{Service}
[/net/connman/service/wifi_b827eb52ccd0_41545458495849537069_managed_psk]
Strength = 37
{Service}
[/net/connman/service/wifi_b827eb52ccd0_4e4554474541523633_managed_psk]
Strength = 21
{Service}
[/net/connman/service/wifi_b827eb52ccd0_456476656e747572657333_managed_psk]
Strength = 20
{Service}
[/net/connman/service/wifi_b827eb52ccd0_464249205375727665696c6c616e63652056616e_managed_psk]
Strength = 17
(while typing this I notice that it scanned again, sees the SSID, but does
not initiate a connection...
I can see in the log when I use the connmanctl interface to connect to the
SSID then I can see it disconnect, then that it scans and 'sees' it again,
but it never re-connects even after it scans again. Looking at the
difference between the monitor-* logs, it looks like connman, somehow does
not recognize that it knows that network.
When I query connman, it looks like it is supposed to autoconnect:
connmanctl> services --properties wifi_b827eb52ccd0_73706733_managed_psk
/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk
Type = wifi
Security = [ psk ]
State = idle
Strength = 45
Favorite = True
Immutable = False
*AutoConnect = True*
Name = spg3
Ethernet = [ Method=auto ]
IPv4 = [ ]
IPv4.Configuration = [ Method=dhcp ]
IPv6 = [ ]
IPv6.Configuration = [ Method=auto, Privacy=disabled ]
Nameservers = [ ]
Nameservers.Configuration = [ ]
Timeservers = [ ]
Timeservers.Configuration = [ ]
Domains = [ ]
Domains.Configuration = [ ]
Proxy = [ ]
Proxy.Configuration = [ ]
mDNS = False
mDNS.Configuration = False
Provider = [ ]
The system:
Arch Linux aarch64 on an RPi, kernel 5.4.65-1-ARCH, iwd 1.9-1, connman
1.38-1
systemd 246.6-1-arch running in system mode. (+PAM +AUDIT -SELINUX -IMA
-APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ
+LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2
default-hierarchy=hybrid)
I get the same response on all Arch Linux systems: armv6 armv7 and x86_64.
Also, if I reboot with nothing connected to the ethernet port, it will
connect to the wifi SSID, but only at boot. If I connect the ethernet cable
then ssh into it and type 'connmanctl scan wifi', the prompt does not
return though the journalctl log shows that it did scan and that it did
'see' the SSID but it will not connect.
Sep 28 10:28:09 gretarune connmand[211]: plugins/iwd.c:object_added()
net.connman.iwd.Network /net/connman/iwd/0/3/73706733_psk
Sep 28 10:28:05 gretarune connmand[211]:
plugins/iwd.c:station_property_change() /net/connman/iwd/0/3 scanning 1
If I restart connman it does reconnect to the SSID (systemctl restart
connman). I tried adding imd.service to the After= line in the
connman.service file and that made no change to the behavior.
My connman.service file:
[Unit]
Description=Connection service
DefaultDependencies=false
Conflicts=shutdown.target
RequiresMountsFor=/var/lib/connman
After=dbus.service network-pre.target systemd-sysusers.service
Before=network.target multi-user.target shutdown.target
Wants=network.target
[Service]
Type=dbus
BusName=net.connman
Restart=on-failure
ExecStart=/usr/bin/connmand -n -d plugins/iwd.c
StandardOutput=null
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW
CAP_SYS_TIME CAP_SYS_MODULE CAP_SYS_ADMIN
ProtectHome=true
ProtectSystem=true
[Install]
WantedBy=multi-user.target
Thanks for any help.
Keith
Looking at this a bit more. Arch patches connman-polkit.conf when the
package is built. This is the patch:
$ cat allow_group_network.diff
--- a/src/connman-polkit.conf 2010-11-05 12:09:04.285423955 -0200
+++ b/src/connman-polkit.conf 2010-11-05 12:10:53.041423934 -0200
@@ -5,6 +5,9 @@
<allow own="net.connman"/>
<allow send_interface="net.connman.Agent"/>
</policy>
+ <policy group="network">
+ <allow send_interface="net.connman.Agent"/>
+ </policy>
<policy context="default">
<allow send_destination="net.connman"/>
</policy>
Could this be a culprit?
11:25 p.m.
Looking at this a bit more. Arch patches connman-polkit.conf when
the
package is built. This is the patch:
$ cat allow_group_network.diff
--- a/src/connman-polkit.conf 2010-11-05 12:09:04.285423955 -0200
+++ b/src/connman-polkit.conf 2010-11-05 12:10:53.041423934 -0200
@@ -5,6 +5,9 @@
<allow own="net.connman"/>
<allow send_interface="net.connman.Agent"/>
</policy>
+ <policy group="network">
+ <allow send_interface="net.connman.Agent"/>
+ </policy>
<policy context="default">
<allow send_destination="net.connman"/>
</policy>
Could this be a culprit?
This controls access to the Agent API. As far I can tell, the problems
you describe are not related to the Agent (yet).
5:40 a.m.
Daniel,
Hmmm, Agent as in 'connmanctl> agent on'?
Which distro are you using? On the RPIs, I do not believe that raspbian
(whatever it is called now) has kernel support for iwd so I don't believe
that it is a candidate for an investigation. I could be wrong, though and
the current version might. I do have 2 laptops with Arch on them right now
and can install something else on one of them. I find it strange that all
Arch Linux installs fail in this test and would like to see if a different
distro may behave differently. It would be preferable that it run on an
RPi, but I could put it on the laptop...
Keith
On Wed, Sep 30, 2020 at 1:25 AM Daniel Wagner <wagi(a)monom.org> wrote:
> Looking at this a bit more. Arch patches connman-polkit.conf
when the
> package is built. This is the patch:
> $ cat allow_group_network.diff
> --- a/src/connman-polkit.conf 2010-11-05 12:09:04.285423955 -0200
> +++ b/src/connman-polkit.conf 2010-11-05 12:10:53.041423934 -0200
> @@ -5,6 +5,9 @@
> <allow own="net.connman"/>
> <allow send_interface="net.connman.Agent"/>
> </policy>
> + <policy group="network">
> + <allow send_interface="net.connman.Agent"/>
> + </policy>
> <policy context="default">
> <allow send_destination="net.connman"/>
> </policy>
>
> Could this be a culprit?
This controls access to the Agent API. As far I can tell, the problems
you describe are not related to the Agent (yet).
6:52 a.m.
On Wed, Sep 30, 2020 at 07:40:43AM -0500, KeithG wrote:
Hmmm, Agent as in 'connmanctl> agent on'?
Yes.
Which distro are you using?
I used for a long time Fedora, since a year Tumbleweed.
On the RPIs, I do not believe that raspbian
(whatever it is called now) has kernel support for iwd so I don't believe
that it is a candidate for an investigation.
Raspian is likely not working out of the box. IIRC, Fedora and
Tumbleweed are available for RPIs, though I don't have any experience
with it. So I can't really say anything useful on it.
I could be wrong, though and
the current version might. I do have 2 laptops with Arch on them right now
and can install something else on one of them. I find it strange that all
Arch Linux installs fail in this test and would like to see if a different
distro may behave differently. It would be preferable that it run on an
RPi, but I could put it on the laptop...
It's not strange. You can't assume upstream projects ship for every
distro the correct integration/configuration option. The udev/systemd
files in the ConnMan tree are examples which need to be tweak by the
packager.
11:03 a.m.
Daniel,
Tried installing opensuse on the RPi. It installs, but when I try to run
iwd, I get:
Sep 30 12:56:35 localhost iwd[27304]: RC4 support not found
Sep 30 12:56:35 localhost iwd[27304]: The following options are missing in
the kernel:
Sep 30 12:56:35 localhost iwd[27304]:
CONFIG_CRYPTO_USER_API_SKCIPHER
Sep 30 12:56:35 localhost iwd[27304]: CONFIG_CRYPTO_ECB
Sep 30 12:56:35 localhost iwd[27304]: CONFIG_CRYPTO_ARC4
I am unfamiliar with it. How would I set up connman/iwd on this minimal
install?
Keith
On Wed, Sep 30, 2020 at 8:52 AM Daniel Wagner <wagi(a)monom.org> wrote:
On Wed, Sep 30, 2020 at 07:40:43AM -0500, KeithG wrote:
> Hmmm, Agent as in 'connmanctl> agent on'?
Yes.
> Which distro are you using?
I used for a long time Fedora, since a year Tumbleweed.
> On the RPIs, I do not believe that raspbian
> (whatever it is called now) has kernel support for iwd so I don't believe
> that it is a candidate for an investigation.
Raspian is likely not working out of the box. IIRC, Fedora and
Tumbleweed are available for RPIs, though I don't have any experience
with it. So I can't really say anything useful on it.
> I could be wrong, though and
> the current version might. I do have 2 laptops with Arch on them right
now
> and can install something else on one of them. I find it strange that all
> Arch Linux installs fail in this test and would like to see if a
different
> distro may behave differently. It would be preferable that it run on an
> RPi, but I could put it on the laptop...
It's not strange. You can't assume upstream projects ship for every
distro the correct integration/configuration option. The udev/systemd
files in the ConnMan tree are examples which need to be tweak by the
packager.
11:25 a.m.
Hi
On Wed, Sep 30, 2020 at 8:03 PM KeithG <ys3al35l(a)gmail.com> wrote:
Daniel,
Tried installing opensuse on the RPi. It installs, but when I try to run iwd, I get:
Sep 30 12:56:35 localhost iwd[27304]: RC4 support not found
Sep 30 12:56:35 localhost iwd[27304]: The following options are missing in the kernel:
Sep 30 12:56:35 localhost iwd[27304]: CONFIG_CRYPTO_USER_API_SKCIPHER
Sep 30 12:56:35 localhost iwd[27304]: CONFIG_CRYPTO_ECB
Sep 30 12:56:35 localhost iwd[27304]: CONFIG_CRYPTO_ARC4
I am unfamiliar with it. How would I set up connman/iwd on this minimal install?
You can re-package the kernel with that option enabled
Michael
Keith
On Wed, Sep 30, 2020 at 8:52 AM Daniel Wagner <wagi(a)monom.org> wrote:
>
> On Wed, Sep 30, 2020 at 07:40:43AM -0500, KeithG wrote:
> > Hmmm, Agent as in 'connmanctl> agent on'?
>
> Yes.
>
> > Which distro are you using?
>
> I used for a long time Fedora, since a year Tumbleweed.
>
> > On the RPIs, I do not believe that raspbian
> > (whatever it is called now) has kernel support for iwd so I don't believe
> > that it is a candidate for an investigation.
>
> Raspian is likely not working out of the box. IIRC, Fedora and
> Tumbleweed are available for RPIs, though I don't have any experience
> with it. So I can't really say anything useful on it.
>
> > I could be wrong, though and
> > the current version might. I do have 2 laptops with Arch on them right now
> > and can install something else on one of them. I find it strange that all
> > Arch Linux installs fail in this test and would like to see if a different
> > distro may behave differently. It would be preferable that it run on an
> > RPi, but I could put it on the laptop...
>
> It's not strange. You can't assume upstream projects ship for every
> distro the correct integration/configuration option. The udev/systemd
> files in the ConnMan tree are examples which need to be tweak by the
> packager.
_______________________________________________
connman mailing list -- connman(a)lists.01.org
To unsubscribe send an email to connman-leave(a)lists.01.org
--
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
6:40 p.m.
Michael,
Thanks for the suggestion, but being that I am unfamiliar with suse, I'll
need a bit more guidance on 'how' to do that. This is on an RPi and is
headless as I am connected by ssh to it.
Daniel,
I am at a loss as to how to help resolve this and really want to help get
it resolved.
It appears that connman1.38 will initiate a scan via 'connmanctl scan wifi'
even though it does not report that it has scanned. The git version
(1.38.r23) will report on the cli that it has scanned. So, that is an
improvement.
If I use either 1.38 (the current Arch Linux package) or build it from git,
I cannot ge tthe Rpi or my laptop to reconnect when the ssid is rebooted
even though the 'services' for the SSID
show that it is 'autoconnect' and monitor-connman shows that is 'ses' it.
Is there some main.conf setting that I have wrong?
main.conf:
FallbackNameservers = 8.8.8.8,8.8.4.4
DefaultAutoConnectTechnologies = ethernet,wifi
AllowHostnameUpdates = false
AlwaysConnectedTechnologies = ethernet,wifi
AutoConnectRoamingServices = true
As I said previously, the only modifications to the build of the connman
package under Arch are that it adds that dbus 'Agent' bits and also that it
deletes the tmpfiles.d in the package that calls out a /var/run directory
because Arch uses /run/. Other than that it is built under Arch as it is
called out in the git to be built.
From my testing, ./monitor-connman seems to 'see' the ssid return, but will
not reconnect after the router is rebooted.
If I use systemd-networkd and iwd, it reconnects every time. With connman
and iwd, I get no reconnect over a reboot.
How can I help resolve this? We have spent a lot of time and effort getting
our UI to work according to the connman manual and if it cannot reconnect
over a reboot is it kind of useless to us on our headless music player. I
have build capability and rpis and laptops with brcm as well as intel cards
to test things. I am willing to try stuff and can test and, hopefully,
respond with decent feedback, I just do not know how to modify connman to
do this.
Keith
On Wed, Sep 30, 2020 at 1:26 PM Michael Nazzareno Trimarchi <
michael(a)amarulasolutions.com> wrote:
Hi
On Wed, Sep 30, 2020 at 8:03 PM KeithG <ys3al35l(a)gmail.com> wrote:
>
> Daniel,
>
> Tried installing opensuse on the RPi. It installs, but when I try to run
iwd, I get:
>
> Sep 30 12:56:35 localhost iwd[27304]: RC4 support not found
> Sep 30 12:56:35 localhost iwd[27304]: The following options are missing
in the kernel:
> Sep 30 12:56:35 localhost iwd[27304]:
CONFIG_CRYPTO_USER_API_SKCIPHER
> Sep 30 12:56:35 localhost iwd[27304]: CONFIG_CRYPTO_ECB
> Sep 30 12:56:35 localhost iwd[27304]: CONFIG_CRYPTO_ARC4
>
> I am unfamiliar with it. How would I set up connman/iwd on this minimal
install?
You can re-package the kernel with that option enabled
Michael
>
> Keith
>
> On Wed, Sep 30, 2020 at 8:52 AM Daniel Wagner <wagi(a)monom.org> wrote:
>>
>> On Wed, Sep 30, 2020 at 07:40:43AM -0500, KeithG wrote:
>> > Hmmm, Agent as in 'connmanctl> agent on'?
>>
>> Yes.
>>
>> > Which distro are you using?
>>
>> I used for a long time Fedora, since a year Tumbleweed.
>>
>> > On the RPIs, I do not believe that raspbian
>> > (whatever it is called now) has kernel support for iwd so I don't
believe
>> > that it is a candidate for an investigation.
>>
>> Raspian is likely not working out of the box. IIRC, Fedora and
>> Tumbleweed are available for RPIs, though I don't have any experience
>> with it. So I can't really say anything useful on it.
>>
>> > I could be wrong, though and
>> > the current version might. I do have 2 laptops with Arch on them
right now
>> > and can install something else on one of them. I find it strange that
all
>> > Arch Linux installs fail in this test and would like to see if a
different
>> > distro may behave differently. It would be preferable that it run on
an
>> > RPi, but I could put it on the laptop...
>>
>> It's not strange. You can't assume upstream projects ship for every
>> distro the correct integration/configuration option. The udev/systemd
>> files in the ConnMan tree are examples which need to be tweak by the
>> packager.
>
> _______________________________________________
> connman mailing list -- connman(a)lists.01.org
> To unsubscribe send an email to connman-leave(a)lists.01.org
--
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
12:29 a.m.
On Wed, Sep 30, 2020 at 08:40:28PM -0500, KeithG wrote:
I am at a loss as to how to help resolve this and really want to help
get
it resolved.
It appears that connman1.38 will initiate a scan via 'connmanctl scan wifi'
even though it does not report that it has scanned. The git version
(1.38.r23) will report on the cli that it has scanned. So, that is an
improvement.
6b391cfd294d ("iwd: Synchronize station scanning property with scan
state") fixed this. Please next time if something doesn't work update
first to the development version to replicate the problem. This avoids
wasting time for everyone.
If I use either 1.38 (the current Arch Linux package) or build it
from git,
I cannot ge tthe Rpi or my laptop to reconnect when the ssid is rebooted
even though the 'services' for the SSID
show that it is 'autoconnect' and monitor-connman shows that is 'ses'
it.
Is there some main.conf setting that I have wrong?
main.conf:
FallbackNameservers = 8.8.8.8,8.8.4.4
DefaultAutoConnectTechnologies = ethernet,wifi
AllowHostnameUpdates = false
AlwaysConnectedTechnologies = ethernet,wifi
AutoConnectRoamingServices = true
As I said previously, the only modifications to the build of the connman
package under Arch are that it adds that dbus 'Agent' bits and also that it
deletes the tmpfiles.d in the package that calls out a /var/run directory
because Arch uses /run/. Other than that it is built under Arch as it is
called out in the git to be built.
This should be fine. Don't think this is a problem.
From my testing, ./monitor-connman seems to 'see' the ssid
return, but will
not reconnect after the router is rebooted.
If I use systemd-networkd and iwd, it reconnects every time. With connman
and iwd, I get no reconnect over a reboot.
I've redone my test with
AlwaysConnectedTechnologies = ethernet,wifi
SingleConnectedTechnology = false
and pulling the ethernet cable and disabling/enabling the wifi
network. ConnMan reconnected to both networks.
5:27 p.m.
Daniel et al
Still at this. I gave up on the RPI for now and am working on 2 laptops
with full blown Arch desktop. One laptop has a broadcom card and the other
an intel. I get the same result on both. If I let NetworkManager/iwd manage
the network the laptops reconnect as soon as the SSID reappears. Same if I
let systemd-networkd control it. If I let connman manage the network,
though, it will never reconnect to the SSID. This is with connman 1.37 and
1.38. and 1.38.r21. If I turn off the interface: 'ifconfig wlan0 down' then
back 'up', the laptop disconnects then reconnects immediately. If I turn
off the radio on the router, though, it never reconnects by itself. If I
type 'connmanctl services' I get a single service listed as opposed to a
list of a bunch of SSIDs. If I wait, it sometimes will eventually populate
that list and even list the 'known network' but will not connect. On these
laptops, I have been able to get it to reconnect if I type 'iwctl station
wlan0 scan' as well. If this does not work, it will connect if I bring the
interface down then back up.
The attached logs are simultaneous from a 'connected on the wlan' state.
From here I powered down the radio on the router then powered it back up.
From the logs, it looks like it disconnects then ceases scanning. It waited
in this state for many minutes (15?) As soon as I typed 'iwctl station
wlan0 scan' it connects and I am back online.Which component is supposed to
initiate the scan when it is offline? This was on the laptop with the
broadcom card and no ethernet conneccted.
The Arch package is built according to this package:
https://github.com/archlinux/svntogit-community/tree/packages/connman/trunk
Keith
On Thu, Oct 1, 2020 at 2:29 AM Daniel Wagner <wagi(a)monom.org> wrote:
On Wed, Sep 30, 2020 at 08:40:28PM -0500, KeithG wrote:
> I am at a loss as to how to help resolve this and really want to help get
> it resolved.
> It appears that connman1.38 will initiate a scan via 'connmanctl scan
wifi'
> even though it does not report that it has scanned. The git version
> (1.38.r23) will report on the cli that it has scanned. So, that is an
> improvement.
6b391cfd294d ("iwd: Synchronize station scanning property with scan
state") fixed this. Please next time if something doesn't work update
first to the development version to replicate the problem. This avoids
wasting time for everyone.
> If I use either 1.38 (the current Arch Linux package) or build it from
git,
> I cannot ge tthe Rpi or my laptop to reconnect when the ssid is rebooted
> even though the 'services' for the SSID
> show that it is 'autoconnect' and monitor-connman shows that is
'ses' it.
> Is there some main.conf setting that I have wrong?
>
> main.conf:
> FallbackNameservers = 8.8.8.8,8.8.4.4
> DefaultAutoConnectTechnologies = ethernet,wifi
> AllowHostnameUpdates = false
> AlwaysConnectedTechnologies = ethernet,wifi
> AutoConnectRoamingServices = true
>
> As I said previously, the only modifications to the build of the connman
> package under Arch are that it adds that dbus 'Agent' bits and also that
it
> deletes the tmpfiles.d in the package that calls out a /var/run directory
> because Arch uses /run/. Other than that it is built under Arch as it is
> called out in the git to be built.
This should be fine. Don't think this is a problem.
> From my testing, ./monitor-connman seems to 'see' the ssid return, but
will
> not reconnect after the router is rebooted.
>
> If I use systemd-networkd and iwd, it reconnects every time. With connman
> and iwd, I get no reconnect over a reboot.
I've redone my test with
AlwaysConnectedTechnologies = ethernet,wifi
SingleConnectedTechnology = false
and pulling the ethernet cable and disabling/enabling the wifi
network. ConnMan reconnected to both networks.
11:08 a.m.
Daniel,
I finally figured it out. With connman 1.38, I get it to reconnect if I
down the interface *and* if I reboot the router.
What I noticed when looking at the logs was that after the disconnect,
nothing was telling iwd to reconnect. iwd wasn't nor was connman. it just
sat there. I looked again at the /etc/connman/main.conf and noticed that
there was a setting:
BackgroundScanning = true
I uncommented this line and now it manages the interface as designed. I do
not know why it took me so long to figure this out, but it now connects.
Does this mean it always periodically scans? If so, it may be nice to only
do this if it is not connected.
Thanks for your patience with me.
Keith
On Thu, Oct 1, 2020 at 7:27 PM KeithG <ys3al35l(a)gmail.com> wrote:
Daniel et al
Still at this. I gave up on the RPI for now and am working on 2 laptops
with full blown Arch desktop. One laptop has a broadcom card and the other
an intel. I get the same result on both. If I let NetworkManager/iwd manage
the network the laptops reconnect as soon as the SSID reappears. Same if I
let systemd-networkd control it. If I let connman manage the network,
though, it will never reconnect to the SSID. This is with connman 1.37 and
1.38. and 1.38.r21. If I turn off the interface: 'ifconfig wlan0 down' then
back 'up', the laptop disconnects then reconnects immediately. If I turn
off the radio on the router, though, it never reconnects by itself. If I
type 'connmanctl services' I get a single service listed as opposed to a
list of a bunch of SSIDs. If I wait, it sometimes will eventually populate
that list and even list the 'known network' but will not connect. On these
laptops, I have been able to get it to reconnect if I type 'iwctl station
wlan0 scan' as well. If this does not work, it will connect if I bring the
interface down then back up.
The attached logs are simultaneous from a 'connected on the wlan' state.
From here I powered down the radio on the router then powered it back up.
From the logs, it looks like it disconnects then ceases scanning. It waited
in this state for many minutes (15?) As soon as I typed 'iwctl station
wlan0 scan' it connects and I am back online.Which component is supposed to
initiate the scan when it is offline? This was on the laptop with the
broadcom card and no ethernet conneccted.
The Arch package is built according to this package:
https://github.com/archlinux/svntogit-community/tree/packages/connman/trunk
Keith
On Thu, Oct 1, 2020 at 2:29 AM Daniel Wagner <wagi(a)monom.org> wrote:
> On Wed, Sep 30, 2020 at 08:40:28PM -0500, KeithG wrote:
> > I am at a loss as to how to help resolve this and really want to help
> get
> > it resolved.
> > It appears that connman1.38 will initiate a scan via 'connmanctl scan
> wifi'
> > even though it does not report that it has scanned. The git version
> > (1.38.r23) will report on the cli that it has scanned. So, that is an
> > improvement.
>
> 6b391cfd294d ("iwd: Synchronize station scanning property with scan
> state") fixed this. Please next time if something doesn't work update
> first to the development version to replicate the problem. This avoids
> wasting time for everyone.
>
> > If I use either 1.38 (the current Arch Linux package) or build it from
> git,
> > I cannot ge tthe Rpi or my laptop to reconnect when the ssid is rebooted
> > even though the 'services' for the SSID
> > show that it is 'autoconnect' and monitor-connman shows that is
'ses'
> it.
> > Is there some main.conf setting that I have wrong?
> >
> > main.conf:
> > FallbackNameservers = 8.8.8.8,8.8.4.4
> > DefaultAutoConnectTechnologies = ethernet,wifi
> > AllowHostnameUpdates = false
> > AlwaysConnectedTechnologies = ethernet,wifi
> > AutoConnectRoamingServices = true
> >
> > As I said previously, the only modifications to the build of the connman
> > package under Arch are that it adds that dbus 'Agent' bits and also
> that it
> > deletes the tmpfiles.d in the package that calls out a /var/run
> directory
> > because Arch uses /run/. Other than that it is built under Arch as it is
> > called out in the git to be built.
>
> This should be fine. Don't think this is a problem.
>
> > From my testing, ./monitor-connman seems to 'see' the ssid return, but
> will
> > not reconnect after the router is rebooted.
> >
> > If I use systemd-networkd and iwd, it reconnects every time. With
> connman
> > and iwd, I get no reconnect over a reboot.
>
> I've redone my test with
>
> AlwaysConnectedTechnologies = ethernet,wifi
> SingleConnectedTechnology = false
>
> and pulling the ethernet cable and disabling/enabling the wifi
> network. ConnMan reconnected to both networks.
>
8:04 a.m.
Group,
After I finally, painfully, figured this out and can get the wifi to
reconnect when the SSID radio goes down then comes back up. So I am running
and I notice a lot of log spam where it is now scanning the ethernet port
even though the wifi is connected. I believe this is because I now have
'BackgroundScanning=true' and have the default of
'SingleConnectedTechnology = false'.
I have a question, though, would it be reasonable if the BackgroundScanning
flag could be = true,ethernet,wifi,bluetooth as opposed to just =
true,false? I ask as I can imagine that there would be a situation where a
user would want the bt or wifi to scan if it became disconnected, but the
ethernet port can be easily unplugged/replugged to trigger a reconnection...
Keith
On Fri, Oct 2, 2020 at 1:08 PM KeithG <ys3al35l(a)gmail.com> wrote:
Daniel,
I finally figured it out. With connman 1.38, I get it to reconnect if I
down the interface *and* if I reboot the router.
What I noticed when looking at the logs was that after the disconnect,
nothing was telling iwd to reconnect. iwd wasn't nor was connman. it just
sat there. I looked again at the /etc/connman/main.conf and noticed that
there was a setting:
BackgroundScanning = true
I uncommented this line and now it manages the interface as designed. I do
not know why it took me so long to figure this out, but it now connects.
Does this mean it always periodically scans? If so, it may be nice to only
do this if it is not connected.
Thanks for your patience with me.
Keith
On Thu, Oct 1, 2020 at 7:27 PM KeithG <ys3al35l(a)gmail.com> wrote:
> Daniel et al
>
> Still at this. I gave up on the RPI for now and am working on 2 laptops
> with full blown Arch desktop. One laptop has a broadcom card and the other
> an intel. I get the same result on both. If I let NetworkManager/iwd manage
> the network the laptops reconnect as soon as the SSID reappears. Same if I
> let systemd-networkd control it. If I let connman manage the network,
> though, it will never reconnect to the SSID. This is with connman 1.37 and
> 1.38. and 1.38.r21. If I turn off the interface: 'ifconfig wlan0 down' then
> back 'up', the laptop disconnects then reconnects immediately. If I turn
> off the radio on the router, though, it never reconnects by itself. If I
> type 'connmanctl services' I get a single service listed as opposed to a
> list of a bunch of SSIDs. If I wait, it sometimes will eventually populate
> that list and even list the 'known network' but will not connect. On these
> laptops, I have been able to get it to reconnect if I type 'iwctl station
> wlan0 scan' as well. If this does not work, it will connect if I bring the
> interface down then back up.
>
> The attached logs are simultaneous from a 'connected on the wlan' state.
> From here I powered down the radio on the router then powered it back up.
> From the logs, it looks like it disconnects then ceases scanning. It waited
> in this state for many minutes (15?) As soon as I typed 'iwctl station
> wlan0 scan' it connects and I am back online.Which component is supposed to
> initiate the scan when it is offline? This was on the laptop with the
> broadcom card and no ethernet conneccted.
>
> The Arch package is built according to this package:
>
> https://github.com/archlinux/svntogit-community/tree/packages/connman/trunk
>
> Keith
>
>
>
>
> On Thu, Oct 1, 2020 at 2:29 AM Daniel Wagner <wagi(a)monom.org> wrote:
>
>> On Wed, Sep 30, 2020 at 08:40:28PM -0500, KeithG wrote:
>> > I am at a loss as to how to help resolve this and really want to help
>> get
>> > it resolved.
>> > It appears that connman1.38 will initiate a scan via 'connmanctl scan
>> wifi'
>> > even though it does not report that it has scanned. The git version
>> > (1.38.r23) will report on the cli that it has scanned. So, that is an
>> > improvement.
>>
>> 6b391cfd294d ("iwd: Synchronize station scanning property with scan
>> state") fixed this. Please next time if something doesn't work update
>> first to the development version to replicate the problem. This avoids
>> wasting time for everyone.
>>
>> > If I use either 1.38 (the current Arch Linux package) or build it from
>> git,
>> > I cannot ge tthe Rpi or my laptop to reconnect when the ssid is
>> rebooted
>> > even though the 'services' for the SSID
>> > show that it is 'autoconnect' and monitor-connman shows that is
'ses'
>> it.
>> > Is there some main.conf setting that I have wrong?
>> >
>> > main.conf:
>> > FallbackNameservers = 8.8.8.8,8.8.4.4
>> > DefaultAutoConnectTechnologies = ethernet,wifi
>> > AllowHostnameUpdates = false
>> > AlwaysConnectedTechnologies = ethernet,wifi
>> > AutoConnectRoamingServices = true
>> >
>> > As I said previously, the only modifications to the build of the
>> connman
>> > package under Arch are that it adds that dbus 'Agent' bits and also
>> that it
>> > deletes the tmpfiles.d in the package that calls out a /var/run
>> directory
>> > because Arch uses /run/. Other than that it is built under Arch as it
>> is
>> > called out in the git to be built.
>>
>> This should be fine. Don't think this is a problem.
>>
>> > From my testing, ./monitor-connman seems to 'see' the ssid return,
but
>> will
>> > not reconnect after the router is rebooted.
>> >
>> > If I use systemd-networkd and iwd, it reconnects every time. With
>> connman
>> > and iwd, I get no reconnect over a reboot.
>>
>> I've redone my test with
>>
>> AlwaysConnectedTechnologies = ethernet,wifi
>> SingleConnectedTechnology = false
>>
>> and pulling the ethernet cable and disabling/enabling the wifi
>> network. ConnMan reconnected to both networks.
>>
>
3 p.m.
Group,
I read through the code a bit more closely and it appears that the
BackgroundScanning is just for wifi. Do I have this correct? If so, why
does connman continually make the unused eth0 interface go up and down and
spam the log with messages that it made it go up and down? It appears that
it does this every 15 minutes. This happens whether or not the 'single
connected technology' is selected or not. I would think that if a single
connected technology was selected and it was connected on the wifi that it
would be quiet and ignore the other interfaces until it lost a connection
on the wifi...
Keith
On Sat, Oct 3, 2020 at 10:04 AM KeithG <ys3al35l(a)gmail.com> wrote:
Group,
After I finally, painfully, figured this out and can get the wifi to
reconnect when the SSID radio goes down then comes back up. So I am running
and I notice a lot of log spam where it is now scanning the ethernet port
even though the wifi is connected. I believe this is because I now have
'BackgroundScanning=true' and have the default of
'SingleConnectedTechnology = false'.
I have a question, though, would it be reasonable if the
BackgroundScanning flag could be = true,ethernet,wifi,bluetooth as opposed
to just = true,false? I ask as I can imagine that there would be a
situation where a user would want the bt or wifi to scan if it became
disconnected, but the ethernet port can be easily unplugged/replugged to
trigger a reconnection...
Keith
On Fri, Oct 2, 2020 at 1:08 PM KeithG <ys3al35l(a)gmail.com> wrote:
> Daniel,
>
> I finally figured it out. With connman 1.38, I get it to reconnect if I
> down the interface *and* if I reboot the router.
>
> What I noticed when looking at the logs was that after the disconnect,
> nothing was telling iwd to reconnect. iwd wasn't nor was connman. it just
> sat there. I looked again at the /etc/connman/main.conf and noticed that
> there was a setting:
> BackgroundScanning = true
>
> I uncommented this line and now it manages the interface as designed. I
> do not know why it took me so long to figure this out, but it now connects.
> Does this mean it always periodically scans? If so, it may be nice to only
> do this if it is not connected.
>
> Thanks for your patience with me.
>
> Keith
>
> On Thu, Oct 1, 2020 at 7:27 PM KeithG <ys3al35l(a)gmail.com> wrote:
>
>> Daniel et al
>>
>> Still at this. I gave up on the RPI for now and am working on 2 laptops
>> with full blown Arch desktop. One laptop has a broadcom card and the other
>> an intel. I get the same result on both. If I let NetworkManager/iwd manage
>> the network the laptops reconnect as soon as the SSID reappears. Same if I
>> let systemd-networkd control it. If I let connman manage the network,
>> though, it will never reconnect to the SSID. This is with connman 1.37 and
>> 1.38. and 1.38.r21. If I turn off the interface: 'ifconfig wlan0 down'
then
>> back 'up', the laptop disconnects then reconnects immediately. If I turn
>> off the radio on the router, though, it never reconnects by itself. If I
>> type 'connmanctl services' I get a single service listed as opposed to a
>> list of a bunch of SSIDs. If I wait, it sometimes will eventually populate
>> that list and even list the 'known network' but will not connect. On
these
>> laptops, I have been able to get it to reconnect if I type 'iwctl station
>> wlan0 scan' as well. If this does not work, it will connect if I bring the
>> interface down then back up.
>>
>> The attached logs are simultaneous from a 'connected on the wlan' state.
>> From here I powered down the radio on the router then powered it back up.
>> From the logs, it looks like it disconnects then ceases scanning. It waited
>> in this state for many minutes (15?) As soon as I typed 'iwctl station
>> wlan0 scan' it connects and I am back online.Which component is supposed to
>> initiate the scan when it is offline? This was on the laptop with the
>> broadcom card and no ethernet conneccted.
>>
>> The Arch package is built according to this package:
>>
>> https://github.com/archlinux/svntogit-community/tree/packages/connman/trunk
>>
>> Keith
>>
>>
>>
>>
>> On Thu, Oct 1, 2020 at 2:29 AM Daniel Wagner <wagi(a)monom.org> wrote:
>>
>>> On Wed, Sep 30, 2020 at 08:40:28PM -0500, KeithG wrote:
>>> > I am at a loss as to how to help resolve this and really want to help
>>> get
>>> > it resolved.
>>> > It appears that connman1.38 will initiate a scan via 'connmanctl
scan
>>> wifi'
>>> > even though it does not report that it has scanned. The git version
>>> > (1.38.r23) will report on the cli that it has scanned. So, that is an
>>> > improvement.
>>>
>>> 6b391cfd294d ("iwd: Synchronize station scanning property with scan
>>> state") fixed this. Please next time if something doesn't work
update
>>> first to the development version to replicate the problem. This avoids
>>> wasting time for everyone.
>>>
>>> > If I use either 1.38 (the current Arch Linux package) or build it
>>> from git,
>>> > I cannot ge tthe Rpi or my laptop to reconnect when the ssid is
>>> rebooted
>>> > even though the 'services' for the SSID
>>> > show that it is 'autoconnect' and monitor-connman shows that is
'ses'
>>> it.
>>> > Is there some main.conf setting that I have wrong?
>>> >
>>> > main.conf:
>>> > FallbackNameservers = 8.8.8.8,8.8.4.4
>>> > DefaultAutoConnectTechnologies = ethernet,wifi
>>> > AllowHostnameUpdates = false
>>> > AlwaysConnectedTechnologies = ethernet,wifi
>>> > AutoConnectRoamingServices = true
>>> >
>>> > As I said previously, the only modifications to the build of the
>>> connman
>>> > package under Arch are that it adds that dbus 'Agent' bits and
also
>>> that it
>>> > deletes the tmpfiles.d in the package that calls out a /var/run
>>> directory
>>> > because Arch uses /run/. Other than that it is built under Arch as it
>>> is
>>> > called out in the git to be built.
>>>
>>> This should be fine. Don't think this is a problem.
>>>
>>> > From my testing, ./monitor-connman seems to 'see' the ssid
return,
>>> but will
>>> > not reconnect after the router is rebooted.
>>> >
>>> > If I use systemd-networkd and iwd, it reconnects every time. With
>>> connman
>>> > and iwd, I get no reconnect over a reboot.
>>>
>>> I've redone my test with
>>>
>>> AlwaysConnectedTechnologies = ethernet,wifi
>>> SingleConnectedTechnology = false
>>>
>>> and pulling the ethernet cable and disabling/enabling the wifi
>>> network. ConnMan reconnected to both networks.
>>>
>>
11:33 p.m.
On Sat, Oct 03, 2020 at 05:00:17PM -0500, KeithG wrote:
I read through the code a bit more closely and it appears that the
BackgroundScanning is just for wifi. Do I have this correct?
Correct.
If so, why
does connman continually make the unused eth0 interface go up and down and
spam the log with messages that it made it go up and down?
I am pretty sure this is not ConnMan's doing.
It appears that
it does this every 15 minutes. This happens whether or not the 'single
connected technology' is selected or not. I would think that if a single
connected technology was selected and it was connected on the wifi that it
would be quiet and ignore the other interfaces until it lost a connection
on the wifi...
Do you have any other network related daemons running?
Thanks,
Daniel
6:57 a.m.
On Mon, Oct 5, 2020 at 1:33 AM Daniel Wagner <wagi(a)monom.org> wrote:
On Sat, Oct 03, 2020 at 05:00:17PM -0500, KeithG wrote:
> I read through the code a bit more closely and it appears that the
> BackgroundScanning is just for wifi. Do I have this correct?
Correct.
> If so, why
> does connman continually make the unused eth0 interface go up and down
and
> spam the log with messages that it made it go up and down?
I am pretty sure this is not ConnMan's doing.
> It appears that
> it does this every 15 minutes. This happens whether or not the 'single
> connected technology' is selected or not. I would think that if a single
> connected technology was selected and it was connected on the wifi that
it
> would be quiet and ignore the other interfaces until it lost a connection
> on the wifi...
Do you have any other network related daemons running?
Thanks,
Daniel
To answer your questions:
I do not believe that I have any other network daemons loaded or running on
either the laptops or the RPis. I have uninstalled wpa_supplicant on all
platforms and have disabled systemd-networkd and dhcpcd. In addition, on
the laptop, I disabled NetworkManager as I am running Gnome and I was
unable to remove it without removing a bunch of other stuff I need.
# systemctl status systemd-networkd
● systemd-networkd.service - Network Service
Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service;
disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:systemd-networkd.service(8)
Since I do not have wpa_supplicant installed, I find it strange that the
only way I was able to get any of these devices to scan and reconnect when
the SSID went away and returned was to have 'BackgroundScanning=true'. If
this was left as default (commented out), I can see on both monitor-iwd and
monitor-connman that the interface goes away and the computer just sits
there and does nothing. Never rescans. Same on the RPIs and Laptop. I let
it sit for 30 minutes and nothing ever happens. As soon as I made this one
edit and restarted connman, if I reboot the router, it will reconnect
almost immediately.
As for the eth0 up and down, it looks like it is being controlled by
connman. At least journalctl thinks so:
Oct 05 08:18:53 rune64 connmand[4313]: eth0 {update} flags 36866 <DOWN>
Oct 05 08:18:53 rune64 connmand[4313]: eth0 {newlink} index 3 address
B8:27:EB:07:99:85 mtu 1500
Oct 05 08:18:53 rune64 connmand[4313]: eth0 {newlink} index 3 operstate 2
<DOWN>
Oct 05 08:18:53 rune64 connmand[4313]: eth0 {update} flags 36867 <UP>
Oct 05 08:18:53 rune64 connmand[4313]: eth0 {newlink} index 3 address
B8:27:EB:07:99:85 mtu 1500
Oct 05 08:18:53 rune64 connmand[4313]: eth0 {newlink} index 3 operstate 2
<DOWN>
Oct 05 08:34:20 rune64 connmand[4313]: eth0 {update} flags 36866 <DOWN>
Oct 05 08:34:20 rune64 connmand[4313]: eth0 {newlink} index 3 address
B8:27:EB:07:99:85 mtu 1500
Oct 05 08:34:20 rune64 connmand[4313]: eth0 {newlink} index 3 operstate 2
<DOWN>
Oct 05 08:34:20 rune64 connmand[4313]: eth0 {update} flags 36867 <UP>
Oct 05 08:34:20 rune64 connmand[4313]: eth0 {newlink} index 3 address
B8:27:EB:07:99:85 mtu 1500
Oct 05 08:34:20 rune64 connmand[4313]: eth0 {newlink} index 3 operstate 2
<DOWN>
Spams the log with this.
11:29 p.m.
On Mon, Oct 05, 2020 at 08:57:47AM -0500, KeithG wrote:
As for the eth0 up and down, it looks like it is being controlled by
connman. At least journalctl thinks so:
Oct 05 08:18:53 rune64 connmand[4313]: eth0 {update} flags 36866 <DOWN>
Oct 05 08:18:53 rune64 connmand[4313]: eth0 {newlink} index 3 address
B8:27:EB:07:99:85 mtu 1500
Oct 05 08:18:53 rune64 connmand[4313]: eth0 {newlink} index 3 operstate 2
<DOWN>
Oct 05 08:18:53 rune64 connmand[4313]: eth0 {update} flags 36867 <UP>
Oct 05 08:18:53 rune64 connmand[4313]: eth0 {newlink} index 3 address
B8:27:EB:07:99:85 mtu 1500
Oct 05 08:18:53 rune64 connmand[4313]: eth0 {newlink} index 3 operstate 2
<DOWN>
Oct 05 08:34:20 rune64 connmand[4313]: eth0 {update} flags 36866 <DOWN>
Oct 05 08:34:20 rune64 connmand[4313]: eth0 {newlink} index 3 address
B8:27:EB:07:99:85 mtu 1500
Oct 05 08:34:20 rune64 connmand[4313]: eth0 {newlink} index 3 operstate 2
<DOWN>
Oct 05 08:34:20 rune64 connmand[4313]: eth0 {update} flags 36867 <UP>
Oct 05 08:34:20 rune64 connmand[4313]: eth0 {newlink} index 3 address
B8:27:EB:07:99:85 mtu 1500
Oct 05 08:34:20 rune64 connmand[4313]: eth0 {newlink} index 3 operstate 2
<DOWN>
Spams the log with this.
No, this doesn't mean it's controlled by ConnMan. ConnMan just logs the
state of the interfaces. If there are no other log entries when running
with 'connmand -n -d src/service.c' saying let's connnect/disconnect,
then it's something else enabling/disabling the interface.
7:01 a.m.
On Tue, Oct 6, 2020 at 1:29 AM Daniel Wagner <wagi(a)monom.org> wrote:
On Mon, Oct 05, 2020 at 08:57:47AM -0500, KeithG wrote:
> As for the eth0 up and down, it looks like it is being controlled by
> connman. At least journalctl thinks so:
>
> Oct 05 08:18:53 rune64 connmand[4313]: eth0 {update} flags 36866 <DOWN>
> Oct 05 08:18:53 rune64 connmand[4313]: eth0 {newlink} index 3 address
> B8:27:EB:07:99:85 mtu 1500
> Oct 05 08:18:53 rune64 connmand[4313]: eth0 {newlink} index 3 operstate 2
> <DOWN>
> Oct 05 08:18:53 rune64 connmand[4313]: eth0 {update} flags 36867 <UP>
> Oct 05 08:18:53 rune64 connmand[4313]: eth0 {newlink} index 3 address
> B8:27:EB:07:99:85 mtu 1500
> Oct 05 08:18:53 rune64 connmand[4313]: eth0 {newlink} index 3 operstate 2
> <DOWN>
> Oct 05 08:34:20 rune64 connmand[4313]: eth0 {update} flags 36866 <DOWN>
> Oct 05 08:34:20 rune64 connmand[4313]: eth0 {newlink} index 3 address
> B8:27:EB:07:99:85 mtu 1500
> Oct 05 08:34:20 rune64 connmand[4313]: eth0 {newlink} index 3 operstate 2
> <DOWN>
> Oct 05 08:34:20 rune64 connmand[4313]: eth0 {update} flags 36867 <UP>
> Oct 05 08:34:20 rune64 connmand[4313]: eth0 {newlink} index 3 address
> B8:27:EB:07:99:85 mtu 1500
> Oct 05 08:34:20 rune64 connmand[4313]: eth0 {newlink} index 3 operstate 2
> <DOWN>
>
> Spams the log with this.
No, this doesn't mean it's controlled by ConnMan. ConnMan just logs the
state of the interfaces. If there are no other log entries when running
with 'connmand -n -d src/service.c' saying let's connnect/disconnect,
then it's something else enabling/disabling the interface.
Daniel,
I think I found what is spamming the log. It isn't connman, but a script we
are running to check the interfaces. I have disabled that and will watch it
some more.
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.
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.
Oct 05 18:41:10 rune64 connmand[185]: Failed to find URL:
http://ipv6.connman.net/online/status.html
Oct 06 06:32:46 rune64 connmand[43232]:
src/service.c:__connman_service_online_check_failed() service 0x55902cbb10
type IPv6 interval 6
Oct 06 06:32:46 rune64 connmand[43232]:
src/service.c:connman_service_ref_debug() 0x55902cbb10 ref 4 by
src/service.c:6205:__connman_service_online_check_failed()
Oct 06 06:33:23 rune64 connmand[43232]:
src/service.c:connman_service_unref_debug() 0x55902cbb10 ref 3 by
src/service.c:6160:redo_wispr()
Oct 06 06:33:23 rune64 connmand[43232]: src/service.c:redo_wispr() Retrying
IPv6 WISPr for 0x55902cbb10 spg3
Oct 06 06:35:32 rune64 connmand[43232]:
src/service.c:__connman_service_online_check_failed() service 0x55902cbb10
type IPv6 interval 7
Oct 06 06:35:32 rune64 connmand[43232]:
src/service.c:connman_service_ref_debug() 0x55902cbb10 ref 4 by
src/service.c:6205:__connman_service_online_check_failed()
Oct 06 06:36:22 rune64 connmand[43232]:
src/service.c:connman_service_unref_debug() 0x55902cbb10 ref 3 by
src/service.c:6160:redo_wispr()
Oct 06 06:36:22 rune64 connmand[43232]: src/service.c:redo_wispr() Retrying
IPv6 WISPr for 0x55902cbb10 spg3
Oct 06 06:38:32 rune64 connmand[43232]:
src/service.c:__connman_service_online_check_failed() service 0x55902cbb10
type IPv6 interval 8
Oct 06 06:38:32 rune64 connmand[43232]:
src/service.c:connman_service_ref_debug() 0x55902cbb10 ref 4 by
src/service.c:6205:__connman_service_online_check_failed()
Oct 06 06:39:37 rune64 connmand[43232]:
src/service.c:connman_service_unref_debug() 0x55902cbb10 ref 3 by
src/service.c:6160:redo_wispr()
Oct 06 06:39:37 rune64 connmand[43232]: src/service.c:redo_wispr() Retrying
IPv6 WISPr for 0x55902cbb10 spg3
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.
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.
Keith
11:15 p.m.
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
3:30 p.m.
On Wed, Oct 7, 2020 at 1:15 AM Daniel Wagner <wagi(a)monom.org> 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
11:31 p.m.
Hi Keith,
On Sat, Oct 03, 2020 at 10:04:36AM -0500, KeithG wrote:
After I finally, painfully, figured this out and can get the wifi to
reconnect when the SSID radio goes down then comes back up. So I am running
and I notice a lot of log spam where it is now scanning the ethernet port
even though the wifi is connected. I believe this is because I now have
'BackgroundScanning=true' and have the default of
'SingleConnectedTechnology = false'.
BackGroundScanning is only relevant for the wpa_supplicant plugin
(plugins/wifi.c). iwd is able to steer the scanning itself and doesn't
need ConnMan to tell how to scan. You can still trigger a manual scan
but this is not needed in general. It's just if you have an impatient
user who doesn't want to wait for the regular scan.
I have a question, though, would it be reasonable if the
BackgroundScanning
flag could be = true,ethernet,wifi,bluetooth as opposed to just =
true,false?
BackgroundScanning is really only for the wpa_supplicant plugin. It's
very unfortunate that ConnMan even has to know about it. It's a layer
violation.
I ask as I can imagine that there would be a situation where a
user would want the bt or wifi to scan if it became disconnected, but the
ethernet port can be easily unplugged/replugged to trigger a
reconnection...
For this we have the manual scan.
Thanks,
Daniel
11:22 p.m.
On Mon, Sep 28, 2020 at 05:43:23AM -0500, KeithG wrote:
I get the same response on all Arch Linux systems: armv6 armv7 and
x86_64.
Also, if I reboot with nothing connected to the ethernet port, it will
connect to the wifi SSID, but only at boot. If I connect the ethernet cable
then ssh into it and type 'connmanctl scan wifi', the prompt does not
return though the journalctl log shows that it did scan and that it did
'see' the SSID but it will not connect.
Okay, the auto connection algorithm somehow decides not to reconnect to
the SSID. That is strange. As I said I'll try to reproduce it
again.
12:08 a.m.
On Wed, Sep 30, 2020 at 08:22:51AM +0200, Daniel Wagner wrote:
On Mon, Sep 28, 2020 at 05:43:23AM -0500, KeithG wrote:
> I get the same response on all Arch Linux systems: armv6 armv7 and x86_64.
> Also, if I reboot with nothing connected to the ethernet port, it will
> connect to the wifi SSID, but only at boot. If I connect the ethernet cable
> then ssh into it and type 'connmanctl scan wifi', the prompt does not
> return though the journalctl log shows that it did scan and that it did
> 'see' the SSID but it will not connect.
Okay, the auto connection algorithm somehow decides not to reconnect to
the SSID. That is strange. As I said I'll try to reproduce it
again.
I was not able to reproduce your problem. ConnMan reliable reconnects to
my WiFi network (toggling SSID on the router, restarting iwd, unplug and
plug USB WiFi dongle).
Though one thing I noticed in your problem description is that you are
also using ethernet at the same time. Note that ConnMan will not
autoconnect to WiFi if ethernet is present in the default settings. See
the documentation on connman.conf
DefaultAutoConnectTechnologies
DefaultFavoriteTechnologies
AlwaysConnectedTechnologies
PreferredTechnologies
SingleConnectedTechnology
with those config knobs you can influence the auto connect algorithm.
11:19 p.m.
On Sun, Sep 27, 2020 at 08:24:02PM -0500, KeithG wrote:
I see this with all my Arch Linux installs. I made a basic install on
an
RPi with nothing but the base system and connman and iwd and a few other
programs. When I use connman to manage the wifi interface and run
./monitor-iwd, nothing ever displays even when the wifi goes down. I'd show
the tect capture, but it is blank. When I run systemd-networks/dhcpcd with
iwd, and have the network go down, I get a lot of messages and it
reconnects when the radio comes back online:
There is something not correctly configured on your system. ConnMan does
not interact in any sorts with monitor-iwd. If there is no output, it
sounds like it is not able to read from D-Bus or iwd is not running.
11:15 p.m.
On Thu, Sep 24, 2020 at 07:56:33AM -0500, KeithG wrote:
I pulled the latest connman and was able to run monitor-connman. The
attached log is what I got when I:
1) stopped connman
2) started connman
3) turned off the radio
4) waited until my phone and other devices were online with that SSID
5) typed 'connmanctl scan wifi' got no return
6) typed ctrl c
7) typed 'connmanctl services'
I noted that after I initiated the scan even though connman reported
nothing, it had already begun the connection and connected. We have noticed
that if we type 'iwctl station wlan0 scan' or, apparently 'connmanctl scan
wifi' that it will initiate and complete a scan. I wonder if the fact that
connman 1.38 never returns with a scan complete message is a hint?
IIRC, this is what I saw a few weeks back ago as well. ConnMan depends
on iwd to return a scan complete message. If that never happens for some
reason, the Scan() call will block until it hits a timeout (I think).
The
monitor-connman.txt is what showed in the terminal when I ran the script.
The monitor-connman-journal.txt is what appeared in the journal for u-
connman. At the same time the journalctl -iwd shows this:
Sep 24 07:29:14 keith-dell iwd[405]: Received Deauthentication event,
reason: 3, from_ap: false
Sep 24 07:39:08 keith-dell iwd[405]: Received Deauthentication event,
reason: 3, from_ap: true
Sep 24 07:39:08 keith-dell iwd[405]: Connected BSS not in scan results
Sep 24 07:39:08 keith-dell iwd[405]: authentication timed out
Is there some sort of timing problem?
I am no expert on iwd. Those log message look interesting, sure things
to check up what the impact is of it.
1:04 a.m.
Custom psychology research writing services have become very popular among students
seeking Psychology Assignment Writing Services and psychology essay writing services.
https://researchpapers247.com/psychology-assignment-writing-services-2/
11:23 p.m.
Custom psychology research writing services have become very popular among students
seeking Psychology Assignment Writing Services and psychology essay writing services.
https://researchpapers247.com/psychology-assignment-writing-services-2/
107
days inactive
215
days old
35 comments
5 participants
participants (5)
-
Daniel Wagner -
joanmelda1＠gmail.com -
KeithG -
Michael Nazzareno Trimarchi -
Ryll, Jan (GED-SDD2)