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 and IWD - Scanning Network - Update? (Daniel Wagner)
2. Re: [HELP :-) ] 3g modem auto connect (Daniel Wagner)
3. Re: [PATCH v3 1/9] vpn-provider: Implement simple connection and auth
error counters
(Daniel Wagner)
4. Re: [PATCH] pptp: Cancel queued VPN agent msg when disconnected
(Daniel Wagner)
5. Re: [PATCH] [Fix] Dereference after free in sta_remove_callback()
(Daniel Wagner)
6. Re: [PATCH] wispr: prevent use-after-free from agent browser request
(Daniel Wagner)
7. Re: [PATCH] plugins/ethernet: fix strncpy errors with GCC>9.1
(Daniel Wagner)
8. Re: if-up if-down scripts or systemd network-online target
(Daniel Wagner)
9. Re: problem changing wired connection from dhcp -> manual
(Daniel Wagner)
10. Re: Insights on connmand -d (JH)
----------------------------------------------------------------------
Date: Mon, 21 Oct 2019 08:58:35 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: Connman and IWD - Scanning Network - Update?
To: stef204 <[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Thu, Oct 17, 2019 at 05:15:51AM -0600, stef204 wrote:
> Any updates or progress on this issue?
No not yet. Sorry.
------------------------------
Date: Mon, 21 Oct 2019 09:02:21 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: [HELP :-) ] 3g modem auto connect
To: nick83ola <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi,
On Thu, Oct 10, 2019 at 10:28:37AM +0100, nick83ola wrote:
> I need a way to say to connman that if there's any cellular modem connected
> just connect to it.
> there's an option or something that I can do without monitoring connman
> through dbus?
> Is this the correct connman behaviour?
Yes, that is this is how ConnMan should behave withouth any
provisioning. Have a look at connman/doc/config-format.txt. If a
service is provisioned it will always autoconnect.
Thanks,
Daniel
------------------------------
Date: Mon, 21 Oct 2019 09:07:24 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH v3 1/9] vpn-provider: Implement simple connection
and auth error counters
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Jussi,
On Fri, Oct 11, 2019 at 03:52:51PM +0300, Jussi Laakkonen wrote:
> Add simple error counters to vpn-provider.c to count authentication and
> connection errors separately. These can be used by the VPN plugins using
> VPN agent to determine if the previous authentication has failed, and in
> such case to re-request the credentials. Values are incremented when
> vpn_provider_indicate_error() is called, both login errors
> (VPN_PROVIDER_ERROR_LOGIN_FAILED) and authentication errors
> (VPN_PROVIDER_ERROR_AUTH_FAILED) increase the authentication error
> counter.
>
> Counters are reset when connection succeeds (vpn-provider.c:connect_cb()
> is called without error) or when the provider is saved (for the cases
> where user updates the credential info in provider settings).
>
> Removed changing of the provider state to idle in case of login error.
> It is only necessary to record the errors and set state using VPN
> driver.
All patches applied.
Thanks,
Daniel
------------------------------
Date: Mon, 21 Oct 2019 09:08:21 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] pptp: Cancel queued VPN agent msg when
disconnected
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Fri, Oct 11, 2019 at 04:52:35PM +0300, Jussi Laakkonen wrote:
> Queued VPN agent messages must be canceled if the plugin timeouts
> without starting the process. This fixes the issue of having multiple
> VPN agent queries stacked on another in such scenario, where PPTP is
> awaiting for user input.
Patch applied.
Thanks,
Daniel
------------------------------
Date: Mon, 21 Oct 2019 09:10:32 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] [Fix] Dereference after free in
sta_remove_callback()
To: [email protected]
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Sat, Oct 12, 2019 at 07:12:52AM -0000, [email protected] wrote:
> Signed-off-by: Nishant Chaprana <[email protected]>
Patch applied.
Thanks,
Daniel
------------------------------
Date: Mon, 21 Oct 2019 09:24:42 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] wispr: prevent use-after-free from agent browser
request
To: John Keeping <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi John,
On Wed, Oct 16, 2019 at 01:24:27PM +0100, John Keeping wrote:
> Agent requests take a reference on the service object, but this doesn't
> guarantee that the wispr context is kept alive. When we get a callback,
> lookup the context from first principles and verify that the object
> we've been given is still a context on the given service.
>
> This prevents a use-after-free on the wispr context pointer if the agent
> takes a long time to respond (or fails to respond resulting in a DBus
> timeout) and the context is freed before that response arrives.
> ---
> This is the smallest change which solves this problem, but I'm not sure
> if it would be better to make more widespread changes in the agent
> handling code to better track and cancel agent requests that don't
> relate directly to a service.
Yeah, those timeouts are tricky to handle correctly. Considering how
difficult it is to setup and debug this I would say we go with your
solution. And if someone is wondering in future, your commit message
it will be possible to understand why the code is there :)
Thanks,
Daniel
------------------------------
Date: Mon, 21 Oct 2019 09:54:38 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] plugins/ethernet: fix strncpy errors with GCC>9.1
To: Nicola Lunghi <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
Hi,
On Wed, Oct 16, 2019 at 06:01:40PM +0100, Nicola Lunghi wrote:
> This fixes the following errors:
> vifr.cmd = GET_VLAN_VID_CMD;
> - strncpy(vifr.device1, ifname, sizeof(vifr.device1));
> + strncpy(vifr.device1, ifname, sizeof(vifr.device1) - 1);
The compiler is not always right.
IFNAMSIZ constant defines the maximum buffer size needed to hold an
interface name, including its terminating zero byte. And the way we
use strncpy here, we make sure we copy also the terminating zero byte.
That sad, I only see two possiblities to 'fix' this. Either we drop
'-Wstringop-truncation' or we go with your solution including
Böszörményi comment.
Maybe there is a third way to do: what about using memcpy instead?
> if(ioctl(sk, SIOCSIFVLAN, &vifr) >= 0)
> vid = vifr.u.VID;
> @@ -99,14 +99,17 @@ static int get_dsa_port(const char *ifname)
> return -errno;
>
> memset(&ifr, 0, sizeof(ifr));
> - strncpy(ifr.ifr_name, ifname, sizeof(ifr.ifr_name));
> + strncpy(ifr.ifr_name, ifname, sizeof(ifr.ifr_name) - 1);
>
> /* check if it is a vlan and get physical interface name*/
> vifr.cmd = GET_VLAN_REALDEV_NAME_CMD;
> - strncpy(vifr.device1, ifname, sizeof(vifr.device1));
> + strncpy(vifr.device1, ifname, sizeof(vifr.device1) - 1);
>
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wstringop-truncation"
> if(ioctl(sk, SIOCSIFVLAN, &vifr) >= 0)
> - strncpy(ifr.ifr_name, vifr.u.device2, sizeof(ifr.ifr_name));
> + strncpy(ifr.ifr_name, vifr.u.device2, sizeof(ifr.ifr_name) - 1);
> +#pragma GCC diagnostic pop
I don't think we should go down this road. Annotating the code with
random pragmas here and there makes the code no way better.
Thanks,
Daniel
------------------------------
Date: Mon, 21 Oct 2019 09:58:19 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: if-up if-down scripts or systemd network-online target
To: [email protected]
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Tormen,
On Thu, Oct 17, 2019 at 08:45:13PM +0200, [email protected] wrote:
> So if connman would
> * start network-online when AT LEAST ONE interface is brought
> up and would
> * stop network-online when the LAST interfaces would be
> brought down
> then this could IMHO satisfy most cases for if-up if-down scripts.
>
> What say you? :)
If I understood you correctly, there is already the
connman-wait-online.service script which is what you request:
$ cat src/connman-wait-online.service
[Unit]
Description=Wait for network to be configured by ConnMan
Requisite=connman.service
After=connman.service
Before=network-online.target
DefaultDependencies=no
Conflicts=shutdown.target
[Service]
Type=oneshot
ExecStart=/usr/sbin/connmand-wait-online
RemainAfterExit=yes
[Install]
WantedBy=network-online.target
Thanks,
Daniel
------------------------------
Date: Mon, 21 Oct 2019 10:00:19 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: problem changing wired connection from dhcp -> manual
To: [email protected]
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Fri, Oct 18, 2019 at 03:14:57PM -0000, [email protected] wrote:
> I'm having an issue with connman 1.27.
Could you try to reproduce this with the current HEAD. 1.27 is from
2014, so there is a chance we already fixed your problem upstream.
Thanks,
Daniel
------------------------------
Date: Mon, 21 Oct 2019 20:41:28 +1100
From: JH <[email protected]>
Subject: Re: Insights on connmand -d
To: David Weidenkopf <[email protected]>
Cc: Daniel Wagner <[email protected]>, connman <[email protected]>
Message-ID:
<CAA=hcWR6x=xdejoqmckhgckw_fn0hj83riqswmzfmqb7azk...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi Daniel and David,
The connman was built by Yocto recipe, automatically launched by
systemd service set up by the Yocto connman recipe.
Any suggestion how to fix that issue or any workarounds? The connman
is installed in an embedded device, currently I use the debug port to
access the device and to stop systemd connman and to run command -d
manually, it is not feasible to do it when a device is installed
remotely.
Thank you.
Kind regards,
- jh
On 10/2/19, JH <[email protected]> wrote:
> On 10/2/19, David Weidenkopf <[email protected]> wrote:
>> What user are you running connmand -d as? What user is the service
>> running
>> as when you launch using systemctl?
>
> Running root in connmand -d and root for systemctl for connman.service
> in imx6 platform.
>
> Thanks David.
>
>>
>> ________________________________________
>> From: JH [[email protected]]
>> Sent: Monday, September 30, 2019 6:49 PM
>> To: Daniel Wagner
>> Cc: connman
>> Subject: Re: Insights on connmand -d
>>
>> Hi Daniel,
>>
>> On 10/1/19, Daniel Wagner <[email protected]> wrote:
>>> Hi,
>>>
>>> On 9/30/19 12:51 AM, JH wrote:
>>>> Could anyone give some insights on what connmand -d differs to
>>>> connmand -n running by systemctl? From reading the documentation, my
>>>> understanding is it should be identical except increasing debug level
>>>> to printing out more debug messages, but the systemd service connmand
>>>> -n incapable of bringing my LTE modem up makes my wandering what I
>>>> could get wrong here, could the connman -n service messages be blocked
>>>> by journal logs? Appreciate anyone helps to fix it,
>>>
>>> Yes the behavior of ConnMan doesn't change with or without '-d'. It
>>> executes the exact same code. It's more like enabling a fancy function
>>> tracer.
>>
>> That completed puzzled me, the LTE modem could not be up until I run
>> systemctl stop connman and connmand -d. It is the latest version 1.36.
>>
>>
>>> I don't know if journald blocks if the logging store gets full or not.
>>> But you could try to increase the log buffer for testing. Just to rule
>>> out this problem.
>>
>> Changed journald log buffer size, it did not help. Any suggestion how
>> to debug and fix it?
>>
>> Thank you Daniel.
>>
>> Kind regards,
>> _______________________________________________
>> connman mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>> This e-mail and any files transmitted with it are the property of
>> Arthrex,
>> Inc. and/or its affiliates, are confidential, and are intended solely for
>> the use of the individual or entity to whom this e-mail is addressed. If
>> you
>> are not one of the named recipient(s) or otherwise have reason to believe
>> that you have received this message in error, please notify the sender at
>> 239-643-5553 and delete this message immediately from your computer. Any
>> other use, retention, dissemination forwarding, printing or copying of
>> this
>> e-mail is strictly prohibited. Please note that any views or opinions
>> presented in this email are solely those of the author and do not
>> necessarily represent those of the company. Finally, while Arthrex uses
>> virus protection, the recipient should check this email and any
>> attachments
>> for the presence of viruses. The company accepts no liability for any
>> damage
>> caused by any virus transmitted by this email.
>>
>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 48, Issue 27
***************************************
