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. dhcp discover timeout (Pieter Cardoen)
2. Spherical metal powder ([email protected])
3. Re: Current connman master has difficulty getting ipv4 address
(KeithG)
4. Re: connman wifi disconnect problem (KeithG)
----------------------------------------------------------------------
Date: Wed, 7 Oct 2020 10:12:03 +0000
From: Pieter Cardoen <[email protected]>
Subject: dhcp discover timeout
To: "[email protected]" <[email protected]>
Message-ID: <[email protected]
prd07.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Dear
We are using connman as network manager for our embedded devices. We are
currently facing an issue regarding DHCP.
I've noted that if a service is configured to use DHCP, a DHCP discover message
is sent multiple times (DISCOVER_RETRIES). If the DHCP server doesn't respond
in time, a fallback scenario is used and a fixed static IP address is
configured instead.
For or application, this behaviour is unexpected and a device should keep
sending discover messages until the end of times 😋.
We currently applied a dirty fix (see below). What is the reason of this
fallback behaviour and is it possible to configure connman to keep sending
discovers in a better way?
diff --git a/gdhcp/client.c b/gdhcp/client.c
index 0250791..831731a 100644
--- a/gdhcp/client.c
+++ b/gdhcp/client.c
@@ -2733,6 +2733,10 @@ static gboolean discover_timeout(gpointer user_data)
dhcp_client->retry_times++;
+ if(dhcp_client->retry_times == DISCOVER_RETRIES){
+ dhcp_client->retry_times = DISCOVER_RETRIES - 2;
+ }
+
Thanks
Pieter Cardoen
------------------------------
Date: Wed, 07 Oct 2020 10:15:12 -0000
From: [email protected]
Subject: Spherical metal powder
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Xi’an Sailongmetal materials Co., Limited is among the leading spherical metal
powder producer. We provide various products including PREP equipment, 3D
products, T l profiles, PM products, the metal filter, Tl profiles and more. Do
visit our ‘products” tab to know further about our offerings.
https://sailongmetals.com/product/spherical-metal-powder-for-ebm-3d-printing/
------------------------------
Date: Wed, 7 Oct 2020 10:32:49 -0500
From: KeithG <[email protected]>
Subject: Re: Current connman master has difficulty getting ipv4
address
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Message-ID:
<CAG17S_P=-6xxqp+73vjkzaxgnacbvdy0p-jvcawdaf6+u5u...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="000000000000349ea805b1166edd"
--000000000000349ea805b1166edd
Content-Type: text/plain; charset="UTF-8"
Daniel,
I built the current git and reverted that specific commit
patch -Rp1 -i "commit.diff"
I tried the current git and verified that I did only get an IPv6 address. I
tried a package with that commit reverted and I get both an IPv6 and an
IPv4 address again.
Also verified that BT is no longer blocked with that setting.
Keith
On Mon, Oct 5, 2020 at 1:41 AM Daniel Wagner <[email protected]> wrote:
> 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
>
--000000000000349ea805b1166edd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Daniel,</div><div><br></div><div>I built the current =
git and reverted that specific commit <br></div><div>patch -Rp1 -i "co=
mmit.diff"</div><div>I tried the current git and verified that I did o=
nly get an IPv6 address. I tried a package with that commit reverted and I =
get both an IPv6 and an IPv4 address again.</div><div><br></div><div>Also v=
erified that BT is no longer blocked with that setting. <br></div><div><br>=
</div><div>Keith<br></div><div><br></div></div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Oct 5, 2020 at 1:41 AM Dan=
iel Wagner <<a href=3D"mailto:[email protected]";>[email protected]</a>> wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Keith,<br=
>
<br>
On Fri, Oct 02, 2020 at 01:03:32PM -0500, KeithG wrote:<br>
> I have built the latest connman from the git repo . I am running it wi=
th<br>
> iwd and I have noticed that it is reluctant to grab an IPv4 address on=
the<br>
> wifi interface. It appears to get an ipv6 and I can connect to it, but=
not<br>
> from it. The ethernet interface seems unaffected as it always grabs an=
IP<br>
> address. Noticed on arch linux x86_64 as well as on Raspberry Pi. Am I=
the<br>
> only one seeing this? The release version of 1.38 does not seem to suf=
fer<br>
> from this.<br>
<br>
There is only one relevant git commit to DHCP since the 1.38 release.<br>
<br>
=C2=A0 e17f601cf4af ("gdhcp: Make DHCP client timeouts suspend aware&q=
uot;)<br>
<br>
Can you try to revert it and see if it helps?<br>
<br>
> Also, I notice that whenever connman is started, it soft blocks the<br=
>
> bluetooth radio. I am not using bluetooth as a network interface, but =
for a<br>
> keyboard and audio. Is there some setting in connman main.conf that sh=
ould<br>
> be set to counter this? As it is, I add an ExecPost to the service fil=
e to<br>
> unblock bluetooth, but wondering if there is something else I should/c=
ould<br>
> do.<br>
<br>
Ah, this is a default out of the box settings of ConnMan when it<br>
controls the 'technology'. It disables it on boot. To enable the<br=
>
Bluetooth technology use via D-Bus interface once. Or alternative stop<br>
ConnMan first and edit the /var/connman/settings file by hand:<br>
<br>
=C2=A0 [Bluetooth]<br>
=C2=A0 Enable=3Dtrue<br>
=C2=A0 Tethering=3Dfalse<br>
<br>
Next boot, ConnMan will bring up the BT interfaces (or at least doesn't=
<br>
softblock it).<br>
<br>
Thanks,<br>
Daniel<br>
</blockquote></div>
--000000000000349ea805b1166edd--
------------------------------
Date: Wed, 7 Oct 2020 17:30:36 -0500
From: KeithG <[email protected]>
Subject: Re: connman wifi disconnect problem
To: Daniel Wagner <[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID:
<cag17s_ngvpgaznqctwd3s9lnsd_fgqhg90_sxrw0kfcmasj...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="0000000000005828cb05b11c4435"
--0000000000005828cb05b11c4435
Content-Type: text/plain; charset="UTF-8"
On Wed, Oct 7, 2020 at 1:15 AM Daniel Wagner <[email protected]> wrote:
> On Tue, Oct 06, 2020 at 09:01:54AM -0500, KeithG wrote:
> > As I see it, there are still 3 strange things going on:
> > 1) the latest git will not grab an ipv4 address. I will revert that
> commit
> > and try this again. Probably have time later this week.
>
> Yes, please. It's the only commit which modified anything around DHCP.
>
> > 2) the IPv6 online check still always fails (though it has a valid ipv4
> and
> > ipv6 address) I can connect to ipv6 addresses via ping/curl/wget and I
> can
> > connect to it via ssh with its ipv6 address. I currently disable the
> online
> > check and the link shows as AR and not AO.
>
> I've still not setup an IPv6 network for testing, thus it's hard to test.
>
> > 3) (most confounding) I am using a setting for wpa_supplicant which seems
> > to work to get iwd to reconnect when the router goes down then back up.
> > This setting is supposed to only work with wpa_supplicant. I am leery of
> > calling this 'fixed' on my end as it is not supposed to work.
>
> Are you referring to BackgroundScanning? This doesn't do anything for
> iwd. There is literally no code in ConnMan's core nor in the iwd plugin
> looking at this variable.
>
> > On this, I wonder if it would reconnect if connman actually forced the
> iwd
> > config setting to AutoConnect=true. Currently when connman is controlling
> > iwd, the iwd config looks like this:
> >
> > [Security]
> > PreSharedKey=xxxxxx
> > Passphrase=password
> >
> > [Settings]
> > AutoConnect=false
> >
> > I cannot edit the AutoConnect to be 'true' because connman is controlling
> > it and resets it every time I try to edit it. But, without the
> > BacgroundScan setting in main.conf, iwd never gets a trigger to scan
> after
> > it has lost the connection and, therefore will never reconnect when the
> > SSID reappears. When I use systemd-networkd and iwd, I can edit this iwd
> > setting to true and it always reconnects. wpa_supplicant is not
> installed.
>
> As I explained, ConnMan is disabling iwd's AutoConnect. When to connect
> to a network is ConnMan's decision not iwd.
>
> ConnMan doesn't need to tell iwd when to scan. The BackgroundScanning
> knob was added to ConnMan because wpa_supplicant is only doing have of
> the job. Please have a look at one of Marcel Holtmann's iwd
> presentation, e.g.
>
> https://www.youtube.com/watch?v=QIqT2obSPDk
Daniel,
I appreciate the link. Interesting.
It appeared to me that flag set them to always connect, but it was more
complicated than that and part of that was my impatience. I think I was
just not waiting long enough for it to scan.
I have made things really simple and have set up a spare router so I do not
upset the family. I have a keyboard and a small display connected to the
rpi so I can interact with it directly and tail the log. I am running the
latest connman-git r23 with the dhcp patch reverted (so it grabs an ipv4
address) and iwd 1.9
main.conf only has
AllowHostnameUpdates = false
connman.service exec line is:
ExecStart=/usr/bin/connmand -n --nodnsproxy -d plugins/iwd.c
If I boot it always connects. If I power down the radio on the router it
will reconnect eventually.
I did notice one time I got a 'Service state machine inconsistency
detected' but it did reconnect after this error.
If I turn off the radio on the router then back on, I get a lag ~4 minutes
before it rescans. It will re-scan and re-connects. I did this again and it
took 13 minutes. I did it again and it took ~14 minutes. It seems like it
is on a schedule to trigger the scan at ~15 minutes? The 14+ minute wait
for a rescan seems like a long time to me. Then I did it again and it was
almost immediate. Is there any way to control this? My phone rescans almost
immediately every time and reconnects.
Keith
--0000000000005828cb05b11c4435
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Oct 7, 2020 at 1:15 AM Daniel=
Wagner <<a href=3D"mailto:[email protected]";>[email protected]</a>> wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Oct 06,=
2020 at 09:01:54AM -0500, KeithG wrote:<br>
> As I see it, there are still 3 strange things going on:<br>
> 1) the latest git will not grab an ipv4 address. I will revert that co=
mmit<br>
> and try this again. Probably have time later this week.<br>
<br>
Yes, please. It's the only commit which modified anything around DHCP.<=
br>
<br>
> 2) the IPv6 online check still always fails (though it has a valid ipv=
4 and<br>
> ipv6 address) I can connect to ipv6 addresses via ping/curl/wget and I=
can<br>
> connect to it via ssh with its ipv6 address. I currently disable the o=
nline<br>
> check and the link shows as AR and not AO.<br>
<br>
I've still not setup an IPv6 network for testing, thus it's hard to=
test.<br>
<br>
> 3) (most confounding) I am using a setting for wpa_supplicant which se=
ems<br>
> to work to get iwd to reconnect when the router goes down then back up=
.<br>
> This setting is supposed to only work with wpa_supplicant. I am leery =
of<br>
> calling this 'fixed' on my end as it is not supposed to work.<=
br>
<br>
Are you referring to BackgroundScanning? This doesn't do anything for<b=
r>
iwd. There is literally no code in ConnMan's core nor in the iwd plugin=
<br>
looking at this variable.<br>
<br>
> On this, I wonder if it would reconnect if connman actually forced the=
iwd<br>
> config setting to AutoConnect=3Dtrue. Currently when connman is contro=
lling<br>
> iwd, the iwd config looks like this:<br>
> <br>
> [Security]<br>
> PreSharedKey=3Dxxxxxx<br>
> Passphrase=3Dpassword<br>
> <br>
> [Settings]<br>
> AutoConnect=3Dfalse<br>
> <br>
> I cannot edit the AutoConnect to be 'true' because connman is =
controlling<br>
> it and resets it every time I try to edit it. But, without the<br>
> BacgroundScan setting in main.conf, iwd never gets a trigger to scan a=
fter<br>
> it has lost the connection and, therefore will never reconnect when th=
e<br>
> SSID reappears. When I use systemd-networkd and iwd, I can edit this i=
wd<br>
> setting to true and it always reconnects. wpa_supplicant is not instal=
led.<br>
<br>
As I explained, ConnMan is disabling iwd's AutoConnect. When to connect=
<br>
to a network is ConnMan's decision not iwd.<br>
<br>
ConnMan doesn't need to tell iwd when to scan. The BackgroundScanning<b=
r>
knob was added to ConnMan because wpa_supplicant is only doing have of<br>
the job. Please have a look at one of Marcel Holtmann's iwd<br>
presentation, e.g.<br>
<br>
=C2=A0 <a href=3D"https://www.youtube.com/watch?v=3DQIqT2obSPDk"; rel=3D"nor=
eferrer" target=3D"_blank">https://www.youtube.com/watch?v=3DQIqT2obSPDk</a=
></blockquote><div><br></div><div>Daniel,</div><div><br></div><div>I apprec=
iate the link. Interesting. <br></div><div><br></div><div>It appeared to me=
that flag set them to always connect, but it was more complicated than tha=
t and part of that was my impatience.=20
I think I was just not waiting long enough for it to scan.=20
</div><div><br></div><div>I have made things really simple and have set up =
a spare router so I do not upset the family. I have a keyboard and a small =
display connected to the rpi so I can interact with it directly and tail th=
e log. I am running the latest connman-git r23 with the dhcp patch reverted=
(so it grabs an ipv4 address) and iwd 1.9<br></div><div><br></div><div>mai=
n.conf only has <br></div><div>AllowHostnameUpdates =3D false</div><div>con=
nman.service exec line is:</div><div><br></div><div>ExecStart=3D/usr/bin/co=
nnmand -n --nodnsproxy -d plugins/iwd.c<br></div><div><br></div><div>If I b=
oot it always connects. If I power down the radio on the router it will rec=
onnect eventually.</div><div>I did notice one time I got a 'Service sta=
te machine inconsistency detected' but it did reconnect after this erro=
r.<br></div><div><br></div><div>If I turn off the radio on the router then =
back on, I get a lag ~4 minutes before it rescans. It will re-scan and re-c=
onnects. I did this again and it took 13 minutes. I did it again and it too=
k=C2=A0 ~14 minutes. It seems like it is on a schedule to trigger the scan =
at ~15 minutes? The 14+ minute wait for a rescan seems like a long time to =
me.
Then I did it again and it was almost immediate. Is there any way to contro=
l this?
My phone rescans almost immediately every time and reconnects.<br></div><d=
iv><br></div><div>Keith<br></div></div></div>
--0000000000005828cb05b11c4435--
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 60, Issue 7
**************************************
