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
(Robert Tiemann)
3. Re: Online check fails for working Internet connection
(Slava Monich)
4. Re: Online check fails for working Internet connection
(Daniel Wagner)
5. Re: [PATCH] Adds support for additional wpa_supplicant
options (Daniel Wagner)
6. Re: [PATCH] rootnfs: Working rootnfs using connman (Daniel Wagner)
7. [PATCH] stats: Don't handle TEMP_FAILURE_RETRY on close()
(Daniel Wagner)
8. RE: [PATCH 1/2] dhcpv6: Return -EISCONN when the expiry time
is inifinite (Blanquicet-Melendez Jose (MM))
----------------------------------------------------------------------
Message: 1
Date: Thu, 1 Dec 2016 13:36:53 +0100
From: Robert Tiemann <r...@gmx.de>
To: connman@lists.01.org
Subject: Re: Online check fails for working Internet connection
Message-ID: <da4ed280-1bfd-9baa-1457-01ea4fc56...@gmx.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi!
On 12/01/2016 08:17 AM, Daniel Wagner wrote:
> The online test was always only one shot IIRC. Probably because no one
> dared to dive into the testing :)
Testing this feature is quite some effort as it seems. There are so
many cases to consider.
> Uff, yes those side effects need to addressed.
I am currently searching for the reason that causes this behavior. It
is possible that it is by some bad interaction between my application
and ConnMan; at least I cannot reproduce it with ConnMan alone. So
maybe it's just My Fault.
> 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.
I can try. It will take me some time to start this, right now I need
something that just works. Maybe I can begin working on this during
the next week, but I cannot promise anything.
> Thanks,
> Daniel
Best regards,
Robert
------------------------------
Message: 2
Date: Thu, 1 Dec 2016 13:40:06 +0100
From: Robert Tiemann <r...@gmx.de>
To: connman@lists.01.org
Subject: Re: Online check fails for working Internet connection
Message-ID: <e9ebdb50-5757-69a0-86a7-7976c2268...@gmx.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi!
On 12/01/2016 12:02 PM, Slava Monich wrote:
>
> 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.
Would you be interested to give it another try? Your changes seem to
be quite an improvement, and from my perspective it would be great to
have them in vanilla ConnMan.
> Cheers,
> -Slava
Best regards,
Robert
------------------------------
Message: 3
Date: Thu, 1 Dec 2016 14:54:30 +0200
From: Slava Monich <slava.mon...@jolla.com>
To: connman@lists.01.org
Subject: Re: Online check fails for working Internet connection
Message-ID: <5424ba89-fae1-dc1a-d174-f73fe0dbf...@jolla.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 01/12/16 14:40, Robert Tiemann wrote:
> Hi!
>
> On 12/01/2016 12:02 PM, Slava Monich wrote:
>>
>> 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.
>
> Would you be interested to give it another try? Your changes seem to
> be quite an improvement, and from my perspective it would be great to
> have them in vanilla ConnMan.
>
Possibly, but I doubt that I'll have time for that within the next month
or two. I'll keep it in mind though.
Cheers,
-Slava
------------------------------
Message: 4
Date: Thu, 1 Dec 2016 14:20:44 +0100
From: Daniel Wagner <w...@monom.org>
To: Robert Tiemann <r...@gmx.de>, Slava Monich
<slava.mon...@jolla.com>
Cc: connman@lists.01.org
Subject: Re: Online check fails for working Internet connection
Message-ID: <fa6bbb43-dc1b-fecc-a10f-918ceb380...@monom.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 12/01/2016 01:40 PM, Robert Tiemann wrote:
> On 12/01/2016 12:02 PM, Slava Monich wrote:
>> 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.
>
> Would you be interested to give it another try? Your changes seem to
> be quite an improvement, and from my perspective it would be great to
> have them in vanilla ConnMan.
FWIW, I am willing to take non trivial changes though I expect that if
things break that people actively help and get it fixed. Otherwise, I
just revert the change.
Thanks,
Daniel
------------------------------
Message: 5
Date: Thu, 1 Dec 2016 14:30:13 +0100
From: Daniel Wagner <w...@monom.org>
To: "Lichtinger, Bernhard" <bernhard.lichtin...@lrz.de>,
"marcel.holtm...@intel.com" <marcel.holtm...@intel.com>
Cc: "connman@lists.01.org" <connman@lists.01.org>
Subject: Re: [PATCH] Adds support for additional wpa_supplicant
options
Message-ID: <c0eed5ea-4645-5d1c-a589-56f3f990e...@monom.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Bernhard,
Sorry for the delay. This patch fell through the cracks. I saw your
question on IRC. It was before I setup my patchwork [1] for tracking the
state of patches.
On 10/25/2016 10:13 AM, Daniel Wagner wrote:
> On 09/08/2016 02:32 PM, Lichtinger, Bernhard wrote:
>> Perhaps you like patches more if they are inline.
>> Any comment would be nice, even a "won't apply".
>>
>> adds subject_match, altsubject_match, domain_suffix_match,
>> domain_match
>> they are used for 802.1X aka. enterprise-wpa to check
>> the authentication server's certificate in order to
>> prevent MITM attacks using a valid certificate issued
>> by the same root-CA as configured by CACertFile.
>>
>> More details at
>> https://w1.fi/cgit/hostap/plain/wpa_supplicant/wpa_supplicant.conf
>
> From a quick glance it looks good to me. Most of it is internal APIs
> anyway, which we can change if needed. The config-format is public API
> which means we should at least have some input from the iwd (the yet to
> released wireless daemon which should replace wpa_supplicant).
>
> Marcel: do think these matches proposed below make sense for iwd?
From what I can tell, this shouldn't be a problem at all. Can you just
rebase your patch and sent it again?
Thanks,
Daniel
[1] https://www.monom.org/patchwork/project/connman/list/
------------------------------
Message: 6
Date: Thu, 1 Dec 2016 14:32:00 +0100
From: Daniel Wagner <w...@monom.org>
To: Pantelis Antoniou <pantelis.anton...@konsulko.com>, David
Woodhouse <dw...@infradead.org>
Cc: conn...@ml01.01.org, Stephane Desneux <stephane.desn...@iot.bzh>,
Koen Kooi <koen.k...@linaro.org>
Subject: Re: [PATCH] rootnfs: Working rootnfs using connman
Message-ID: <6abd09eb-0294-d6ac-1a00-930517053...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Pantelis,
On 12/01/2016 09:39 AM, Pantelis Antoniou wrote:
>> 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 ;)
At least if you don't want to do it, send a patch which adds it to TODO
file so we don't forget it.
Thanks,
Daniel
------------------------------
Message: 7
Date: Thu, 1 Dec 2016 14:40:33 +0100
From: Daniel Wagner <w...@monom.org>
To: connman@lists.01.org
Cc: Daniel Wagner <daniel.wag...@bmw-carit.de>
Subject: [PATCH] stats: Don't handle TEMP_FAILURE_RETRY on close()
Message-ID: <1480599633-24894-1-git-send-email-w...@monom.org>
From: Daniel Wagner <daniel.wag...@bmw-carit.de>
If close return EINTR the filedescriptor is already invalid. This is
Linux specific behavoir.
http://lkml.indiana.edu/hypermail/linux/kernel/0509.1/0877.html
https://bugzilla.gnome.org/show_bug.cgi?id=682819
http://utcc.utoronto.ca/~cks/space/blog/unix/CloseEINTR
https://sites.google.com/site/michaelsafyan/software-engineering/checkforeintrwheninvokingclosethinkagain
Pointed out by Tom Gundersen.
*/
---
src/stats.c | 10 +++++-----
tools/stats-tool.c | 4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/stats.c b/src/stats.c
index eed6e8a1c09b..663bc3827efc 100644
--- a/src/stats.c
+++ b/src/stats.c
@@ -227,7 +227,7 @@ static void stats_free(gpointer user_data)
munmap(file->addr, file->len);
file->addr = NULL;
- TFR(close(file->fd));
+ close(file->fd);
file->fd = -1;
g_free(file->history_name);
@@ -373,7 +373,7 @@ static int stats_file_setup(struct stats_file *file)
connman_error("fstat error %s for %s\n",
strerror(errno), file->name);
- TFR(close(file->fd));
+ close(file->fd);
file->fd = -1;
g_free(file->name);
file->name = NULL;
@@ -389,7 +389,7 @@ static int stats_file_setup(struct stats_file *file)
err = stats_file_remap(file, size);
if (err < 0) {
- TFR(close(file->fd));
+ close(file->fd);
file->fd = -1;
g_free(file->name);
file->name = NULL;
@@ -619,7 +619,7 @@ static int stats_file_close_swap(struct stats_file
*history_file,
stats_file_unmap(history_file);
stats_file_unmap(temp_file);
- TFR(close(temp_file->fd));
+ close(temp_file->fd);
unlink(history_file->name);
@@ -627,7 +627,7 @@ static int stats_file_close_swap(struct stats_file
*history_file,
unlink(temp_file->name);
- TFR(close(history_file->fd));
+ close(history_file->fd);
stats_file_cleanup(history_file);
stats_file_cleanup(temp_file);
diff --git a/tools/stats-tool.c b/tools/stats-tool.c
index b076478a4bcf..efa39de27274 100644
--- a/tools/stats-tool.c
+++ b/tools/stats-tool.c
@@ -794,7 +794,7 @@ static void swap_and_close_files(struct stats_file
*history_file,
munmap(history_file->addr, history_file->len);
munmap(temp_file->addr, temp_file->len);
- TFR(close(temp_file->fd));
+ close(temp_file->fd);
unlink(history_file->name);
@@ -802,7 +802,7 @@ static void swap_and_close_files(struct stats_file
*history_file,
return;
unlink(temp_file->name);
- TFR(close(history_file->fd));
+ close(history_file->fd);
}
static void history_file_update(struct stats_file *data_file,
--
2.7.4
------------------------------
Message: 8
Date: Thu, 1 Dec 2016 14:47:50 +0000
From: "Blanquicet-Melendez Jose (MM)"
<jose.blanquicet-melen...@magnetimarelli.com>
To: Patrik Flykt <patrik.fl...@linux.intel.com>, Feng Wang
<wan...@nestlabs.com>
Cc: "connman@lists.01.org" <connman@lists.01.org>
Subject: RE: [PATCH 1/2] dhcpv6: Return -EISCONN when the expiry time
is inifinite
Message-ID: <8c2fcb5d084b4e9f92b335acacb41...@mxpm1fgaw.fgremc.it>
Content-Type: text/plain; charset="utf-8"
Hi,
> Thanks very much for testing! And pointing out the issue!
>
> Both patches have been applied.
>
compiling this patch with gcc version 5.3.0 configured for target
arm-poky-linux-gnueabi I get error "comparison between signed and unsigned
integer expressions [-Werror=sign-compare]". In the past I was using version
4.8.4 and this error did not appear.
In addition but not related with this patch I get:
/opt/sources/connman/src/iptables.c: In function 'iptables_add_chain':
/opt/sources/connman/src/iptables.c:622:10: error: cast increases required
alignment of target type [-Werror=cast-align]
error = (struct error_target *) entry_head->elems;
^
/opt/sources/connman/src/iptables.c:640:13: error: cast increases required
alignment of target type [-Werror=cast-align]
standard = (struct ipt_standard_target *) entry_return->elems;
^
/opt/sources/connman/src/iptables.c: In function 'find_existing_rule':
/opt/sources/connman/src/iptables.c:982:12: error: cast increases required
alignment of target type [-Werror=cast-align]
xt_e_m = (struct xt_entry_match *)entry_test->elems;
^
/opt/sources/connman/src/iptables.c:1014:17: error: cast increases required
alignment of target type [-Werror=cast-align]
tmp_xt_e_m = (struct xt_entry_match *)tmp_e->elems;
^
/opt/sources/connman/src/iptables.c: In function 'dump_match':
/opt/sources/connman/src/iptables.c:1275:10: error: cast increases required
alignment of target type [-Werror=cast-align]
match = (struct xt_entry_match *) entry->elems;
Has someone updated the gcc version and getting these errors?
Regards,
Jose Blanquicet
VISITA IL NOSTRO SITO WEB! - VISIT OUR WEB SITE! www.magnetimarelli.com
Confidential Notice: This message - including its attachments - may contain
proprietary, confidential and/or legally protected information and is intended
solely for the use of the designated addressee(s) above. If you are not the
intended recipient be aware that any downloading, copying, disclosure,
distribution or use of the contents of the above information is strictly
prohibited. If you have received this communication by mistake, please forward
the message back to the sender at the email address above, delete the message
from all mailboxes and any other electronic storage medium and destroy all
copies. Disclaimer Notice: Internet communications cannot be guaranteed to be
safe or error-free. Therefore we do not assure that this message is complete or
accurate and we do not accept liability for any errors or omissions in the
contents of this message.
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
connman@lists.01.org
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 14, Issue 2
**************************************
