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. [PATCH] inet: Only try to read file contents if it exits
(Daniel Wagner)
2. Re: [PATCH v2] rtnl: retry to add ether interface after
renaming (Daniel Wagner)
3. Re: [PATCH] inet: Only try to read file contents if it exits
(Daniel Wagner)
4. Re: [PATCH] nat: Set file offset back to 0 before writing
ip_forward (Neil MacLeod)
5. Re: [PATCH] nat: Set file offset back to 0 before writing
ip_forward (Daniel Wagner)
6. Re: [PATCH] inet: Only try to read file contents if it exits
(Daniel Wagner)
7. Re: [PATCH v2 3/3] Pull pacrunner forward to mozjs38
(Jeremy Linton)
8. Re: [PATCH v2 3/3] Pull pacrunner forward to mozjs38
(Daniel Wagner)
9. Re: Connman to control OpenVPN connection (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Mon, 24 Apr 2017 21:06:31 +0200
From: Daniel Wagner <[email protected]>
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Subject: [PATCH] inet: Only try to read file contents if it exits
Message-ID: <[email protected]>
When the file doesn't exits we get
Cannot read /proc/net/pnp Failed to open file '/proc/net/pnp': No such
file or directory
in the log.
---
src/inet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/inet.c b/src/inet.c
index 99151b0537a9..b283db89f4a0 100644
--- a/src/inet.c
+++ b/src/inet.c
@@ -2997,7 +2997,8 @@ static int get_nfs_server_ip(const char *cmdline_file,
const char *pnp_file,
goto out;
}
- if (!g_file_get_contents(pnp_file, &pnp, NULL, &error)) {
+ if (g_file_test(pnp_file, G_FILE_TEST_EXISTS) &&
+ !g_file_get_contents(pnp_file, &pnp, NULL, &error)) {
connman_error("%s: Cannot read %s %s\n", __func__,
pnp_file, error->message);
goto out;
--
2.9.3
------------------------------
Message: 2
Date: Mon, 24 Apr 2017 21:10:17 +0200
From: Daniel Wagner <[email protected]>
To: Dmitry Rozhkov <[email protected]>,
[email protected]
Subject: Re: [PATCH v2] rtnl: retry to add ether interface after
renaming
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Dmitry,
On 04/21/2017 10:04 AM, Dmitry Rozhkov wrote:
> Changes in v2:
> - before re-evaluation make sure the already known interface is
> of unknown device type which indicates that it has been
> blacklisted.
Applied this version instead of v1. Luckily I haven't pushed the v1 :)
Thanks,
Daniel
------------------------------
Message: 3
Date: Mon, 24 Apr 2017 21:11:27 +0200
From: Daniel Wagner <[email protected]>
To: [email protected]
Subject: Re: [PATCH] inet: Only try to read file contents if it exits
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 04/24/2017 09:06 PM, Daniel Wagner wrote:
> When the file doesn't exits we get
>
> Cannot read /proc/net/pnp Failed to open file '/proc/net/pnp': No such
> file or directory
>
> in the log.
Patch applied.
------------------------------
Message: 4
Date: Mon, 24 Apr 2017 20:12:02 +0100
From: Neil MacLeod <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] nat: Set file offset back to 0 before writing
ip_forward
Message-ID:
<CAFbqK8mgGVdSLFptoZj79HwSWfYu=putuxj9ewwnr0pwtzt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
That's fine with me, Daniel. Many thanks!
On 24 April 2017 at 19:18, Daniel Wagner <[email protected]> wrote:
> Kernel versions >= 4.5 have changed the default behavior[1] for file
> offset handling on crop/says fs to strict write position handling:
>
> Respect file position when writing sysctl strings. Multiple writes
> will append to the sysctl value buffer. Anything past the max length
> of the sysctl value buffer will be ignored. Writes to numeric sysctl
> entries must always be at file position 0 and the value must be
> fully contained in the buffer sent in the write syscall.
>
> We first read from /proc/sys/net/ipv4/ip_forward before writing to the
> file. Without the lseek to 0 first the write is silentenly ignored.
>
> Bug report from Neil MacLeod <[email protected]>.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/
> linux-stable.git/commit/?id=41662f5cc55335807d39404371cfcbb1909304c4
> ---
>
> Hi,
>
> I have 'written' this version of the fix. Mostly pimped the commit
> message and added error handling to Neil's version.
>
> @Neil: I hope that is okay with you.
>
> cheers,
> Daniel
>
> src/nat.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/nat.c b/src/nat.c
> index 4c1f8583d2f1..fb557101ea31 100644
> --- a/src/nat.c
> +++ b/src/nat.c
> @@ -54,6 +54,9 @@ static int enable_ip_forward(bool enable)
> if (!value) {
> if (read(f, &value, sizeof(value)) < 0)
> value = 0;
> +
> + if (lseek(f, 0, SEEK_SET) < 0)
> + return -errno;
> }
>
> if (enable) {
> --
> 2.9.3
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20170424/646840bd/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 24 Apr 2017 21:14:45 +0200
From: Daniel Wagner <[email protected]>
To: Neil MacLeod <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] nat: Set file offset back to 0 before writing
ip_forward
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 04/24/2017 09:12 PM, Neil MacLeod wrote:
> That's fine with me, Daniel. Many thanks!
In this case. Patch applied an pushed.
Thanks!
Daniel
------------------------------
Message: 6
Date: Mon, 24 Apr 2017 21:17:42 +0200
From: Daniel Wagner <[email protected]>
To: [email protected]
Subject: Re: [PATCH] inet: Only try to read file contents if it exits
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
BTW, this one slipped into the push. The idea was to wait a day or two
but well... sorry about it.
------------------------------
Message: 7
Date: Mon, 24 Apr 2017 14:59:57 -0500
From: Jeremy Linton <[email protected]>
To: Daniel Wagner <[email protected]>, [email protected]
Cc: [email protected]
Subject: Re: [PATCH v2 3/3] Pull pacrunner forward to mozjs38
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi,
On 04/24/2017 01:45 PM, Daniel Wagner wrote:
> Hi Jeremy,
>
> [ I was applying all the patches (fixed up those nitpickings I listed)
> but this one needs more 'love' ]
So, that means I don't need to re-post those two right?
>
> Please prefix with 'build'.
>
> On 04/19/2017 07:24 PM, Jeremy Linton wrote:
>> Mozjs185 is getting really old and unsupported. Newer versions
>> of the mozjs JSAPI are C++ based. So we convert the plugin to
>> C++ and then apply necessarily API changes so that it can be built
>> with the more recent mozjs38. For example we now need to "root"
>> values being passed into the API in order to satisfy the JSAPI
>> garbage collection rules. Further, a number of the APIs have been
>> tweaked and moved into the JS namespace, so we namespace them
>> appropriately and adjust their parameters.
>>
>> Signed-off-by: Jeremy Linton <[email protected]>
>
> Again no SoB.
>
>
>> ---
>> Makefile.am | 15 +++---
>> configure.ac | 4 +-
>> plugins/{mozjs.c => mozjs.cc} | 109
>> ++++++++++++++++++++++--------------------
>> 3 files changed, 68 insertions(+), 60 deletions(-)
>> rename plugins/{mozjs.c => mozjs.cc} (59%)
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index ee84b75..65cc8c9 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -31,9 +31,10 @@ endif
>> if MOZJS
>> js_sources = src/js_funcs.c
>> builtin_modules += mozjs
>> -builtin_sources += plugins/mozjs.c
>> -builtin_cflags += @MOZJS_CFLAGS@
>> -builtin_libadd += @MOZJS_LIBS@
>> +builtin_libadd += plugins/libmozjsplugin.a @MOZJS_LIBS@ -lstdc++
>> +noinst_LIBRARIES += plugins/libmozjsplugin.a
>> +plugins_libmozjsplugin_a_SOURCES = plugins/mozjs.cc
>> +plugins_libmozjsplugin_a_CXXFLAGS = $(AM_CFLAGS) @MOZJS_CFLAGS@
>> @DBUS_CFLAGS@ @GLIB_CFLAGS@
>> endif
>>
>> if V8
>> @@ -137,16 +138,16 @@ unit_test_pacrunner_LDADD += @CURL_LIBS@
>> endif
>>
>> if MOZJS
>> -unit_test_pacrunner_SOURCES += plugins/mozjs.c
>> -
>> +unit_test_pacrunner_SOURCES += plugins/mozjs.cc
>> +unit_test_pacrunner_CXXFLAGS = $(AM_CFLAGS) @MOZJS_CFLAGS@
>> unit_test_pacrunner_LDADD += @MOZJS_LIBS@ @PTHREAD_LIBS@
>>
>> noinst_PROGRAMS += unit/test-mozjs
>>
>> unit_test_mozjs_SOURCES = unit/test-mozjs.c src/pacrunner.h \
>> src/proxy.c src/manual.c src/download.c \
>> - src/js.c plugins/mozjs.c $(js_sources)
>> -
>> + src/js.c plugins/mozjs.cc $(js_sources)
>> +unit_test_mozjs_CXXFLAGS = $(AM_CFLAGS) @MOZJS_CFLAGS@
>> unit_test_mozjs_LDADD = @MOZJS_LIBS@ @GLIB_LIBS@ @PTHREAD_LIBS@
>> endif
>>
>> diff --git a/configure.ac b/configure.ac
>> index 888c873..b2565c0 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -76,8 +76,8 @@ AM_CONDITIONAL(DUKTAPE, test "${enable_duktape}" =
>> "yes")
>> AC_ARG_ENABLE(mozjs, AC_HELP_STRING([--enable-mozjs],
>> [enable Mozilla Javascript plugin support]))
>> if (test "${enable_mozjs}" = "yes"); then
>> - PKG_CHECK_MODULES(MOZJS, mozjs185, dummy=yes,
>> - AC_MSG_ERROR(Mozilla Javascript >= 1.8 is required))
>> + PKG_CHECK_MODULES(MOZJS, mozjs-38, dummy=yes,
>> + AC_MSG_ERROR(Mozilla Javascript >= 38 is required))
>
> I have installed mozjs-45-devel on my Fedora 25 system and it was not
> recognized. It worked with mozjs-38 though. I am always strangling with
> the version checks. So I don't know how to test this correctly.
>
> The final result seems to do work. I don't have the right environment to
> test but at least it builds and the unit test are signally okay.
So, I guess this is really a messaging problem. The JSAPI churns so much
from version to version that really this should read
"Mozilla Javascript version 38 is required"
It might be possible to target 38 and 45 at the same time, but likely
that will result in #ifdefs here and there, which just get in the way
when it comes time to move it again.
------------------------------
Message: 8
Date: Mon, 24 Apr 2017 22:18:46 +0200
From: Daniel Wagner <[email protected]>
To: Jeremy Linton <[email protected]>, [email protected]
Cc: [email protected]
Subject: Re: [PATCH v2 3/3] Pull pacrunner forward to mozjs38
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 04/24/2017 09:59 PM, Jeremy Linton wrote:
> Hi,
>
> On 04/24/2017 01:45 PM, Daniel Wagner wrote:
>> Hi Jeremy,
>>
>> [ I was applying all the patches (fixed up those nitpickings I listed)
>> but this one needs more 'love' ]
>
> So, that means I don't need to re-post those two right?
Yes, no need. I'll have in my queue.
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -76,8 +76,8 @@ AM_CONDITIONAL(DUKTAPE, test "${enable_duktape}" =
>>> "yes")
>>> AC_ARG_ENABLE(mozjs, AC_HELP_STRING([--enable-mozjs],
>>> [enable Mozilla Javascript plugin support]))
>>> if (test "${enable_mozjs}" = "yes"); then
>>> - PKG_CHECK_MODULES(MOZJS, mozjs185, dummy=yes,
>>> - AC_MSG_ERROR(Mozilla Javascript >= 1.8 is required))
>>> + PKG_CHECK_MODULES(MOZJS, mozjs-38, dummy=yes,
>>> + AC_MSG_ERROR(Mozilla Javascript >= 38 is required))
>>
>> I have installed mozjs-45-devel on my Fedora 25 system and it was not
>> recognized. It worked with mozjs-38 though. I am always strangling with
>> the version checks. So I don't know how to test this correctly.
>>
>> The final result seems to do work. I don't have the right environment to
>> test but at least it builds and the unit test are signally okay.
>
> So, I guess this is really a messaging problem. The JSAPI churns so much
> from version to version that really this should read
>
> "Mozilla Javascript version 38 is required"
>
> It might be possible to target 38 and 45 at the same time, but likely
> that will result in #ifdefs here and there, which just get in the way
> when it comes time to move it again.
Ah, got it. I though that '>=' comparison indicates that also mojzs-45
works. Should this then be a '=='?
We can go with '==' 38 in the first iteration I suppose. Adding support
for newer version can be a later patch if that helps or make things simpler.
Thanks,
Daniel
------------------------------
Message: 9
Date: Mon, 24 Apr 2017 22:20:48 +0200
From: Daniel Wagner <[email protected]>
To: Florent Le Saout <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: Connman to control OpenVPN connection
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Florent,
On 04/19/2017 05:08 PM, Florent Le Saout wrote:
> I think I figured out the reproducing method.
>
> When I get the first connection, (so before the local settings file
> exist : vpn_X_X_X_X/settings) the route is always wrong.
>
> But at the second boot when the file is already there the route is
> properly setup.
>
> Please find attached the logs with proper and incorrect route setup.
>
> I guess it's trying to set the default route to the kernel before the
> vpn tunnel is actually ready ?
> Let me know if there is other points I should check or if I should add
> more logs.
Thanks for taking time digging into this. I think with this info I
should be able to see there is a problem. But just not today/tonight :)
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 18, Issue 21
***************************************
