Send connman mailing list submissions to
        connman@lists.01.org

To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
        connman-requ...@lists.01.org

You can reach the person managing the list at
        connman-ow...@lists.01.org

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 <w...@monom.org>
Subject: Re: connman wifi disconnect problem
To: KeithG <ys3al...@gmail.com>
Cc: "Ryll, Jan (GED-SDD2)" <jan.r...@bshg.com>, "connman@lists.01.org"
        <connman@lists.01.org>
Message-ID: <20201005063119.4zc7lyuh4vmmg...@beryllium.lan>
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 <w...@monom.org>
Subject: Re: connman wifi disconnect problem
To: KeithG <ys3al...@gmail.com>
Cc: "Ryll, Jan (GED-SDD2)" <jan.r...@bshg.com>, "connman@lists.01.org"
        <connman@lists.01.org>
Message-ID: <20201005063335.6muqitheh2xbe...@beryllium.lan>
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 <w...@monom.org>
Subject: Re: Current connman master has difficulty getting ipv4
        address
To: KeithG <ys3al...@gmail.com>
Cc: connman@lists.01.org
Message-ID: <20201005064132.mjptgxtl2i2rq...@beryllium.lan>
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 -- connman@lists.01.org
To unsubscribe send an email to connman-le...@lists.01.org


------------------------------

End of connman Digest, Vol 60, Issue 4
**************************************

Reply via email to