WireGuard plugin doesn't work: __vpn_ipconfig_foreach: symbol not
found
by Evgeny Zinoviev
Hi everybody.
I'm using connman 1.38 on Void Linux with musl-libc. I was trying to
connect to my WireGuard VPN using connman but the wireguard plugin
crashes on load:
2020-12-01T20:51:31.96059 daemon.err: Dec 1 20:51:31 connman-vpnd[502]:
Can't load /usr/lib/connman/plugins-vpn/wireguard.so: Error relocating
/usr/lib/connman/plugins-vpn/wireguard.so: __vpn_ipconfig_foreach:
symbol not found
Everything else is working fine.
Please tell me how can I help with debugging and solving this issue.
Evgeny
1 year, 6 months
[PATCH] Fix hang up when connecting to a hidden network with a wrong
size name parameter
by Emmanuel Vautrin
Hello everyone,
Please find the patch below that fixes this issue:
---
src/service.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/src/service.c b/src/service.c
index 629db995..a6e8407a 100644
--- a/src/service.c
+++ b/src/service.c
@@ -5692,14 +5692,18 @@ static void request_input_cb(struct connman_service *service,
goto done;
}
- if (service->hidden && name_len > 0 && name_len <= 32) {
- device = connman_network_get_device(service->network);
- security = connman_network_get_string(service->network,
- "WiFi.Security");
- err = __connman_device_request_hidden_scan(device,
- name, name_len,
- identity, passphrase,
- security, user_data);
+ if (service->hidden) {
+ if (name_len > 0 && name_len <= 32) {
+ device = connman_network_get_device(service->network);
+ security = connman_network_get_string(service->network,
+ "WiFi.Security");
+ err = __connman_device_request_hidden_scan(device,
+ name, name_len,
+ identity, passphrase,
+ security, user_data);
+ } else {
+ err = -EINVAL;
+ }
if (err < 0)
__connman_service_return_error(service, -err,
user_data);
--
Best Regards,
Emmanuel
1 year, 6 months
[PATCH] Bugfixes
by Boleslaw Tokarski
Hi,
Bugfix patches along with their desciprions attached,
Best regards,
Bolesław Tokarski
1 year, 6 months
[PATCH v1 00/11] Set IPv6 default route
by Daniel Wagner
Currently, ConnMan relies on the kernel to set the IPv6 default route
(accept_ra=1). This works only if the system has one interface
active. Obviously, ConnMan should be in charge updating the routing
IPv6 routing table as well. This series addresses this problem.
I've still limited IPv6 testing environment, so I hope this works
not just for me.
- The first three few patches improve the logging.
- Patch 4 and 5 allow ConnMan to disable accept_ra
- Patch 6 to 10 add the missing code to forward the default route to
route selection code (connection.c)
- The last patch fixes a bug in connetion, so far ConnMan would
not clear the IPv6 default route.
Daniel Wagner (11):
inet: Add index to debug output when sending RS
inet: Improve the routing logging
connection: Improve logging
ipconfig: Factor out sysfs getter/setter
ipconfig: Disable accept_ra on managed interfaces
inet: Add source address to RS callback
network: Forward IPv6 gateway information to service
dhcpv6: Do not clear gateway address when setting IP
network: Add IPv6 gateway when setting the IPv6 address
connection: Reorder gateway set/unset operations
connection: Delete IPv6 default routes
src/6to4.c | 3 +-
src/connection.c | 80 +++++++++++++---------
src/connman.h | 3 +-
src/dhcpv6.c | 10 ++-
src/inet.c | 16 +++--
src/ipconfig.c | 175 ++++++++++++++++++++++-------------------------
src/network.c | 25 ++++++-
7 files changed, 172 insertions(+), 140 deletions(-)
--
2.29.2
1 year, 6 months
Unable to remove personal data
by Stéphane Veyret
Hello,
When connman connects to a network, it creates a directory (ethernet_*,
wifi_*, usually under the /lib/connman directory) and saves data about
the network. Some of these data may be sensitive to a GDPR (European
data protection rule) point of view. This may be, for example, the case
for the SSID or even an IP address (especially if it is a public IPv6
address).
In order to be compliant to the GDPR, we have to delete these data if
end user asks for it. Therefore, we would need to have a connman
command, using the DBUS API, which would remove all those directories
(including those for networks which are not currently connected). Does
such a command exist? If not, is it possible to open an issue, and how
(I saw that there is a Jira, but I couldn't open an issue on it because
I don't have an account)?
Regards,
Stéphane Veyret
1 year, 6 months
Re: Bridge and bond interface support
by Daniel Wagner
Hi Pieter,
On Tue, Dec 01, 2020 at 04:14:30PM +0000, Pieter Cardoen wrote:
> Dear
>
> Is it possible to use connmand to configure and enable a bridge at
> boot-time and then use connmand to manage this interface?
ConnMan creates and manages only for tethering a bridge. There is no
interface to create or manage bridges.
> Same question for bonding interfaces.
>
> I would like to use a config file like this:
> [service_br0]
> Type=bridge
> IPv4=dhcp
> IPv6=off
> ports=eth0,eth1
Bonding was deliberately left out as it targets more the data center use
cases.
Thanks,
Daniel
1 year, 6 months
[PATCH] vpn-provider: Cancel agent requests when removing VPN
by Jussi Laakkonen
If a VPN has a pending request active in the agent and connman-vpnd is
restarted or shutdown it will result in segmentation fault. This happens
because plugins and tasks are cleaned up before vpn-provider and thus,
the removal of agent driver is called after the plugins are gone and
if there is a pending request from any unloaded VPN plugin it needs to
be cancelled. Since the callback set in the agent request points to a
function in the VPN plugin following happens:
Thread 1 "connman-vpnd" received signal SIGSEGV, Segmentation fault.
0xf6716cbc in ?? ()
(gdb) bt
\#0 0xf6716cbc in ?? ()
\#1 0x0002bafc in agent_finalize_pending (reply=reply@entry=0x0,
agent=<optimized out>) at src/agent.c:121
\#2 0x0002bd80 in cancel_all_requests (agent=0x5285a0) at
src/agent.c:483
\#3 agent_unref_debug (file=0x363d4 "src/agent.c", line=647,
caller=<synthetic pointer>, agent=0x5285a0) at src/agent.c:568
\#4 agent_destroy (data=0x5285a0) at src/agent.c:647
\#5 0xf6f6e8d6 in g_hash_table_remove_all_nodes (hash_table=0x4c94e8,
notify=<optimized out>, destruction=<optimized out>) at ghash.c:552
\#6 0xf6f6fe3c in g_hash_table_remove_all_nodes (destruction=0,
notify=1, hash_table=0x4c94e8) at ghash.c:1444
\#7 g_hash_table_remove_all (hash_table=0x4c94e8) at ghash.c:1447
\#8 0x0002c442 in connman_agent_driver_unregister
(driver=driver@entry=0x49784 <agent_driver>) at src/agent.c:629
\#9 0x00024442 in __vpn_provider_cleanup () at vpn/vpn-provider.c:3416
\#10 0x0001a086 in main (argc=1, argv=0xff8c1334) at vpn/main.c:283
Therefore, the requests must be canceled at plugin driver unregister as
that gets eventually called by VPN plugin exit function via
vpn_unregister().
---
vpn/vpn-provider.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/vpn/vpn-provider.c b/vpn/vpn-provider.c
index 5d0fb2ce..be25e394 100644
--- a/vpn/vpn-provider.c
+++ b/vpn/vpn-provider.c
@@ -2984,6 +2984,12 @@ void vpn_provider_driver_unregister(struct vpn_provider_driver *driver)
if (provider && provider->driver &&
g_strcmp0(provider->driver->name,
driver->name) == 0) {
+ /*
+ * Cancel VPN agent request to avoid segfault at
+ * shutdown as the callback, if set can point to a
+ * function in the plugin that is to be removed.
+ */
+ connman_agent_cancel(provider);
provider->driver = NULL;
}
}
--
2.20.1
1 year, 6 months
Re: DSA support - bug
by Daniel Wagner
Hi Pieter,
On Tue, Dec 01, 2020 at 03:58:47PM +0000, Pieter Cardoen wrote:
> Dear
>
> I am using connmand on our embedded devices which have an on-board
> marvell switch, configured using dsa. I noticed that, using latest
> release, the network connections were not working. After debugging i
> found that this patch needed to be applied to have connmand properly
> working with dsa ports:
After looking at this code I think it's not really good as we try to
identify the type per interface name. I wonder if this could not be done
more clever.
Anyway, for the time beeing I applied your patch.
Thanks,
Daniel
1 year, 6 months
New membership
by Emmanuel Vautrin
Hello everyone,
In the past, Yasser Toor has provided you some patches on which we have worked together. As unfortunately he is working with us anymore, I will continue to provide you the new fixes, based on 1.38 integrated in our Yocto (3.2)
Best Regards,
Emmanuel Vautrin
1 year, 6 months
