Send connman mailing list submissions to
        connman@lists.01.org

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
        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: Online check fails for working Internet connection
      (Robert Tiemann)
   2. Re: Online check fails for working Internet connection
      (Daniel Wagner)
   3. Re: [PATCH] rootnfs: Working rootnfs using connman (Daniel Wagner)
   4. Re: [PATCH] rootnfs: Working rootnfs using connman
      (Pantelis Antoniou)
   5. Re: [PATCH] rootnfs: Working rootnfs using connman
      (David Woodhouse)
   6. Re: [PATCH] rootnfs: Working rootnfs using connman
      (Pantelis Antoniou)
   7. Re: Online check fails for working Internet connection
      (Slava Monich)
   8. Re: [PATCH] rootnfs: Working rootnfs using connman
      (Pantelis Antoniou)


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

Message: 1
Date: Wed, 30 Nov 2016 22:42:58 +0100
From: Robert Tiemann <r...@gmx.de>
To: connman@lists.01.org
Subject: Re: Online check fails for working Internet connection
Message-ID: <583f47e2.70...@gmx.de>
Content-Type: text/plain; charset=windows-1252

On 11/30/2016 07:46 PM, Daniel Wagner wrote:
> Anyway, just peeked at the code and there is some retry logic
> for IPv6 there:
> 
> ...
> 
> So there already some magic involved. A simple approach like in the IPv6
> case is to keep rearming the timer (with a backoff) and retry IPv4.

Yes, I've also found that piece of code after doing some research.
Hence my question if there was any specific reason to avoid doing
repetitions for IPv4.

