[RFC v2 0/8] Implementation of simultaneous internet contexts activation
by Mylene JOSSERAND
This patchset updates and implements in ofono's plugin a simultaneous internet contexts activation per modem.
Thanks to these patches, we can create two (or more) contexts for one modem and activates them simultaneous (if the modem handles it).
It has been tested with a cinterion pxs8 for two contexts : one for QMI and another for PPP interface.
This is the second version. I tried to split the best I can according to previous
comments but I think it can be improved (that is why I put it in RFC again).
Thank you in advance for patch reviews.
Mylene JOSSERAND (8):
ofono: create a list of contexts
ofono: move some properties to context struct
ofono: move "network" property to context struct
ofono: add network_context to property info
ofono: remove the context struct in modem one
ofono: implementation of simultaneous APNS
ofono: add array parsing when contexts are added
ofono: set "powered" property according to value
plugins/ofono.c | 489 +++++++++++++++++++++++++++++++++++---------------------
1 file changed, 310 insertions(+), 179 deletions(-)
--
2.1.4
5 years, 1 month
[PATCH 0/9] connmand-wait-online
by Patrik Flykt
Hi,
Here is a new systemd service which waits until ConnMan gets to 'ready'
or 'online' state by placing itself before systemd's network-online.target.
This will cause services needing network to be run after the network
is actually up instead of being started after ConnMan as is the case
right now.
Cheers,
Patrik
Patrik Flykt (9):
connmand-wait-online: Add program and initial main loop
connmand-wait-online: Monitor Manager PropertyChanged signals
connmand-wait-online: Get Manager properties on startup
connmand-wait-online: Add command line options
connmand-wait-online: Add command line switch for interfaces
connmand-wait-online: Add option to ignore interfaces
connmand-wait-online: Add timeout option
build: Add connman-wait-online.service
connman.service: Remove dependencies on remote-fs.target
Makefile.am | 13 +-
src/connman-wait-online.service.in | 15 ++
src/connman.service.in | 4 +-
src/connmand-wait-online.c | 461 +++++++++++++++++++++++++++++++++++++
4 files changed, 488 insertions(+), 5 deletions(-)
create mode 100644 src/connman-wait-online.service.in
create mode 100644 src/connmand-wait-online.c
--
2.1.4
5 years, 1 month
[PATCH 0/4] Fixed Several Memory Leaks
by Saurav Babu
Saurav Babu (4):
gdbus: Fix Memory Leak
gweb: Properly handle memory failure scenarios
dhcp: Fixed Memory Leak
service: Fixed Memory Leak
gdbus/watch.c | 6 ++++++
gweb/gweb.c | 9 ++++++++-
src/dhcp.c | 6 +++++-
src/service.c | 7 ++++++-
4 files changed, 25 insertions(+), 3 deletions(-)
--
1.9.1
5 years, 1 month
[PATCH] wifi: set interface when added
by Michael Olbrich
Otherwise g_supplicant_interface_set_data(interface, NULL) is not called
for the g_suplicant interface when the wifi object is removed. As a result,
the g_suplicant interface may access the wifi object when it is already
deleted.
This is rarely a problem, because the g_suplicant interface is deleted
shortly afterwards, but occasionally a D-Bus signal arrives at the wrong
time and triggers this use after free issue.
---
plugins/wifi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/plugins/wifi.c b/plugins/wifi.c
index 2aeabfd30f3d..a98b68080fca 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -2169,6 +2169,7 @@ static void interface_added(GSupplicantInterface *interface)
if (!wifi)
return;
+ wifi->interface = interface;
g_supplicant_interface_set_data(interface, wifi);
p2p_iface_list = g_list_append(p2p_iface_list, wifi);
wifi->p2p_device = true;
--
2.6.2
5 years, 1 month
[PATCH] agent: avoid recursion in connman_agent_cancel()
by Michael Olbrich
It is possible that connman_agent_cancel() from within
connman_agent_cancel():
-> request->callback() == request_peer_authorization_reply()
-> auth_reply->peer_callback() == request_authorization_cb()
-> peer_driver->connect() returns -EBUSY (wifi->p2p_connecting == TRUE)
-> connman_peer_set_state()
with old_state == 2 and new_state == 1
-> peer_disconnect()
-> connman_agent_cancel()
Break the loop by removing the request from the list before calling the
callback funtion.
---
src/agent.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/agent.c b/src/agent.c
index d26d8dcad717..4866c8d99397 100644
--- a/src/agent.c
+++ b/src/agent.c
@@ -524,12 +524,12 @@ void connman_agent_cancel(void *user_context)
user_context) {
DBG("cancel pending %p", request);
+ agent->queue = g_list_delete_link(agent->queue,
+ list);
+
request->callback(NULL, request->user_data);
agent_request_free(request);
-
- agent->queue = g_list_delete_link(agent->queue,
- list);
}
list = next;
--
2.6.2
5 years, 1 month
[PATCH v2] gdhcp: don't call the lease added callback for OFFER
by Michael Olbrich
The lease added callback only used to determine and announce the peer
address. Without this, the peer address is announced via D-Bus before the
peer actually ueses the address.
If the first OFFER is lost, then the difference can actually be several
seconds.
---
Hi,
it took a while for me to get back to this, but here is the updated patch.
Regards,
Michael
v2: moved the lease callback instead of adding a new argument to
add_lease() (as suggested).
gdhcp/server.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gdhcp/server.c b/gdhcp/server.c
index 8574c24c4b72..f7795f7e610d 100644
--- a/gdhcp/server.c
+++ b/gdhcp/server.c
@@ -214,9 +214,6 @@ static struct dhcp_lease *add_lease(GDHCPServer *dhcp_server, uint32_t expire,
g_hash_table_insert(dhcp_server->nip_lease_hash,
GINT_TO_POINTER((int) lease->lease_nip), lease);
- if (dhcp_server->lease_added_cb)
- dhcp_server->lease_added_cb(lease->lease_mac, yiaddr);
-
return lease;
}
@@ -616,6 +613,9 @@ static void send_ACK(GDHCPServer *dhcp_server,
send_packet_to_client(dhcp_server, &packet);
add_lease(dhcp_server, 0, packet.chaddr, packet.yiaddr);
+
+ if (dhcp_server->lease_added_cb)
+ dhcp_server->lease_added_cb(packet.chaddr, packet.yiaddr);
}
static void send_NAK(GDHCPServer *dhcp_server,
--
2.6.2
5 years, 1 month
[PATCH] service: Set search domains regardless of connected state
by Patrik Flykt
Search domains will be added before the service gets connected, thus
allow them to be set. The interface index ensures that correct search
domains will be used. This change also fixes issues where search domains
were not appended correctly to the DNS lookups.
Reported by Mike Purvis.
---
src/service.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/service.c b/src/service.c
index e3317dd..be38364 100644
--- a/src/service.c
+++ b/src/service.c
@@ -1027,9 +1027,6 @@ static int searchdomain_add_all(struct connman_service *service)
{
int index, i = 0;
- if (!is_connected(service))
- return -ENOTCONN;
-
index = __connman_service_get_index(service);
if (index < 0)
return -ENXIO;
--
2.1.4
5 years, 1 month
[PATCH 0/5 v2] Properly configure search domains for resolvers
by pasi.sjoholm＠jolla.com
From: Pasi Sjöholm <pasi.sjoholm(a)jollamobile.com>
While debugging append_domain issue reported Vladimir Pavljuchenkov
I noticed that dnsproxy did not do any appended_domain-queries with
nameserver/resolvers configured by IPv6-infrastructure.
After these five small patches the things seems to be right
and all the resolvers are queried with configured search domains
(DNSSL, DHCPv4/6 and manually configured).
DHCPv4/6: siirappi.com
DNSSL: google.com
Before:
--cut--
IP 192.168.189.99.57437 > 192.168.189.1.53: 54758+ A? bz. (20)
IP 192.168.189.99.57437 > 192.168.189.1.53: 24311+ A? bz.siirappi.com. (33)
IP6 2001:470:28:241:2456:88bd:a205:211c.31364 > 2001:470:28:241::1.53: 25855+ A? bz. (20)
IP 192.168.189.1.53 > 192.168.189.99.57437: 54758 0/1/0 (85)
IP 192.168.189.1.53 > 192.168.189.99.57437: 24311 1/0/0 A 1.2.3.4 (49)
IP6 2001:470:28:241::1.53 > 2001:470:28:241:2456:88bd:a205:211c.31364: 25855 0/0/0 (20)
--cut--
After the patches:
--cut--
IP 192.168.189.99.57437 > 192.168.189.1.53: 62803+ A? bz. (20)
IP 192.168.189.99.57437 > 192.168.189.1.53: 56164+ A? bz.siirappi.com. (33)
IP 192.168.189.99.57437 > 192.168.189.1.53: 56164+ A? bz.google.com. (31)
IP6 2001:470:28:241:2456:88bd:a205:211c.33378 > 2001:470:28:241::1.53: 62803+ A? bz. (20)
IP6 2001:470:28:241:2456:88bd:a205:211c.33378 > 2001:470:28:241::1.53: 56164+ A? bz.siirappi.com. (33)
IP6 2001:470:28:241:2456:88bd:a205:211c.33378 > 2001:470:28:241::1.53: 56164+ A? bz.google.com. (31)
IP 192.168.189.1.53 > 192.168.189.99.57437: 62803 0/0/0 (20)
IP 192.168.189.1.53 > 192.168.189.99.57437: 56164 1/0/0 A 1.2.3.4 (49)
IP 192.168.189.1.53 > 192.168.189.99.57437: 56164 NXDomain 0/1/0 (81)
IP6 2001:470:28:241::1.53 > 2001:470:28:241:2456:88bd:a205:211c.33378: 62803 0/0/0 (20)
IP6 2001:470:28:241::1.53 > 2001:470:28:241:2456:88bd:a205:211c.33378: 56164 1/0/0 A 1.2.3.4 (49)
IP6 2001:470:28:241::1.53 > 2001:470:28:241:2456:88bd:a205:211c.33378: 56164 NXDomain 0/0/0 (31)
--cut--
Pasi Sjöholm (5):
dnsproxy: Rename append_domain() to update_domain()
dnsproxy: Remove domains from dns server domain list when needed
service: Reconfigure search domains when nameservers have been
modified
resolver: Reorder call to __connman_service_nameserver_append()
resolver: Readd search domains back when resolvers are redone
src/dnsproxy.c | 25 ++++++++++++++++++++++---
src/resolver.c | 46 ++++++++++++++++++++++++++++++++++------------
src/service.c | 12 ++++++------
3 files changed, 62 insertions(+), 21 deletions(-)
--
2.5.0
5 years, 1 month
Re: [PATCH] Ensure that NameServer ordering is correct when not using the DNS proxy
by Patrik Flykt
On Mon, 2015-11-02 at 15:08 +0000, Sam Nazarko wrote:
> ---
> src/resolver.c | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
When applying, I only get:
Applying: Ensure that NameServer ordering is correct when not using the
DNS proxy
error: patch failed: src/resolver.c:91
error: src/resolver.c: patch does not apply
If I try to apply it using patch -p1 I get:
patching file src/resolver.c
Hunk #1 FAILED at 91.
1 out of 1 hunk FAILED -- saving rejects to file src/resolver.c.rej
Cheers,
Patrik
> diff --git a/src/resolver.c b/src/resolver.c
> index 6a64938..5f08ce3 100644
> --- a/src/resolver.c
> +++ b/src/resolver.c
> @@ -91,15 +91,9 @@ static int resolvfile_export(void)
>
> content = g_string_new("# Generated by Connection Manager\n");
>
> - /*
> - * Domains and nameservers are added in reverse so that the most
> - * recently appended entry is the primary one. No more than
> - * MAXDNSRCH/MAXNS entries are used.
> - */
> -
> - for (count = 0, list = g_list_last(resolvfile_list);
> + for (count = 0, list = g_list_first(resolvfile_list);
> list && (count < MAXDNSRCH);
> - list = g_list_previous(list)) {
> + list = g_list_next(list)) {
> struct resolvfile_entry *entry = list->data;
>
> if (!entry->domain)
> --
> 2.1.0
> _______________________________________________
> connman mailing list
> connman(a)connman.net
> https://lists.connman.net/mailman/listinfo/connman
5 years, 1 month
