[PATCH] connman.service.in: add CAP_SYS_ADMIN for setdomainname
by Julien Massot
From: Julien Massot <jmassot(a)softbankrobotics.com>
connman fail to set the domain name using setdomainname on
systemd based system.
The reason is that setdmainname requires CAP_SYS_ADMIN
---
src/connman.service.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/connman.service.in b/src/connman.service.in
index 9f5c10fe..7376346e 100644
--- a/src/connman.service.in
+++ b/src/connman.service.in
@@ -13,7 +13,7 @@ BusName=net.connman
Restart=on-failure
ExecStart=@sbindir@/connmand -n
StandardOutput=null
-CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SYS_TIME CAP_SYS_MODULE
+CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SYS_TIME CAP_SYS_MODULE CAP_SYS_ADMIN
ProtectHome=true
ProtectSystem=full
--
2.20.1
3 years, 2 months
Stale Wifi service and network not being destroyed?
by Henrik Persson
Hi,
I'm doing some post mortem of a connman process which started to behave
strangely and didn't manage to connect to the Wifi network it should have
connected to for a week (before I forced a core dump and restarted it, which
made everything work again). The error returned to the other process over
DBus after calling service.Connect() was -EIO, which after some investigation
into the source code seems to indicate that the error originates from
service_complete().
Digging into the core dump I found some things that could explain the error:
(gdb) print ((struct connman_service *)(service_list->next->next->data))->name
$157 = 0x1714f38 "B<snip>-2G"
(gdb) print ((struct connman_service *)(service_list->next->next->data))->network
$158 = (struct connman_network *) 0x1722588
(gdb) print ((struct connman_service *)(service_list->next->next->data))->network->device
$159 = (struct connman_device *) 0x0
(gdb) print ((struct connman_service *)(service_list->next->next->data))->network->driver
$160 = (struct connman_network_driver *) 0x0
(gdb) print ((struct connman_service *)(service_list->next->next->data))->network->name
$161 = 0x17224b8 "B<snip>-2G"
network->{driver,device} being NULL explains why -EIO is returned. I'm thinking
that should not happen. I also found another connman_network when digging
into what the supplicant interface was seeing, and that's not the same network
that the service holds a reference to..
(gdb) print ((struct connman_network *)((struct wifi_data *)((GSupplicantInterface *)interface_table->values[1])->data)->networks[0]->next->next->next->next->next->next->next->next->next->next->next->data)->name
$168 = 0x173cc30 "B<snip>-2G"
(gdb) print ((struct connman_network *)((struct wifi_data *)((GSupplicantInterface *)interface_table->values[1])->data)->networks[0]->next->next->next->next->next->next->next->next->next->next->next->data)
$169 = (struct connman_network *) 0x172d310
So, I don't have any logs that tells me anything useful since debugging was not
enabled, but I do have the core dump. It sort of feels like a missing deref on that
service somewhere.
Monitoring dbus during a connection attempt:
‣ Type=method_call Endian=l Flags=0 Version=1 Priority=0 Cookie=239369
Sender=:1.12 Destination=net.connman Path=/net/connman/service/wifi_24[..snip..]3247_managed_psk Interface=net.connman.Service Member=Connect
UniqueName=:1.12
MESSAGE "" {
};
‣ Type=signal Endian=l Flags=1 Version=1 Priority=0 Cookie=530610
Sender=:1.10 Path=/net/connman/service/wifi_24[..snip..]3247_managed_psk Interface=net.connman.Service Member=PropertyChanged
UniqueName=:1.10
MESSAGE "sv" {
STRING "State";
VARIANT "s" {
STRING "idle";
};
};
‣ Type=method_call Endian=l Flags=0 Version=1 Priority=0 Cookie=530611
Sender=:1.10 Destination=:1.12 Path=/ Interface=net.connman.Agent Member=RequestInput
UniqueName=:1.10
MESSAGE "oa{sv}" {
OBJECT_PATH "/net/connman/service/wifi_24[..snip..]3247_managed_psk";
ARRAY "{sv}" {
DICT_ENTRY "sv" {
STRING "Passphrase";
VARIANT "a{sv}" {
ARRAY "{sv}" {
DICT_ENTRY "sv" {
STRING "Type";
VARIANT "s" {
STRING "psk";
};
};
DICT_ENTRY "sv" {
STRING "Requirement";
VARIANT "s" {
STRING "mandatory";
};
};
DICT_ENTRY "sv" {
STRING "Alternates";
VARIANT "as" {
ARRAY "s" {
STRING "WPS";
};
};
};
};
};
};
DICT_ENTRY "sv" {
STRING "WPS";
VARIANT "a{sv}" {
ARRAY "{sv}" {
DICT_ENTRY "sv" {
STRING "Type";
VARIANT "s" {
STRING "wpspin";
};
};
DICT_ENTRY "sv" {
STRING "Requirement";
VARIANT "s" {
STRING "alternate";
};
};
};
};
};
};
};
‣ Type=method_return Endian=l Flags=1 Version=1 Priority=0 Cookie=239370 ReplyCookie=530611
Sender=:1.12 Destination=:1.10
UniqueName=:1.12
MESSAGE "a{sv}" {
ARRAY "{sv}" {
DICT_ENTRY "sv" {
STRING "Passphrase";
VARIANT "s" {
STRING <redacted>;
};
};
};
};
‣ Type=signal Endian=l Flags=1 Version=1 Priority=0 Cookie=530612
Sender=:1.10 Path=/net/connman/service/wifi_24[..snip..]3247_managed_psk Interface=net.connman.Service Member=PropertyChanged
UniqueName=:1.10
MESSAGE "sv" {
STRING "State";
VARIANT "s" {
STRING "failure";
};
};
‣ Type=error Endian=l Flags=1 Version=1 Priority=0 Cookie=530613 ReplyCookie=239369
Sender=:1.10 Destination=:1.12
ErrorName=net.connman.Error.Failed ErrorMessage="Input/output error"
UniqueName=:1.10
MESSAGE "s" {
STRING "Input/output error";
};
‣ Type=method_call Endian=l Flags=0 Version=1 Priority=0 Cookie=239371
Sender=:1.12 Destination=net.connman Path=/net/connman/service/wifi_24[..snip..]3247_managed_psk Interface=net.connman.Service Member=Remove
UniqueName=:1.12
MESSAGE "" {
};
‣ Type=method_return Endian=l Flags=1 Version=1 Priority=0 Cookie=530614 ReplyCookie=239371
Sender=:1.10 Destination=:1.12
UniqueName=:1.10
MESSAGE "" {
};
And that's about all I got so far, but it was stuck in this state for at least
a week and a new wifi scan was triggered periodically during that time.
Any pointers, suggestions, comments, etc that could either tell me that
I'm doing something wrong interacting with connman, or where to look
further?
I'm on connman 1.35 btw because of reasons, but I didn't find anything
in the connman history since that point that should have fixed this. But
I'm gladly proven wrong.
Thanks,
--
Henrik
3 years, 2 months
Bluetooth services does not appear
by Ferry Toth
I'm trying to make my Edison board connect to my cell phone. The cell
phone is set to do tethering over bluetooth.
I can connect my PC (which uses network-manager) to the phone . So the
phone side configuration seems to be working fine.
Also, on the Edison side I can pair/trust/connect bluetooth to the phone
fine, or I can connect to the Edison from the phone side. In neither
case does a bluetooth service appear in connmanctl. In connmanctl I ahve
a bluetooth technology and can power it on/off fine.
Does anybody know what I am doing wrong here? Any suggestions are welcomed.
Note the Edison is not running it's factory firmware, but a rather
recent Yocto Sumo.
root@edison:~# uname -a
Linux edison 4.20.0-rc5-edison-acpi-standard #1 SMP Wed Dec 5 21:29:04
UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
root@edison:~# bluetoothctl -v
bluetoothctl: 5.48
root@edison:~# /usr/sbin/connmand -v
1.35
3 years, 2 months
The role of connection manager
by JH
Hi,
Does ConnMan provide C API to setup WiFi and LTE connection? Or it is
not necessary to use API but use configuration in main.conf?
I am currently debating with my colleague about if it is necessary to
use connection manager in a small embedded Linux device with network
interfaces of LTE, WiFi and BLE. To cut the long story short, I
strongly proposed to use ConnMan and my colleague is against it, his
argument was connection manager should only be used in desktop not for
embedded system, he wanted to set up WiFi directly from
wpa_supplicant, run LTE connection directly from modem gpio. From my
point of view, set up WiFi directly from wpa_supplicant is fine, but
switch on / off LTE directly from gpio could cause serious
consequences, the application should never interact LTE directly
through low level of GPIO, it'll likely to break the integrity of the
kernel and Linux system where other parts of the kernel or system
access the modem via ioctl communication. The manager will make the
final call. As an embedded developer, none of us have experience in
connection manager, appreciate your comments.
Thank you.
JH
3 years, 2 months
How difficult to build ConnMan, oFono on OpenWrt?
by JH
Has anyone built ConnMan and Ofono on OpenWrt?
This is an agony, I want to try ConnMan on a small Linux device with
LTE, WiFi and BLE, the limited sizes of RAM and Flash does not allow
me to run Debian armhf, I can only run OpenWrt, but there is no
ConnMan package in OpenWrt, I am surprised there is no one in OpenWrt
to run ConnMan, I have to check if it is feasible to build and to run
both ConnMan and oFono on OpenWrt. Appreciate any tips and your
expertise advice.
Thank you.
Kind regards,
JH
3 years, 2 months
Ethernet issues since upgrade to 1.36
by Yasser
Hi All,
I have been having some issues since I upgraded to 1.36. I start with the
ethernet cable connected and the interface up and running. The wifi is not
connected. If I disconnect the cable and reconnect the cable after a short
delay everything is fine, but if I repeat this procedure the interface does
not come up but stays down and will only come up if I disconnect and
reconnect the ethernet cable again. I did not have this issue with 1.35.
The log file shows the following messages:
root@smard-sec: tail -F /var/log/messages
libphy: himii:00 - Link is Down
Feb 21 16:11:58 smard-sec user.info kernel: libphy: himii:00 - Link is Down
Feb 21 16:11:58 smard-sec daemon.info connmand[1117]: eth0 {RX} 215095
packets 311631240 bytes
Feb 21 16:11:58 smard-sec daemon.info connmand[1117]: eth0 {TX} 142690
packets 12100139 bytes
Feb 21 16:11:58 smard-sec daemon.info connmand[1117]: eth0 {update} flags
36867 <UP>
Feb 21 16:11:58 smard-sec daemon.info connmand[1117]: eth0 {newlink} index
2 address 00:19:82:E5:E9:6A mtu 1500
Feb 21 16:11:58 smard-sec daemon.info connmand[1117]: eth0 {newlink} index
2 operstate 2 <DOWN>
Feb 21 16:11:58 smard-sec daemon.info connmand[1117]: eth0 {del} address
10.0.9.171/20 label eth0
Feb 21 16:11:58 smard-sec daemon.info connmand[1117]: eth0 {del} route
10.0.0.0 gw 0.0.0.0 scope 253 <LINK>
libphy: himii:00 - Link is Up - 100/Full
Feb 21 16:12:10 smard-sec user.info kernel: libphy: himii:00 - Link is Up -
100/Full
Feb 21 16:12:10 smard-sec daemon.info connmand[1117]: eth0 {RX} 215096
packets 311631327 bytes
Feb 21 16:12:10 smard-sec daemon.info connmand[1117]: eth0 {TX} 142690
packets 12100139 bytes
Feb 21 16:12:10 smard-sec daemon.info connmand[1117]: eth0 {update} flags
102467 <UP,RUNNING,LOWER_UP>
Feb 21 16:12:10 smard-sec daemon.info connmand[1117]: eth0 {newlink} index
2 address 00:19:82:E5:E9:6A mtu 1500
Feb 21 16:12:10 smard-sec daemon.info connmand[1117]: eth0 {newlink} index
2 operstate 6 <UP>
^C
root@smardtv-dip4090-sec:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:19:82:E5:E9:6A
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:215126 errors:0 dropped:976 overruns:0 frame:0
TX packets:142690 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:311641548 (297.2 MiB) TX bytes:12100139 (11.5 MiB)
Interrupt:103
wlan0 Link encap:Ethernet HWaddr 18:C8:E7:21:9A:5E
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:77 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
3 years, 2 months
Support LTE and WiFi network switch
by JH
Hi,
Sorry for asking basic questions, I am new to connman and the list,
but it seems to me that connman targets to the embedded system, a
perfect light weight network management library for the embedded
system. I am using ublox SARA LTE Cat M1 / NB1 module, EMMY-W1 WiFi
and BLE in a tiny Linux embedded system running on C / C++
applications, has anyone known if there are drivers that connman can
support those modules? Anything I need be aware of before using the
connman?
I also need network switching capability, the LTE is the default
network interface, when the system detects WiFi is available, it
switches from LTE to WiFi network connection immediately which is
similar to the mobile phone to automatically switch from LTE to the
WiFi. I think the connman must has that capacity as well, but correct
me if I am wrong.
The dbus is a desktop bus as the name implies, is it mandatory that
connman has to use dbus? I heard there are problems for embedded
system to use dbus, but please correct me.
Are there any preference of Linux distribution that will be the best
for running connman? I have been thinking to use either Debian armhf
or OpenWrt, appreciate your comments.
Thank you.
Kind regards,
jupiter
3 years, 2 months
[Patch][gsupplicant]Added support for auth type "ttls" abd phase 2 value "GTC" incase of 802.1x Security for Peap
by Rahul Jain
Dear Daniel,
From: Rahul Jain <rahul.jain(a)samsung.com>
Date: Mon, 18 Feb 2019 17:53:16 +0530
Subject: [PATCH] [Patch][gsupplicant]Added support for auth type ttls abd
phase 2 value GTC incase of 802.1x Security for Peap
Signed-off-by: Rahul Jain <rahul.jain(a)samsung.com>
---
gsupplicant/supplicant.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index b814b32..da8c52e 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -4698,7 +4698,9 @@ static void add_network_security_peap(DBusMessageIter *dict,
}
- if (g_str_has_prefix(ssid->phase2_auth, "EAP-")) {
+ if(g_strcmp0(ssid->phase2_auth, "GTC") == 0 && g_strcmp0(ssid->eap, "ttls") == 0)
+ phase2_auth = g_strdup_printf("autheap=%s", ssid->phase2_auth);
+ else if (g_str_has_prefix(ssid->phase2_auth, "EAP-")) {
phase2_auth = g_strdup_printf("autheap=%s",
ssid->phase2_auth + strlen("EAP-"));
} else
--
2.7.4
3 years, 2 months
[PATCH] Fix faulty error handling in inet.c
by Matthias Berndt
[PATCH] Fix faulty error handling in inet.c
Hi,
I was recently trying to run connman on postmarketOS, and it crashed
while setting up the routes for the wifi connection. I ran it again in
gdb and while I couldn't get a full stacktrace, I did see that it
crashes because it passes a NULL pointer to freeaddrinfo.
So I took a look at the source code and went through all the calls to
that function in connman. There aren't that many, and they all have
error handling code to prevent this - except for one. The attached
patch should fix it.
3 years, 2 months