After some more research I've found the Mer project
(http://merproject.org/). Looks like they are maintaining their own
ConnMan fork. Their online check is quite different:

https://git.merproject.org/mer-core/connman/blob/master/connman/src/service.c

It's a shame they have chosen to put their fork into a completely
different repo. Cherry-picking is much harder than necessary this way.

Anyway, for a start, I've ported two of their very early patches
(82b6030 [1] and e124243 [2]) to current master that add a simple
retry mechanism for IPv4. It works pretty well for my case, but as a
side effect the retries are also done if the WLAN password has been
entered incorrectly. The retries are done over a course of more than
10 minutes, and during that time it is not possible to perform a WLAN
site survey for some reason. I've tweaked it further to reduce that
time to 30 seconds with up to 5 retries, which seems to be OK. I will
test a bit more tomorrow.

Now, I don't know the ConnMan source code very well (just dived in),
and I have no idea if the implementation in the Mer project is good or
bad. The general approach in their current version, however, looks
pretty good to me (I'm saying that without having it tested, though).

What do you think, should their changes be incorporated in the
official ConnMan tree? Or would another approach be preferable?

> cheers,
> daniel

Best regards,
Robert

[1]
https://git.merproject.org/mer-core/connman/commit/82b60303d32f1cda62996504a057ec17fc352bc5
[2]
https://git.merproject.org/mer-core/connman/commit/e124243f15d44d57f2b1a5406423893475630c72


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

Message: 2
Date: Thu, 1 Dec 2016 08:17:01 +0100
From: Daniel Wagner <w...@monom.org>
To: Robert Tiemann <r...@gmx.de>
Cc: connman@lists.01.org
Subject: Re: Online check fails for working Internet connection
Message-ID: <a8386c4a-5ecb-c256-ce0e-5988ba2d0...@monom.org>
Content-Type: text/plain; charset=windows-1252; format=flowed

Good Morning Robert!

On 11/30/2016 10:42 PM, Robert Tiemann wrote:
> On 11/30/2016 07:46 PM, Daniel Wagner wrote:
>> Anyway, just peeked at the code and there is some retry logic
>> for IPv6 there:
>>
>> ...
>>
>> So there already some magic involved. A simple approach like in the IPv6
>> case is to keep rearming the timer (with a backoff) and retry IPv4.
>
> Yes, I've also found that piece of code after doing some research.
> Hence my question if there was any specific reason to avoid doing
> repetitions for IPv4.

The online test was always only one shot IIRC. Probably because no one 
dared to dive into the testing :)

> After some more research I've found the Mer project
> (http://merproject.org/). Looks like they are maintaining their own
> ConnMan fork. Their online check is quite different:
>
> https://git.merproject.org/mer-core/connman/blob/master/connman/src/service.c

I see. Looks quite sane to me.

> It's a shame they have chosen to put their fork into a completely
> different repo. Cherry-picking is much harder than necessary this way.
>
> Anyway, for a start, I've ported two of their very early patches
> (82b6030 [1] and e124243 [2]) to current master that add a simple
> retry mechanism for IPv4. It works pretty well for my case, but as a
> side effect the retries are also done if the WLAN password has been
> entered incorrectly. The retries are done over a course of more than
> 10 minutes, and during that time it is not possible to perform a WLAN
> site survey for some reason. I've tweaked it further to reduce that
> time to 30 seconds with up to 5 retries, which seems to be OK. I will
> test a bit more tomorrow.

Uff, yes those side effects need to addressed.

> Now, I don't know the ConnMan source code very well (just dived in),
> and I have no idea if the implementation in the Mer project is good or
> bad. The general approach in their current version, however, looks
> pretty good to me (I'm saying that without having it tested, though).
>
> What do you think, should their changes be incorporated in the
> official ConnMan tree? Or would another approach be preferable?

I think starting from the mer version is a good idea since theirs 
changes are already in 'production'. I would really appreciate if you 
could cook a nice patch (set) and send it for review and testing.

Thanks,
Daniel


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

Message: 3
Date: Thu, 1 Dec 2016 08:34:29 +0100
From: Daniel Wagner <w...@monom.org>
To: Pantelis Antoniou <pantelis.anton...@konsulko.com>,
        connman@lists.01.org
Cc: Koen Kooi <koen.k...@linaro.org>, Stephane Desneux
        <stephane.desn...@iot.bzh>
Subject: Re: [PATCH] rootnfs: Working rootnfs using connman
Message-ID: <84be6e13-f1bc-a6a3-ed27-3b13408de...@monom.org>
Content-Type: text/plain; charset=windows-1252; format=flowed

Hi Pantelis,

On 11/30/2016 07:59 PM, Pantelis Antoniou wrote:
> Until now for root NFS you either had to manually blacklist
> the interface or disable connman all together
>
> This patch automatically blacklists the interface the NFS server
> is reachable from and populates the resolver entries that the
> DHCP server provided on startup.
>
> It is now possible to use a vanilla rootfs tarball without
> having to manually edit connman configuration entries.

Thanks for v2. I did get a compile error:

src/inet.c: In function ?get_nfs_server_ip?:
src/inet.c:3071:10: error: comparison between signed and unsigned 
integer expressions [-Werror=sign-compare]
   if (len >= sizeof(addrstr)) {
           ^~


fixed it with this here:


diff --git a/src/inet.c b/src/inet.c
index 0f2151cd4c3e..8e8805408b92 100644
--- a/src/inet.c
+++ b/src/inet.c
@@ -2969,7 +2969,7 @@ static int get_nfs_server_ip(const char 
*cmdline_file, const char *pnp_file,
                                 struct in_addr *addr)
  {
         char *s, *nfsargs;
-       int len;
+       size_t len;
         char addrstr[INET_ADDRSTRLEN];
         struct in_addr taddr;
         GError *error = NULL;


Can you double check if the type is correct. A quick test
showed that everything works as expected. That is if one has no
NFS as rootfs everything still works :)

Patch applied and pushed.

Thanks,
Daniel


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

Message: 4
Date: Thu, 1 Dec 2016 10:22:17 +0200
From: Pantelis Antoniou <pantelis.anton...@konsulko.com>
To: Daniel Wagner <w...@monom.org>
Cc: connman@lists.01.org, Koen Kooi <koen.k...@linaro.org>, Stephane
        Desneux <stephane.desn...@iot.bzh>
Subject: Re: [PATCH] rootnfs: Working rootnfs using connman
Message-ID: <8ca7e7a6-3840-4a3b-9e8a-924445d2e...@konsulko.com>
Content-Type: text/plain; charset=windows-1252

Hi Daniel,

> On Dec 1, 2016, at 09:34 , Daniel Wagner <w...@monom.org> wrote:
> 
> Hi Pantelis,
> 
> On 11/30/2016 07:59 PM, Pantelis Antoniou wrote:
>> Until now for root NFS you either had to manually blacklist
>> the interface or disable connman all together
>> 
>> This patch automatically blacklists the interface the NFS server
>> is reachable from and populates the resolver entries that the
>> DHCP server provided on startup.
>> 
>> It is now possible to use a vanilla rootfs tarball without
>> having to manually edit connman configuration entries.
> 
> Thanks for v2. I did get a compile error:
> 
> src/inet.c: In function ?get_nfs_server_ip?:
> src/inet.c:3071:10: error: comparison between signed and unsigned integer 
> expressions [-Werror=sign-compare]
>  if (len >= sizeof(addrstr)) {
>          ^~
> 
> 
> fixed it with this here:
> 
> 
> diff --git a/src/inet.c b/src/inet.c
> index 0f2151cd4c3e..8e8805408b92 100644
> --- a/src/inet.c
> +++ b/src/inet.c
> @@ -2969,7 +2969,7 @@ static int get_nfs_server_ip(const char *cmdline_file, 
> const char *pnp_file,
>                                struct in_addr *addr)
> {
>        char *s, *nfsargs;
> -       int len;
> +       size_t len;
>        char addrstr[INET_ADDRSTRLEN];
>        struct in_addr taddr;
>        GError *error = NULL;
> 
> 

Yeah, that?s better; my compiler version let it pass.

> Can you double check if the type is correct. A quick test
> showed that everything works as expected. That is if one has no
> NFS as rootfs everything still works :)
> 

Yep, I will do so.

> Patch applied and pushed.
> 

Thank you.

> Thanks,
> Daniel

Regards

? Pantelis



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

Message: 5
Date: Thu, 01 Dec 2016 08:29:14 +0000
From: David Woodhouse <dw...@infradead.org>
To: Pantelis Antoniou <pantelis.anton...@konsulko.com>,
        conn...@ml01.01.org
Cc: Koen Kooi <koen.k...@linaro.org>, Stephane Desneux
        <stephane.desn...@iot.bzh>
Subject: Re: [PATCH] rootnfs: Working rootnfs using connman
Message-ID: <1480580954.24062.4.ca...@infradead.org>
Content-Type: text/plain; charset="UTF-8"

On Wed, 2016-11-30 at 20:59 +0200, Pantelis Antoniou wrote:
> Until now for root NFS you either had to manually blacklist
> the interface or disable connman all together
> 
> This patch automatically blacklists the interface the NFS server
> is reachable from and populates the resolver entries that the
> DHCP server provided on startup.
> 
> It is now possible to use a vanilla rootfs tarball without
> having to manually edit connman configuration entries.

That looks like it supports Legacy IP only. Is that also true of the
kernel's built-in nfsroot support, or did that get brought into the
21st century? And part of the *reason* for not updating the old nfsroot
support in the kernel is that it can be done from an initramfs....
should we attempt to handle that case too??

--?
dwmw2


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

Message: 6
Date: Thu, 1 Dec 2016 10:39:07 +0200
From: Pantelis Antoniou <pantelis.anton...@konsulko.com>
To: David Woodhouse <dw...@infradead.org>
Cc: conn...@ml01.01.org, Koen Kooi <koen.k...@linaro.org>, Stephane
        Desneux <stephane.desn...@iot.bzh>
Subject: Re: [PATCH] rootnfs: Working rootnfs using connman
Message-ID: <724293cc-4418-4f8d-91a6-bcdda6c21...@konsulko.com>
Content-Type: text/plain; charset=utf-8

Hi David,

> On Dec 1, 2016, at 10:29 , David Woodhouse <dw...@infradead.org> wrote:
> 
> On Wed, 2016-11-30 at 20:59 +0200, Pantelis Antoniou wrote:
>> Until now for root NFS you either had to manually blacklist
>> the interface or disable connman all together
>> 
>> This patch automatically blacklists the interface the NFS server
>> is reachable from and populates the resolver entries that the
>> DHCP server provided on startup.
>> 
>> It is now possible to use a vanilla rootfs tarball without
>> having to manually edit connman configuration entries.
> 
> That looks like it supports Legacy IP only. Is that also true of the
> kernel's built-in nfsroot support, or did that get brought into the
> 21st century? And part of the *reason* for not updating the old nfsroot
> support in the kernel is that it can be done from an initramfs....
> should we attempt to handle that case too? 
> 

In-kernel support is IPv4 as far as I know so that?s why this is
IPv4 only. It is not hard to add IPv6 support.

When using initram rootnfs and rootnfs? I haven?t tried it but it should
be possible to detect that your root is on an NFS share. All you need is
to find out the server ip and the same method to find the interface to
blacklist.

Personally I dislike using initramfs on embedded systems because a) uses up
memory for not a particularly valid reason b) slows down boot and c) on
an embedded system you have a pretty good chance of booting directly without
needing to load non-free drivers from initramfs. Unfortunately most PC based
distros seem to use it :)

If someone wants to do it, please go ahead ;)

