Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe 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: Python3 support (Daniel Wagner)
2. Re: Any connman API for WiFi WPS process? (Daniel Wagner)
3. [PATCH] coding-style: Update M8 about g_malloc use (Daniel Wagner)
4. Re: [PATCH 0/3] Fix WireGuard fallouts (Daniel Wagner)
5. [PATCH] Revert "timeserver: Reload nameservers when service nameservers
change"
(Daniel Wagner)
----------------------------------------------------------------------
Date: Tue, 19 Nov 2019 08:15:08 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: Python3 support
To: nick83ola <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi,
On Mon, Nov 18, 2019 at 04:18:45PM +0000, nick83ola wrote:
> how is the status of python3 support in connman?
ConnMan itself doesn't depend on Python at all. We got a bunch of test
scripts for developing which are still Python 2. I just send out and
patch which adds Python3 support to the scripts.
> -> python2.7 will be EOL in january 2020...
Upstream yes, downstream Python2 will life much longer...
Thanks,
Daniel
------------------------------
Date: Tue, 19 Nov 2019 08:18:09 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: Any connman API for WiFi WPS process?
To: JH <[email protected]>
Cc: connman <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi,
On Tue, Nov 19, 2019 at 05:40:33PM +1100, JH wrote:
> I think connman can catch WiFi WPS broadcasting message and extract
> WiFi network name and password, are there any dbus API to find the
> WiFi network name and password during WiFi WPS process?
Have a look at the the Agent API. From the examples:
Requesting a passphrase for a WPA2 network with WPS alternative:
RequestInput("/service3",
{ "Passphrase" : { "Type" : "psk",
"Requirement" : "mandatory",
"Alternates" : [ "WPS" ]
},
"WPS" : { "Type" : "wpspin",
"Requirement" : "alternate"
}
}
==> { "WPS" : "123456" }
Requesting a passphrase for a WPA2 network with WPS alternative
after an error on the previous one:
RequestInput("/service3",
{ "Passphrase" : { "Type" : "psk",
"Requirement" : "mandatory",
"Alternates" : [ "WPS" ]
},
"WPS" : { "Type" : "wpspin",
"Requirement" : "alternate"
}
"PreviousPassphrase" :
{ "Type" : "wpspin",
"Requirement" : "informational",
"Value" : "123456"
}
Thanks,
Daniel
------------------------------
Date: Tue, 19 Nov 2019 08:42:03 +0100
From: Daniel Wagner <[email protected]>
Subject: [PATCH] coding-style: Update M8 about g_malloc use
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Message-ID: <[email protected]>
Document the useles effort to handle small memory allocations. Even
the small test program below shows glibc's malloc wont return a NULL
allocation. The
program will be killed by the OOM.
int main(int argc, char *argv[])
{
while (1) {
if (!malloc(16))
exit(3);
}
return 0;
}
$ ./malloc
[1] 25788 killed ./malloc
$ echo $?
137
[ 2729.844036] Out of memory: Killed process 25745 (malloc)
total-vm:15131480kB, anon-rss:14977108kB, file-rss:948kB, shmem-rss:0kB
[ 2730.091798] oom_reaper: reaped process 25745 (malloc), now anon-rss:0kB,
file-rss:0kB, shmem-rss:0kB
Linux userland system programming is different to embedded systems
where any sized malloc can and *will* fail.
---
doc/coding-style.txt | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/doc/coding-style.txt b/doc/coding-style.txt
index 97410ce72584..c2fdc717a14e 100644
--- a/doc/coding-style.txt
+++ b/doc/coding-style.txt
@@ -155,10 +155,19 @@ for (i = 0; i < 3; i++) {
}
-M8: Use g_try_malloc instead of g_malloc
-========================================
-When g_malloc fails, the whole program would exit. Most of time, this is not
-the expected behavior, and you may want to use g_try_malloc instead.
+M8: Abort if small allocation fail
+==================================
+When g_malloc fails, the whole program would exit. Small allocations
+are very unlikely to fail and if an allocations is not possible, it is
+very likely the error code can't recover from this
+situation. Furthermore, many of the error paths are not tested at
+all. Instead use g_malloc() when the allocation fails and rely on an
+external watchdog to restart the program.
+
+Furthermore, Glib's functions such as g_strdup use g_malloc which
+obviously terminates the program anyway.
+
+For large allocation using g_try_malloc is still the right choice.
Example:
additional = g_try_malloc(len - 1); // correct
--
2.24.0
------------------------------
Date: Tue, 19 Nov 2019 08:51:19 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH 0/3] Fix WireGuard fallouts
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
All three patches applied.
------------------------------
Date: Tue, 19 Nov 2019 08:55:16 +0100
From: Daniel Wagner <[email protected]>
Subject: [PATCH] Revert "timeserver: Reload nameservers when service
nameservers change"
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Message-ID: <[email protected]>
This reverts commit da51f2d6afb09b3486bbefd3c748659b5ce4d878.
As it turns out this patch doesn't solve the issue Vivien is
seeing. It's better to go back to the original code and modify it when
needed.
---
src/service.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/service.c b/src/service.c
index 222ce277f48f..22e94f7bf3c7 100644
--- a/src/service.c
+++ b/src/service.c
@@ -974,12 +974,8 @@ static int nameservers_changed_cb(void *user_data)
service->nameservers_timeout = 0;
if ((is_idle(service->state) && !service->nameservers) ||
- is_connected(service->state)) {
+ is_connected(service->state))
dns_changed(service);
- if (service == connman_service_get_default())
- __connman_timeserver_sync(service);
- }
-
return FALSE;
}
--
2.24.0
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 49, Issue 23
***************************************
