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: Doesn't connect to strongest wifi (Daniel Wagner)
2. MTU (Damien LEFEVRE)
3. Re: How to configure disconnected Ethernet? (Sergey Organov)
4. Re: How to configure disconnected Ethernet? (Daniel Wagner)
5. Re: How to configure disconnected Ethernet? (Sergey Organov)
6. Re: Impossible to retry when entering wrong password with connmanctl.
(Maxime Roussin-Bélanger)
----------------------------------------------------------------------
Date: Mon, 3 Feb 2020 10:48:11 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: Doesn't connect to strongest wifi
To: Torsten Wörtwein <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
On Mon, Feb 03, 2020 at 02:46:58AM -0500, Torsten Wörtwein wrote:
> Hi Daniel,
>
> On Sun, Feb 2, 2020 at 7:47 AM Daniel Wagner <[email protected]> wrote:
>
> > iwd doesn't know about ConnMan's setting files. Are you sure ConnMan
> > was not running in the background? I don't see how else iwd figured
> > out the network settings. I assume you have a WPA2 enabled.
> >
> I'm quite sure connman wasn't running and yes it is WPA2. I had used
> connman+iwd before then, I assume iwd remembered the settings which
> connman told it at some point.
That explains it. iwd stores the credentials and that's why it was
able to auto connect.
> iwd is pretty awesome, I removed wpa_supplicant and connman (sorry,
> iwd covers all my networking needs).
>
> I was able to tweak the roaming behavior of iwd with it's RoamThreshold and
> BandModifier5Ghz settings :)
It's alright. Replacing wpa_supplicant with iwd is a win :)
Thanks,
Daniel
------------------------------
Date: Mon, 3 Feb 2020 13:45:51 +0200
From: Damien LEFEVRE <[email protected]>
Subject: MTU
To: [email protected]
Message-ID:
<ca+fhbv9qg1vizt9ofkvmhmrxvrmahf1zuuiffvtg4umj0s-...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="000000000000beab86059daa7737"
--000000000000beab86059daa7737
Content-Type: text/plain; charset="UTF-8"
Hi!
What's the correct way to set the MTU with connman? All I see from the doc
is that the value is reported as read-only
I have a yocto system where I tried to use systemd-networkd for setting the
MTU only. Out of 2 interfaces, one goes crazy after the DHCP request goes
through and I'm not able to ping from it or the device from another PC. The
network adapter led is flashing until I restart the connman service.
Thanks,
-Damien
--000000000000beab86059daa7737
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi!<div><br></div><div>What's the correct way to set t=
he MTU with connman? All I see from the doc is that the value is reported a=
s read-only</div><div><br></div><div>I have a yocto system where I tried to=
use systemd-networkd for setting the MTU only. Out of 2 interfaces, one go=
es crazy after the DHCP request goes through and I'm not able to ping f=
rom it or the device from another PC. The network adapter led is flashing u=
ntil I restart the connman service.</div><div><br></div><div>Thanks,</div><=
div>-Damien</div></div>
--000000000000beab86059daa7737--
------------------------------
Date: Mon, 03 Feb 2020 16:53:50 +0300
From: Sergey Organov <[email protected]>
Subject: Re: How to configure disconnected Ethernet?
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain
Hi Daniel,
Daniel Wagner <[email protected]> writes:
> Hi Sergey,
>
> On Thu, Jan 30, 2020 at 05:13:04PM +0300, Sergey Organov wrote:
>> The question is: how do I get Ethernet service configuration and/or
>> re-configure it when there is no cable connected; for example, how do I
>> change configuration so that at the next connect of the cable the
>> service would use static IPv4 instead of DHCP?
>
> For configuering non-existing networks you need to provision it.
> This means you need to write a provisiong file for this. There is no
> D-Bus interface for this. See the config-format.txt documentation:
>
> https://git.kernel.org/pub/scm/network/connman/connman.git/tree/doc/config-format.txt
Thanks! I've read it already, but it seemed unnatural to me to be forced
to parse/edit configuration file(s) directly, effectively duplicating
what connmand does anyway, especially as my actual aim is to do it from
an application.
I'll obviously do it, as it happens to be the only available way, but
it's still unclear how does provisioning interoperate with configuration
through D-Bus/connmanctl? My quick test shows that "connmanctl
configure" starts to give (rather undescriptive) errors on provisioned
service:
# connmanctl config ethernet_0018d7677f91_cable ipv4 dhcp
Error ethernet_0018d7677f91_cable: Not supported
#
effectively making provisioning and "connmanctl configure" mutually
exclusive. Is it how it's designed to behave indeed?
Thanks,
Sergey
------------------------------
Date: Mon, 3 Feb 2020 15:21:58 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: How to configure disconnected Ethernet?
To: Sergey Organov <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Mon, Feb 03, 2020 at 04:53:50PM +0300, Sergey Organov wrote:
> Thanks! I've read it already, but it seemed unnatural to me to be forced
> to parse/edit configuration file(s) directly, effectively duplicating
> what connmand does anyway, especially as my actual aim is to do it from
> an application.
The reason why the provisioning is done only by file is that the D-Bus
API lacks a way to create non existing services. You can only modify
currently available services via D-Bus.
> I'll obviously do it, as it happens to be the only available way, but
> it's still unclear how does provisioning interoperate with configuration
> through D-Bus/connmanctl? My quick test shows that "connmanctl
> configure" starts to give (rather undescriptive) errors on provisioned
> service:
>
> # connmanctl config ethernet_0018d7677f91_cable ipv4 dhcp
> Error ethernet_0018d7677f91_cable: Not supported
try
connmanctl config ethernet_0018d7677f91_cable --ipv4 dhcp
> effectively making provisioning and "connmanctl configure" mutually
> exclusive. Is it how it's designed to behave indeed?
Yes indeed, they are mutually exclusive due it's original use case.
Thanks,
Daniel
------------------------------
Date: Mon, 03 Feb 2020 18:39:24 +0300
From: Sergey Organov <[email protected]>
Subject: Re: How to configure disconnected Ethernet?
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain
Daniel Wagner <[email protected]> writes:
> On Mon, Feb 03, 2020 at 04:53:50PM +0300, Sergey Organov wrote:
>> Thanks! I've read it already, but it seemed unnatural to me to be forced
>> to parse/edit configuration file(s) directly, effectively duplicating
>> what connmand does anyway, especially as my actual aim is to do it from
>> an application.
>
> The reason why the provisioning is done only by file is that the D-Bus
> API lacks a way to create non existing services. You can only modify
> currently available services via D-Bus.
I meant that I'd expected I could configure Ethernet without
provisioning. In other words, I don't see why Ethernet with disconnected
cable is to be considered "non-existing" rather than, say,
"disconnected", or something else, keeping the ability to handle it
through D-Bus/connmanctl rather than forcing to use provision config
files.
>
>> I'll obviously do it, as it happens to be the only available way, but
>> it's still unclear how does provisioning interoperate with configuration
>> through D-Bus/connmanctl? My quick test shows that "connmanctl
>> configure" starts to give (rather undescriptive) errors on provisioned
>> service:
>>
>> # connmanctl config ethernet_0018d7677f91_cable ipv4 dhcp
>> Error ethernet_0018d7677f91_cable: Not supported
>
> try
>
> connmanctl config ethernet_0018d7677f91_cable --ipv4 dhcp
It doesn't seem to matter, both give the same error when interface is
provisioned, and both work silently when not, that seems to be perfectly
inline with the design of mutual exclusion of the features. The only woe
here is that error message could have been more informative.
>
>> effectively making provisioning and "connmanctl configure" mutually
>> exclusive. Is it how it's designed to behave indeed?
>
> Yes indeed, they are mutually exclusive due it's original use case.
OK, got it, thanks!
-- Sergey
------------------------------
Date: Mon, 3 Feb 2020 11:47:41 -0500
From: Maxime Roussin-Bélanger <[email protected]>
Subject: Re: Impossible to retry when entering wrong password with
connmanctl.
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Message-ID:
<CAE=t-s7wxbl2epfn8peaspjxcydrzzrmcgxydeebsnl6ax6...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="00000000000010e396059daeb091"
--00000000000010e396059daeb091
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Daniel,
On Mon, Feb 3, 2020 at 1:59 AM Daniel Wagner <[email protected]> wrote:
>
> Hi Max,
>
> On Sun, Feb 02, 2020 at 01:51:10PM -0500, Maxime Roussin-B=C3=A9langer wr=
ote:
> > On Sun, Feb 2, 2020 at 9:40 AM Daniel Wagner <[email protected]> wrote:
> > After the 'timeout', I get the output `Agent request cancelled by
ConnMan`.
>
> Okay, I'm not sure if I saw this message when trying to provoke the
> timeout.
>
> > This cancel the retry prompt. Which I can see, but instead I'm shown th=
e
> > `connmanctl>`
> > to enter a connmanctl command.
> >
> > >
> > > > We looked at the d-bus-monitor and we get two types of error: `-3`
> > > > and we do get a `16`, from 80211 AssocCode status code. -3 from wha=
t
> > > > I can understand is internal.
> > >
> > > Which communication are you monitoring? ConnMan - wpa_supplicant? You
> > > can also turn up the debug level on ConnMan side by setting the
> > > environment variable CONNMAN_SUPPLICANT_DEBUG=3D1 and enabling the
> > > connman log 'connmand -n -d'
> >
> > I monitored both.
>
> Can you upload the ConnMan log somehwere? I'd like to understand how
> we end up canceling the request and then block any further
> attempt.
I tried to connect to
the wifi_b072bfc0a090_4f6d65676120506f696e74_managed_psk network.
The connect starts at line 567, and we get an error not long after at line
576.
https://drive.google.com/open?id=3D1TESYkngpIRK-QtyRxdaCXZN-5sdReFzO
I have uploaded a picture to show what kind of output I get.
>
> > > Accoring the WiFi spec, 16 means group key handshake timeout.
> > >
> > > I've tried to simulate the timeout by not entering a passphrase but
> > > again, it's still working for me.
> >
> > I don't really know how WiFi works at a lower level, but it seems that
if
> > I send the wrong password to the AP, the AP doesn't answer back. This
> > seems to trigger the timeout, or maybe the AP sends back a response, bu=
t
> > my device driver fails to handle the situation? We use brcm80211.
>
> Okay, so there might be two problems. One is that ConnMan is gets
> stuck in a state where you can't retry to connect with a new
> password. The other sounds like a driver/firmware problem.
>
> > We've been using lttng to aggregate the tracing logs from
> > connman, wpa_supplicant and the kernel to have a complete
> > picture. This as not been easy to figure out what is going on, but
> > so far it seems to always relate to our hardware integration... (We hav=
e
> > other WiFi problems)
>
> Nifty setup :)
>
> > I'm not sure iwd will be helpful if our hardware integration is at
> > fault here... but it will give us more hints to where the problem is.
>
> The nl80211 interface got a lot of bug fixes since iwd exists. Before
> iwd there was only wpa_supplicant and the interface suffered from the
> single user user problem. iwd exersices this API differently than
> wpa_supplicant. This could paper over some of the problems or maybe
> not.
I'll start testing iwd and see what kind of log I get.
>
> If it is not to complicated to intergrate, give it a try. This gives
> you at least some idea where the problem could be. And again iwmon is
> an excellent tool for monitoring the interface. I don't know if lttng
> is able to decode all the traces. Ususally, you can easily spot the
> problems in the traces generated by iwmon.
Well, working with yocto has some advantages :) Shouldn't be too hard.
Thanks,
Max.
>
> Thanks,
> Daniel
--00000000000010e396059daeb091
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Daniel,<br><br>On Mon, Feb 3, 2020 at 1:59 AM Daniel Wa=
gner <<a href=3D"mailto:[email protected]";>[email protected]</a>> wrote:<br=
>><br>> Hi Max,<br>><br>> On Sun, Feb 02, 2020 at 01:51:10PM -0=
500, Maxime Roussin-B=C3=A9langer wrote:<br>> > On Sun, Feb 2, 2020 a=
t 9:40 AM Daniel Wagner <<a href=3D"mailto:[email protected]";>[email protected]=
g</a>> wrote:<br>> > After the 'timeout', I get the output=
`Agent request cancelled by ConnMan`.<br>><br>> Okay, I'm not su=
re if I saw this message when trying to provoke the<br>> timeout.<br>>=
;<br>> > This cancel the retry prompt. Which I can see, but instead I=
'm shown the<br>> > `connmanctl>`<br>> > to enter a conn=
manctl command.<br>> ><br>> > ><br>> > > > We lo=
oked at the d-bus-monitor and we get two types of error: `-3`<br>> > =
> > and we do get a `16`, from 80211 AssocCode status code. -3 from w=
hat<br>> > > > I can understand is internal.<br>> > ><=
br>> > > Which communication are you monitoring? ConnMan - wpa_sup=
plicant? You<br>> > > can also turn up the debug level on ConnMan =
side by setting the<br>> > > environment variable CONNMAN_SUPPLICA=
NT_DEBUG=3D1 and enabling the<br>> > > connman log 'connmand -=
n -d'<br>> ><br>> > I monitored both.<br>><br>> Can y=
ou upload the ConnMan log somehwere? I'd like to understand how<br>>=
we end up canceling the request and then block any further<br>> attempt=
.<div><br></div><div>I tried to connect to the=C2=A0wifi_b072bfc0a090_4f6d6=
5676120506f696e74_managed_psk network.</div><div><br></div><div>The connect=
starts at line 567, and we get an error not long after at line 576.</div><=
div><div><br></div><div><a href=3D"https://drive.google.com/open?id=3D1TESY=
kngpIRK-QtyRxdaCXZN-5sdReFzO">https://drive.google.com/open?id=3D1TESYkngpI=
RK-QtyRxdaCXZN-5sdReFzO</a><br></div><div><br></div><div>I have uploaded a =
picture to show what kind of output I get.</div><div><br>><br>> > =
> Accoring the WiFi spec, 16 means group key handshake timeout.<br>> =
> ><br>> > > I've tried to simulate the timeout by not e=
ntering a passphrase but<br>> > > again, it's still working fo=
r me.<br>> ><br>> > I don't really know how WiFi works at a=
lower level, but it seems that if<br>> > I send the wrong password t=
o the AP, the AP doesn't answer back. This<br>> > seems to trigge=
r the timeout, or maybe the AP sends back a response, but<br>> > my d=
evice driver fails to handle the situation? We use brcm80211.<br>><br>&g=
t; Okay, so there might be two problems. One is that ConnMan is gets<br>>=
; stuck in a state where you can't retry to connect with a new<br>> =
password. The other sounds like a driver/firmware problem.<br>><br>> =
> We've been using lttng to aggregate the tracing logs from<br>> =
> connman, wpa_supplicant and the kernel to have a complete<br>> >=
picture. This as not been easy to figure out what is going on, but<br>>=
> so far it seems to always relate to our hardware integration... (We h=
ave<br>> > other WiFi problems)<br>><br>> Nifty setup :)<br>>=
;<br>> > I'm not sure iwd will be helpful if our hardware integra=
tion is at<br>> > fault here... but it will give us more hints to whe=
re the problem is.<br>><br>> The nl80211 interface got a lot of bug f=
ixes since iwd exists. Before<br>> iwd there was only wpa_supplicant and=
the interface suffered from the<br>> single user user problem. iwd exer=
sices this API differently than<br>> wpa_supplicant. This could paper ov=
er some of the problems or maybe<br>> not.</div><div><br></div><div>I=
9;ll start testing iwd and see what kind of log I get.</div><div><br>><b=
r>> If it is not to complicated to intergrate, give it a try. This gives=
<br>> you at least some idea where the problem could be. And again iwmon=
is<br>> an excellent tool for monitoring the interface. I don't kno=
w if lttng<br>> is able to decode all the traces. Ususally, you can easi=
ly spot the<br>> problems in the traces generated by iwmon.</div><div><b=
r></div><div>Well, working with yocto has some advantages :) Shouldn't =
be too hard.</div><div><br></div><div>Thanks,</div><div>Max.</div><div><br>=
><br>> Thanks,<br>> Daniel</div></div></div>
--00000000000010e396059daeb091--
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 52, Issue 3
**************************************