> -- 
> dwmw2

Regards

? Pantelis



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

Message: 7
Date: Thu, 1 Dec 2016 13:02:15 +0200
From: Slava Monich <slava.mon...@jolla.com>
To: connman@lists.01.org
Subject: Re: Online check fails for working Internet connection
Message-ID: <e531b509-340b-8daa-4c64-52ebff8a0...@jolla.com>
Content-Type: text/plain; charset=windows-1252; format=flowed

On 30/11/16 23:42, Robert Tiemann wrote:
> It's a shame they have chosen to put their fork into a completely
> different repo. Cherry-picking is much harder than necessary this way.

For whatever reason, it used to be nearly impossible for us to get 
anything non-trivial merged upstream, so we eventually gave up. It was 
simply a waste of time on both ends. And yes, it's a shame.

Cheers,
-Slava


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

Message: 8
Date: Thu, 1 Dec 2016 13:03:55 +0200
From: Pantelis Antoniou <pantelis.anton...@konsulko.com>
To: Daniel Wagner <w...@monom.org>
Cc: connman@lists.01.org, Koen Kooi <koen.k...@linaro.org>, Stephane
        Desneux <stephane.desn...@iot.bzh>
Subject: Re: [PATCH] rootnfs: Working rootnfs using connman
Message-ID: <a4eb3448-ec2c-4011-9d04-0787510b0...@konsulko.com>
Content-Type: text/plain; charset=windows-1252

