Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: connman wifi disconnect problem (Daniel Wagner)
2. Re: connman wifi disconnect problem (Daniel Wagner)
3. Re: Current connman master has difficulty getting ipv4 address
(Daniel Wagner)
----------------------------------------------------------------------
Date: Mon, 5 Oct 2020 08:31:19 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: connman wifi disconnect problem
To: KeithG <[email protected]>
Cc: "Ryll, Jan (GED-SDD2)" <[email protected]>, "[email protected]"
<[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
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
------------------------------
Date: Mon, 5 Oct 2020 08:33:35 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: connman wifi disconnect problem
To: KeithG <[email protected]>
Cc: "Ryll, Jan (GED-SDD2)" <[email protected]>, "[email protected]"
<[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
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
------------------------------
Date: Mon, 5 Oct 2020 08:41:32 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: Current connman master has difficulty getting ipv4
address
To: KeithG <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Keith,
On Fri, Oct 02, 2020 at 01:03:32PM -0500, KeithG wrote:
> I have built the latest connman from the git repo . I am running it with
> iwd and I have noticed that it is reluctant to grab an IPv4 address on the
> wifi interface. It appears to get an ipv6 and I can connect to it, but not
> from it. The ethernet interface seems unaffected as it always grabs an IP
> address. Noticed on arch linux x86_64 as well as on Raspberry Pi. Am I the
> only one seeing this? The release version of 1.38 does not seem to suffer
> from this.
There is only one relevant git commit to DHCP since the 1.38 release.
e17f601cf4af ("gdhcp: Make DHCP client timeouts suspend aware")
Can you try to revert it and see if it helps?
> Also, I notice that whenever connman is started, it soft blocks the
> bluetooth radio. I am not using bluetooth as a network interface, but for a
> keyboard and audio. Is there some setting in connman main.conf that should
> be set to counter this? As it is, I add an ExecPost to the service file to
> unblock bluetooth, but wondering if there is something else I should/could
> do.
Ah, this is a default out of the box settings of ConnMan when it
controls the 'technology'. It disables it on boot. To enable the
Bluetooth technology use via D-Bus interface once. Or alternative stop
ConnMan first and edit the /var/connman/settings file by hand:
[Bluetooth]
Enable=true
Tethering=false
Next boot, ConnMan will bring up the BT interfaces (or at least doesn't
softblock it).
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 60, Issue 4
**************************************
