Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, 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: [PATCH] service: Prevent sending D-Bus error reply twice
with hidden networks (Daniel Wagner)
2. Re: dnsproxy: invalid answer where there are no DNS servers
available (Daniel Wagner)
3. Re: Failed to bring WiFi up (Daniel Wagner)
4. Re: provision an already connected service (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Fri, 19 Jul 2019 13:29:49 +0200
From: Daniel Wagner <[email protected]>
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] service: Prevent sending D-Bus error reply twice
with hidden networks
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Jussi,
On 7/5/19 4:51 PM, Jussi Laakkonen wrote:
> When the input request has timed out or some other error has occurred do
> not allow to send duplicate D-Bus error replies. This would result in
> crashes when hidden network is first informed with ETIMEDOUT and error
> is returned and if the __connman_device_request_hidden_scan() reports an
> error or that it is already running (EALREADY) and then second error
> reply is sent.
>
> After each reply to pending D-Bus message (reply_pending()) the
> service->pending is set NULL but since request_input_cb() holds the
> reference to the pending D-Bus message (user_data) there will be a
> second reply.
>
> This fixes the issue by 1) recording the error also when D-Bus error is
> other than Canceled to prevent connecting attempt at done label and 2)
> skipping hidden network connect in such case as well.
Patch applied.
Thanks!
Daniel
------------------------------
Message: 2
Date: Fri, 19 Jul 2019 13:33:18 +0200
From: Daniel Wagner <[email protected]>
To: Nuno Gon?alves <[email protected]>
Cc: [email protected]
Subject: Re: dnsproxy: invalid answer where there are no DNS servers
available
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Nuno,
On 7/7/19 7:02 PM, Nuno Gon?alves wrote:
> Hi,
>
> I did hacked this to work for me, and it will take some substantial
> work to upstream. Anyway I hope I can do it soon.
Excellent! Thanks a lot for your effort. Really appreciated.
> I do have a question on this subsystem, when compiling with
> --with-dns-backend=systemd-resolved (instead of internal), what is the
> intended behaviour for tether clients?
>
> Currently I think they get no DNS server.
>
> Should we send them the systemd-revolved upstream server?
Hmm, sounds like a reasonable thing to do.
> Should dnsproxy be split into the proxy part and the caching part,
> where the proxy will continue to be used to relay requests to
> systemd-resolved?
If this makes sense to do (also if the code allows it :)), then yes.
Thanks,
Daniel
------------------------------
Message: 3
Date: Fri, 19 Jul 2019 13:34:19 +0200
From: Daniel Wagner <[email protected]>
To: JH <[email protected]>, connman <[email protected]>
Subject: Re: Failed to bring WiFi up
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 7/9/19 12:30 AM, JH wrote:
> It turns out that the WiFi signal was too weak caused connman dropped it.
IIRC, ConnMan would print that in the logs. But maybe I just confusing
thins :)
Thanks,
Daniel
------------------------------
Message: 4
Date: Fri, 19 Jul 2019 13:43:06 +0200
From: Daniel Wagner <[email protected]>
To: Christophe Ronco <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: provision an already connected service
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Christophe,
> In connman debug traces (attached) it seems that service is not
> disconnected-reconnected. That's why there is a difference between
> current real eth0 configuration and connman DBUS properties. This can be
> fixed by a connman restart (this time, information in kconf.config file
> will be used to connect ethernet device using fixed IP address).
>
> If I do the same thing with an already provisioned service, it is
> correctly disconnected and reconnected. At the end of operation, eth0
> IP, gateway, ... is aligned with configuration in kconf.config file even
> without a connman restart.
>
> I made a patch (attached) to fix this problem. The idea is to force
> service disconnection when connman knows that a new configuration is
> available for this service. I have simply copied what is done in
> unregister_service (src/config.c).
>
> My questions are:
> 1) Do you think the behavior described here is a bug or should I not do
> this (provision a connected service) / do this differently?
> 2) If it is a bug, is this the right way to fix it?
This sounds like a bug. At least the service should be disconnected via
this path here:
provision_changed()
__connman_config_provision_service_ident()
find_and_provision_service_from_config()
try_provision_service()
__connman_service_disconnect()
Can you check what is going in try_provision_service. At least your code
snipped should end in there not in service.c
> I will be without mail access until end of July. If you think this is a
> bug and wants a patch quicker than that, please do the correct patch. If
> you can wait and give me advice on what would be a correct patch, I can
> submit this patch when I am back from holidays.
No worries. No hurry, rather enjoy your holidays. /me does the same :)
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 45, Issue 14
***************************************