Hi Daniel,

> On Dec 1, 2016, at 09:34 , Daniel Wagner <w...@monom.org> wrote:
> 
> Hi Pantelis,
> 
> On 11/30/2016 07:59 PM, Pantelis Antoniou wrote:
>> Until now for root NFS you either had to manually blacklist
>> the interface or disable connman all together
>> 
>> This patch automatically blacklists the interface the NFS server
>> is reachable from and populates the resolver entries that the
>> DHCP server provided on startup.
>> 
>> It is now possible to use a vanilla rootfs tarball without
>> having to manually edit connman configuration entries.
> 
> Thanks for v2. I did get a compile error:
> 
> src/inet.c: In function ?get_nfs_server_ip?:
> src/inet.c:3071:10: error: comparison between signed and unsigned integer 
> expressions [-Werror=sign-compare]
>  if (len >= sizeof(addrstr)) {
>          ^~
> 
> 
> fixed it with this here:
> 
> 
> diff --git a/src/inet.c b/src/inet.c
> index 0f2151cd4c3e..8e8805408b92 100644
> --- a/src/inet.c
> +++ b/src/inet.c
> @@ -2969,7 +2969,7 @@ static int get_nfs_server_ip(const char *cmdline_file, 
> const char *pnp_file,
>                                struct in_addr *addr)
> {
>        char *s, *nfsargs;
> -       int len;
> +       size_t len;
>        char addrstr[INET_ADDRSTRLEN];
>        struct in_addr taddr;
>        GError *error = NULL;
> 
> 
> Can you double check if the type is correct. A quick test
> showed that everything works as expected. That is if one has no
> NFS as rootfs everything still works :)
> 
> Patch applied and pushed.
> 

Just checked on my side; everything works as expected. I?d love others
to pitch in about their results.

> Thanks,
> Daniel

Regards

? Pantelis



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

Subject: Digest Footer

_______________________________________________
connman mailing list
connman@lists.01.org
https://lists.01.org/mailman/listinfo/connman


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

End of connman Digest, Vol 14, Issue 1
**************************************

Reply via email to