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: [PATCH] timeserver: Fix time update manual->auto at startup
      (Daniel Wagner)
   2. [PATCH] timerserver: Fix time update manual->auto (Daniel Wagner)
   3. Re: [PATCH] service: Prevent auto connection during passphrase request
      (Daniel Wagner)
   4. Re: DHCP lease release (Daniel Wagner)
   5. [PATCH] service: Disable native autoconnect calls for providers
      (Daniel Wagner)
   6. [PATCH v2] service: Disable native autoconnect calls for providers
      (Daniel Wagner)
   7. Re: [PATCH v2] service: Disable native autoconnect calls for providers
      (Daniel Wagner)


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

Date: Sun, 25 Apr 2021 19:56:49 +0200
From: Daniel Wagner <w...@monom.org>
Subject: Re: [PATCH] timeserver: Fix time update manual->auto at
        startup
To: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
        <emmanuel.vaut...@cpexterne.org>
Cc: "connman@lists.01.org" <connman@lists.01.org>
Message-ID: <20210425175649.id7vpozywa3dkyip@beryllium>
Content-Type: text/plain; charset=us-ascii

Hi Emmanual,

On Sun, Apr 18, 2021 at 11:13:45PM +0000, VAUTRIN Emmanuel (Canal Plus 
Prestataire) wrote:
> > When the timerserver_list is empty the timer server sync 
> > code is supposed to be off as well. If this is not the case,
> > it's a bug and needs to be fixed. So that's why I am saying
> > assigning ts_service a valid service and at the same time
> > timerservers_list is NULL is just wrong.
> Let me just illustrate, with the following case:
> 1. The device boots, in manual mode (even if a timer list is
> provided, timerservers_list will be NULL, the default time
> /etc/timestamp is used.
> 2. After a while, the user switches to auto, to synchronize.
> __connman_timeserver_conf_update is called, but,
> unfortunately, ts_service is NULL, and differs from
> service. ts_reset is not called, nothing happens, the
> default time keeps being used instead being synchronized,
> as expected.

Ahh, stupid me. I reproduced it (thanks for your instructions) and I
think I found a better way to fix this. The thing I don't like at your
patch is that it fixes it at the wrong place. I'll send out a patch
which fixes the problem for me.

Thanks,
Daniel

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

Date: Sun, 25 Apr 2021 19:58:34 +0200
From: Daniel Wagner <w...@monom.org>
Subject: [PATCH] timerserver: Fix time update manual->auto
To: connman@lists.01.org
Cc: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
        <emmanuel.vaut...@cpexterne.org>, Daniel Wagner <w...@monom.org>
Message-ID: <20210425175834.18071-1-w...@monom.org>

__connman_timeserver_conf_update() will block the update if the
service is not matching the current used service.  In case where
ts_service is NULL it should not block the update. This can happen
by a manual to auto TimeUpdate settings change.

Reported by Emmanuel Vautrin
---
 src/timeserver.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/timeserver.c b/src/timeserver.c
index 040a7aef8221..feef8e8398b4 100644
--- a/src/timeserver.c
+++ b/src/timeserver.c
@@ -398,7 +398,7 @@ static void ts_reset(struct connman_service *service)
 
 void __connman_timeserver_sync(struct connman_service *service)
 {
-       if (!service || service == ts_service)
+       if (!service || ts_service == service)
                return;
 
        ts_reset(service);
@@ -406,7 +406,7 @@ void __connman_timeserver_sync(struct connman_service 
*service)
 
 void __connman_timeserver_conf_update(struct connman_service *service)
 {
-       if (!service || service != ts_service)
+       if (!service || (ts_service && ts_service != service))
                return;
 
        ts_reset(service);
-- 
2.31.1

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

Date: Sun, 25 Apr 2021 20:02:27 +0200
From: Daniel Wagner <w...@monom.org>
Subject: Re: [PATCH] service: Prevent auto connection during
        passphrase request
To: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
        <emmanuel.vaut...@cpexterne.org>
Cc: "connman@lists.01.org" <connman@lists.01.org>
Message-ID: <20210425180227.722x3kge2jbmy7xi@beryllium>
Content-Type: text/plain; charset=us-ascii

HI Emmanuel,

On Sun, Apr 18, 2021 at 10:47:21PM +0000, VAUTRIN Emmanuel (Canal Plus 
Prestataire) wrote:
> Thank you Daniel for your answer.
> 
> > It seems you didn't understand my explenation, here what I think is
> > the way to go. Just use the service pointer direcltly and remove the
> > entry at the end.
> In fact, it was clear, I was involving the interface (represented by service
> index) in purpose.
> 
> Let me illustrate with the following case:
> The end-user has 2 Wifi networks and wants to connect to both.
> The involved device has only one Wifi interface, 1 frequency.
> 1. He connects successfully to Wifi 1, which  is not secure.
> 2. He tries to connect to Wifi 2 which is secure.
> When doing that, the following steps happen:
>   A. ConnMan disconnect Wifi 1
>   B. It tries to user connect to Wifi 2, but is paused by the passphrase
> request.
>   C. Then, it auto connects to Wifi 1, which is available and succeeds.
>   D. The passphrase entered, it tries to user connect to Wifi 2
> but unfortunately, another Wifi (1) is already connected, so it fails.
> 
> It will never be possible in this configuration for Wifi 2 to be connected.
> The same issue also occurs if Wifi 1 is secure, as the passphrase is known.

I see, thanks for the explanation. This needs to go into the commit
message as it is important to understand why the index is used. And I
still think you need to address the issue that you never remove the
entries from the hash tables, so potentially it could be a memory hog.

Thanks,
Daniel

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

Date: Sun, 25 Apr 2021 20:16:17 +0200
From: Daniel Wagner <w...@monom.org>
Subject: Re: DHCP lease release
To: Sergey Organov <sorga...@gmail.com>
Cc: connman@lists.01.org
Message-ID: <20210425181617.lw7yhzpbxmogsseh@beryllium>
Content-Type: text/plain; charset=us-ascii

Hi Sergey,

On Fri, Apr 16, 2021 at 04:40:51PM +0300, Sergey Organov wrote:
> Hello,
> 
> I'm using connman 1.38 on embedded ARM target.
> 
> When target gets down, connman seem to send "lease release" request to
> the DHCP server, that no other host out there seem to do, including my
> Linux machine running Debian.
> 
> Is this bug or feature? Is this configurable?

I found following commits to this topic

4a5dca29b3bd ("dhcp: Stop pending gdhcp client requests")
1121ed73e9a5 ("dhcp: Invalidate and Release on Network Removal")

and RFC 2131 says in section '3.2 Client-server interaction - reusing a
previously allocated network address'

   4. The client may choose to relinquish its lease on a network
      address by sending a DHCPRELEASE message to the server.  The
      client identifies the lease to be released with its
      'client identifier', or 'chaddr' and network address in the
      DHCPRELEASE message.

      Note that in this case, where the client retains its network
      address locally, the client will not normally relinquish its
      lease during a graceful shutdown.  Only in the case where the
      client explicitly needs to relinquish its lease, e.g., the client
      is about to be moved to a different subnet, will the client send
      a DHCPRELEASE message.

I don't think it's a bug. No, it's not configurable.

> With the DHCP server in use in our network this results in randomly
> getting different IP address from DHCP after reboot, that is very
> inconvenient.

While I understand your desire for stable IP addresses, you could either
assign a static DHCP address (I know, somehow stupid) or add a DNS
server. ConnMan adds the hostname to the DHCP request, so the DHCP is
able to tell this the DNS server. I am using this in my network and this
works pretty well.

So I am not thrilled to make this configurable. Maybe it could make more
smart so it just sends out the DHCP release when we switch to a
different subnet as discussed in the RFC. If you want to work this
feature please be my guest.

Thanks,
Daniel

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

Date: Sun, 25 Apr 2021 21:00:41 +0200
From: Daniel Wagner <w...@monom.org>
Subject: [PATCH] service: Disable native autoconnect calls for
        providers
To: connman@lists.01.org
Cc: Daniel Wagner <w...@monom.org>
Message-ID: <20210425190041.10654-1-w...@monom.org>

VPN providers don't have a network at startup, hence the network
pointer is NULL.
---
 src/service.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/service.c b/src/service.c
index a16350c65ddc..153a50d2af77 100644
--- a/src/service.c
+++ b/src/service.c
@@ -6727,8 +6727,8 @@ int __connman_service_connect(struct connman_service 
*service,
 
        __connman_service_clear_error(service);
 
-       if (__connman_network_native_autoconnect(service->network) &&
-                       service->autoconnect) {
+       if (service->network && service->autoconnect &&
+                       __connman_network_native_autoconnect(service->network) {
                DBG("service %p switch connecting reason to native", service);
                reason = CONNMAN_SERVICE_CONNECT_REASON_NATIVE;
        }
-- 
2.31.1

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

Date: Sun, 25 Apr 2021 21:03:55 +0200
From: Daniel Wagner <w...@monom.org>
Subject: [PATCH v2] service: Disable native autoconnect calls for
        providers
To: connman@lists.01.org
Cc: Daniel Wagner <w...@monom.org>
Message-ID: <20210425190355.11326-2-w...@monom.org>

VPN providers don't have a network at startup, hence the network
pointer is NULL.
---
 src/service.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/service.c b/src/service.c
index a16350c65ddc..153a50d2af77 100644
--- a/src/service.c
+++ b/src/service.c
@@ -6727,8 +6727,8 @@ int __connman_service_connect(struct connman_service 
*service,
 
        __connman_service_clear_error(service);
 
-       if (__connman_network_native_autoconnect(service->network) &&
-                       service->autoconnect) {
+       if (service->network && service->autoconnect &&
+                       __connman_network_native_autoconnect(service->network) {
                DBG("service %p switch connecting reason to native", service);
                reason = CONNMAN_SERVICE_CONNECT_REASON_NATIVE;
        }
-- 
2.31.1

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

Date: Mon, 26 Apr 2021 08:55:56 +0200
From: Daniel Wagner <w...@monom.org>
Subject: Re: [PATCH v2] service: Disable native autoconnect calls for
        providers
To: connman@lists.01.org
Message-ID: <20210426065556.zz4vgdukyad5o...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii

On Sun, Apr 25, 2021 at 09:03:55PM +0200, Daniel Wagner wrote:
> -     if (__connman_network_native_autoconnect(service->network) &&
> -                     service->autoconnect) {
> +     if (service->network && service->autoconnect &&
> +                     __connman_network_native_autoconnect(service->network) {

I failed again. Anyway I applied the version with the right amount of
brackets.

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

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 66, Issue 30
***************************************

Reply via email to