Connman to control OpenVPN connection
by Florent Le Saout
Hello,
I'm trying to get vpn connection managed by connman.
I've been looking in the documentation in the sources or website, but
didn't find my answer yet.
So far, I can connect to my OpenVPN server manually via connmanctl, so I
guess my vpn config file is quite ok.
But the remaining question is about the autoconnection and link
verification.
From my understanding autoconnect, reconnect etc, that we can configure
in main config file only applies to technologies, but VPNs are not
technologies from connman perspectives, so they are listed as service
(maybe my statement here is not correct ?).
My goal is to be able, as soon as I get proper network connection,
either by ethernet, cellular or wifi technologies to get connected to my
vpn server and in case of disconnection (so implicitly a connection
check is done in background) to get reconnected.
* How to setup autoconnect and reconnect with OpenVPN (also in case we
change technology from ethernet to cellular for instance) ?
* Regarding routes, I would like to know how to apply the routes
pushed by the OpenVPN server as the default route?
* Regarding DNS server, I also would like to know how to get the DNS
pushed by the OpenVPN applied in resolv.conf ?
If my questions are unclear feel free to ask.
Below you can find more details about my setup.
Thanks,
Florent.
----------------------------------------------------------------------------
My setup is :
* connman 1.33
* connman-vpnd
* connman-plugin-vpn
* openvpn 2.3.14
My VPN config file is :
[global]
Name = OpenVPVN
Description = OepnVPN custom configuration
[provider_openvpn]
Type = OpenVPN
Name = Custom VPN
Host = MY_SERVER_IP
Domain = MY_DOMAIN
Networks =
192.168.1.0/255.255.255.0/10.8.0.1,192.168.0.0/255.255.0.0/10.8.0.1
OpenVPN.ConfigFile=/etc/openvpn/client-openvpn.conf
My VPN config stored by connman is :
connmanctl> services vpn_MY_SERVER_IP_MY_DOMAIN
/net/connman/service/vpn_MY_SERVER_IP_MY_DOMAIN
Type = vpn
Security = [ ]
State = ready
Favorite = True
Immutable = False
AutoConnect = False
Name = Custom VPN
IPv4 = [ Method=fixed, Address=10.8.0.18, Netmask=255.255.255.255,
Gateway=MY_SERVER_IP ]
IPv4.Configuration = [ Method=fixed, Address=10.8.0.18,
Netmask=255.255.255.255, Gateway=MY_SERVER_IP ]
IPv6 = [ ]
IPv6.Configuration = [ Method=off ]
Nameservers = [ 10.8.0.1 ]
Nameservers.Configuration = [ ]
Timeservers = [ ]
Timeservers.Configuration = [ ]
Domains = [ ran.com ]
Domains.Configuration = [ ]
Proxy = [ Method=direct ]
Proxy.Configuration = [ ]
Provider = [ Host=MY_SERVER_IP, Type=openvpn ]
4 years, 7 months
Connman v1.33 with systemd v230 : experiencing delay in IP assignment
by Shrikant Bobade
Hi,
I am using connman v1.33 along with systemd v230 for yocto based project.
Experiencing delay in IP assignment ranging from 20 sec. to 1.5 min.
While used earlier versions previously didn't faced such delays. So by the
time I am finding the exact change in version causing this delay issue.
Just want to check anyone experiencing such delays in IP assignments.
Any suggestions or pointers will be a great help.
Thanks
Shrikant
4 years, 10 months
[RFC v2] service: Update nameservers and timeservers with changes in IP
by Patrik Flykt
When the IP address changes, nameservers need to be removed and
re-added in order for them to pick up the changed IP address. The
same applies to timeservers, restart the query for those as well.
Reported by Måns Rullgård.
---
Much less messing around with the code if implemented this way.
Can you still test that it works identically to v1?
Cheers,
Patrik
src/service.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/src/service.c b/src/service.c
index 737a39f..ee87ad5 100644
--- a/src/service.c
+++ b/src/service.c
@@ -1961,19 +1961,26 @@ static void settings_changed(struct connman_service *service,
{
enum connman_ipconfig_type type;
- if (!allow_property_changed(service))
- return;
-
type = __connman_ipconfig_get_config_type(ipconfig);
- if (type == CONNMAN_IPCONFIG_TYPE_IPV4)
- connman_dbus_property_changed_dict(service->path,
+ if (allow_property_changed(service)) {
+ if (type == CONNMAN_IPCONFIG_TYPE_IPV4)
+ connman_dbus_property_changed_dict(service->path,
CONNMAN_SERVICE_INTERFACE, "IPv4",
append_ipv4, service);
- else if (type == CONNMAN_IPCONFIG_TYPE_IPV6)
- connman_dbus_property_changed_dict(service->path,
+ else if (type == CONNMAN_IPCONFIG_TYPE_IPV6)
+ connman_dbus_property_changed_dict(service->path,
CONNMAN_SERVICE_INTERFACE, "IPv6",
append_ipv6, service);
+ }
+
+ if (is_connected_state(service, service->state) &&
+ service == __connman_service_get_default()) {
+ nameserver_remove_all(service, type);
+ nameserver_add_all(service, type);
+
+ __connman_timeserver_sync(service);
+ }
__connman_notifier_ipconfig_changed(service, ipconfig);
}
--
2.10.2
4 years, 10 months
[PATCH] service: Don't auto connect if error is set for service.
by Saurav Babu
In the following scenario:
1. Device gets connected to an AP.
2. Goto AP's settings page and add device's MAC address in block list
3. Device gets disconnected with AP.
4. Auto Connection is again triggered with AP.
In above scenario steps 3 and 4 are repeated infintely even though
device would never connect to AP because it's MAC address is added in
block list of AP.
On the first disconnection connect-failed error is set. This patch only
blocks auto connection whenever an error is set for the service.
---
src/service.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/service.c b/src/service.c
index 737a39f..e6fdef8 100644
--- a/src/service.c
+++ b/src/service.c
@@ -3733,6 +3733,9 @@ static bool is_ignore(struct connman_service *service)
if (service->state == CONNMAN_SERVICE_STATE_FAILURE)
return true;
+ if (service->error != CONNMAN_SERVICE_ERROR_UNKNOWN)
+ return true;
+
if (!is_ipconfig_usable(service))
return true;
--
1.9.1
4 years, 11 months
two wlan interfaces - tether on one and control the other as a client?
by Matthijs Vader
Hi,
I have two wlan interfaces in linux, from a single rtl8723bu chipset running in concurrent mode. I want to use wlan0 as a normal client, and use wlan1 to host an access point. The idea is to use wlan1 to let users of our blackbox-type-product for setting up eth0 or wlan0 networking and some other config options.
Is it possible make connman enable tethering on wlan1 only, while also still using connman to configure & manage the wlan0 as well to connect to other access points?
All documentation and connmanctl instructions I've seen and use refer to the more generic wifi..
Or won't that work, and would I be therefore better of keeping connman for the client (wlan0) only. So make it ignore wlan1 by blacklisting it, and then setting up hostapd or something similar on wlan1. ?
Best regards, Matthijs
4 years, 11 months
Interface re-enumerated at runtime
by Fabio Emiliani
Dear all,
I'm facing a strange problem regarding the re-enumeration of an ethernet
interface. Please see the following log:
> root@my_hostname:/mnt/mmclog# cat log_lte.txt | grep "daemon.info
> connmand"
> Jan 1 00:00:05 daemon.info connmand[294]: Connection Manager version
> 1.28
> Jan 1 00:00:06 daemon.info connmand[294]: Checking loopback
> interface settings
> Jan 1 00:00:06 daemon.info connmand[294]: System hostname is my_hostname
> Jan 1 00:00:06 daemon.info connmand[294]: lo {newlink} index 1
> address 00:00:00:00:00:00 mtu 65536
> Jan 1 00:00:06 daemon.info connmand[294]: lo {newlink} index 1
> operstate 0 <UNKNOWN>
> Jan 1 00:00:06 daemon.info connmand[294]: sit0 {newlink} index 2
> address 00:00:00:00:08:00 mtu 1480
> Jan 1 00:00:06 daemon.info connmand[294]: sit0 {newlink} index 2
> operstate 2 <DOWN>
> Dec 24 22:34:52 daemon.info connmand[294]: eth0 {create} index 5 type
> 1 <ETHER>
> Dec 24 22:34:52 daemon.info connmand[294]: eth0 {update} flags 4098
> <DOWN>
> Dec 24 22:34:52 daemon.info connmand[294]: eth0 {newlink} index 5
> address 00:00:00:01:02:03 mtu 1500
> Dec 24 22:34:52 daemon.info connmand[294]: eth0 {newlink} index 5
> operstate 2 <DOWN>
> Dec 24 22:34:52 daemon.info connmand[294]: *Adding interface eth0 [
> ethernet ]*
> Dec 24 22:34:52 daemon.info connmand[294]: eth0 {update} flags 102467
> <UP,RUNNING,LOWER_UP>
> Dec 24 22:34:52 daemon.info connmand[294]: eth0 {newlink} index 5
> address 00:00:00:01:02:03 mtu 1500
> Dec 24 22:34:52 daemon.info connmand[294]: eth0 {newlink} index 5
> operstate 0 <UNKNOWN>
> Dec 24 22:34:52 daemon.info connmand[294]: eth0 {add} route ff00:: gw
> :: scope 0 <UNIVERSE>
> Dec 24 22:34:52 daemon.info connmand[294]: eth0 {add} route fe80:: gw
> :: scope 0 <UNIVERSE>
> Dec 24 22:34:52 daemon.info connmand[294]: eth0 {update} flags 36867 <UP>
> Dec 24 22:34:52 daemon.info connmand[294]: eth0 {newlink} index 5
> address 00:00:00:01:02:03 mtu 1500
> Dec 24 22:34:52 daemon.info connmand[294]: eth0 {newlink} index 5
> operstate 2 <DOWN>
> Dec 24 22:34:53 daemon.info connmand[294]: *eth0 {update} flags
> 102467 <UP,RUNNING,LOWER_UP>*
> Dec 24 22:34:53 daemon.info connmand[294]: eth0 {newlink} index 5
> address 00:00:00:01:02:03 mtu 1500
> Dec 24 22:34:53 daemon.info connmand[294]: eth0 {newlink} index 5
> operstate 6 <UP>
> Dec 24 22:35:02 daemon.info connmand[294]: *Setting hostname to
> my_hostname*
> Dec 24 22:35:02 daemon.info connmand[294]: eth0 {add} address
> 192.168.1.100/24 label eth0 family 2
> Dec 24 22:35:02 daemon.info connmand[294]: eth0 {add} route
> 192.168.1.0 gw 0.0.0.0 scope 253 <LINK>
> Dec 24 22:35:02 daemon.info connmand[294]: eth0 {add} route
> 192.168.1.1 gw 0.0.0.0 scope 253 <LINK>
> Dec 24 22:35:02 daemon.info connmand[294]: eth0 {add} route 0.0.0.0
> gw 192.168.1.1 scope 0 <UNIVERSE>
> Dec 24 22:35:02 daemon.info connmand[294]: eth0 {add} route
> 82.165.8.211 gw 192.168.1.1 scope 0 <UNIVERSE>
> Dec 24 22:35:02 daemon.info connmand[294]: eth0 {del} route
> 82.165.8.211 gw 192.168.1.1 scope 0 <UNIVERSE>
> Dec 24 22:38:26 daemon.info connmand[294]: *(null) {RX} 776 packets
> 148761 bytes*
> Dec 24 22:38:26 daemon.info connmand[294]: *(null) {TX} 825 packets
> 78648 bytes*
> Dec 24 22:38:26 daemon.info connmand[294]: *(null) {update} flags
> 36866 <DOWN>*
> Dec 24 22:38:26 daemon.info connmand[294]: *eth0 {newlink} index 5
> address 00:00:00:01:02:03 mtu 1500*
> Dec 24 22:38:26 daemon.info connmand[294]: *eth0 {newlink} index 5
> operstate 2 <DOWN>*
> Dec 24 22:38:27 daemon.info connmand[294]: (null) {del} route fe80::
> gw :: scope 0 <UNIVERSE>
> Dec 24 22:38:27 daemon.info connmand[294]: (null) {del} route ff00::
> gw :: scope 0 <UNIVERSE>
> Dec 24 22:38:27 daemon.info connmand[294]: (null) {del} address
> 192.168.1.100/24 label eth0
> Dec 24 22:38:27 daemon.info connmand[294]: eth0 {dellink} index 5
> operstate 2 <DOWN>
> Dec 24 22:38:27 daemon.info connmand[294]: (null) {RX} 776 packets
> 148761 bytes
> Dec 24 22:38:27 daemon.info connmand[294]: (null) {TX} 825 packets
> 78648 bytes
> Dec 24 22:38:27 daemon.info connmand[294]: (null) {remove} index 5
> Dec 24 22:38:27 daemon.info connmand[294]: *Remove interface (null) [
> ethernet ]*
> Dec 24 22:39:12 daemon.info connmand[294]: eth0 {create} index 6 type
> 1 <ETHER>
> Dec 24 22:39:12 daemon.info connmand[294]: eth0 {update} flags 4098
> <DOWN>
> Dec 24 22:39:12 daemon.info connmand[294]: eth0 {newlink} index 6
> address 00:00:00:01:02:03 mtu 1500
> Dec 24 22:39:12 daemon.info connmand[294]: eth0 {newlink} index 6
> operstate 2 <DOWN>
> Dec 24 22:39:12 daemon.info connmand[294]: *Adding interface eth0 [
> ethernet ]*
> Dec 24 22:39:12 daemon.info connmand[294]: eth0 {update} flags 102467
> <UP,RUNNING,LOWER_UP>
> Dec 24 22:39:12 daemon.info connmand[294]: eth0 {newlink} index 6
> address 00:00:00:01:02:03 mtu 1500
> Dec 24 22:39:12 daemon.info connmand[294]: eth0 {newlink} index 6
> operstate 0 <UNKNOWN>
> Dec 24 22:39:12 daemon.info connmand[294]: eth0 {add} route ff00:: gw
> :: scope 0 <UNIVERSE>
> Dec 24 22:39:12 daemon.info connmand[294]: eth0 {add} route fe80:: gw
> :: scope 0 <UNIVERSE>
> Dec 24 22:39:12 daemon.info connmand[294]: eth0 {update} flags 36867 <UP>
> Dec 24 22:39:12 daemon.info connmand[294]: eth0 {newlink} index 6
> address 00:00:00:01:02:03 mtu 1500
> Dec 24 22:39:12 daemon.info connmand[294]: eth0 {newlink} index 6
> operstate 2 <DOWN>
> Dec 24 22:39:14 daemon.info connmand[294]: eth0 {update} flags 102467
> <UP,RUNNING,LOWER_UP>
> Dec 24 22:39:14 daemon.info connmand[294]: eth0 {newlink} index 6
> address 00:00:00:01:02:03 mtu 1500
> Dec 24 22:39:14 daemon.info connmand[294]: eth0 {newlink} index 6
> operstate 6 <UP>
> Dec 24 22:39:22 daemon.info connmand[294]: Setting hostname to
> my_hostname
> Dec 24 22:39:22 daemon.info connmand[294]: eth0 {add} address
> 192.168.1.100/24 label eth0 family 2
> Dec 24 22:39:22 daemon.info connmand[294]: eth0 {add} route
> 192.168.1.0 gw 0.0.0.0 scope 253 <LINK>
> Dec 24 22:39:22 daemon.info connmand[294]: eth0 {add} route
> 192.168.1.1 gw 0.0.0.0 scope 253 <LINK>
> Dec 24 22:39:22 daemon.info connmand[294]: eth0 {add} route 0.0.0.0
> gw 192.168.1.1 scope 0 <UNIVERSE>
> Dec 24 22:39:22 daemon.info connmand[294]: eth0 {add} route
> 82.165.8.211 gw 192.168.1.1 scope 0 <UNIVERSE>
> Dec 24 22:39:22 daemon.info connmand[294]: eth0 {del} route
> 82.165.8.211 gw 192.168.1.1 scope 0 <UNIVERSE>
Until 22:35:02 everything goes fine, eth0 interface is up and running.
After three minutes, at 22:38:26 I see some strange logs. What does
(null) mean? Why the interface is removed and then added again? What can
be the cause of the problem?
Thanks in advance for your time
Regards,
Fabio Emiliani
--
*Fabio Emiliani*
*/Software Engineer/*
/Ph. +39 075 8298 532/
/fabioemiliani(a)artgroup-spa.com/ <mailto:fabioemiliani@artgroup-spa.com>
DISCLAIMER
This email and any attachment may contain confidential information. If
you are not the intended recipient you are not authorised to copy or
disclose all or any part of it without the prior written consent of ART SpA.
/ART SpA – Step Forward With US - //www.artgroup-spa.com/logo_ART_firma-1//
/Ph. +39 075 8298 501 – Fax +39 075 8298 525 /
P*Please consider our environment before printing this e-mail***
4 years, 11 months
Hidden Wifi with several AP
by Thomas Baron
Hi,
I'm using connman (1.33) on a raspberry pi 3B to connect to a hidden wifi.
While this is working fine there is an strange behavior here : after the
connection is established (using wpa_supplicant), few seconds after connman
switch to another AP which is broadcasting the same SSID (actually there
are several AP on the same network at that place). Once this second
connection is made connman stays connected properly.
The WiFi configuration is set on /var/lib/connman/wifi.config (with Hidden
= true on the relevant service_wifi).
Extract of the relevant logs is below :
Dec 22 08:00:22 connmand[424]: Connection Manager version 1.33
connmand[424]: Adding configuration wifi
connmand[424]: Adding service configuration wifi_2458
[...]
systemd[1]: Started WPA supplicant.
connmand[424]: wlan0 {update} flags 36931 <UP,RUNNING>
wpa_supplicant[443]: wlan0: Trying to associate with 40:18:b1:0b:65:15
(SSID='name_of_the_ssid' freq=2437 MHz)
wpa_supplicant[443]: wlan0: Associated with 40:18:b1:0b:65:15
wpa_supplicant[443]: wlan0: WPA: Key negotiation completed with
40:18:b1:0b:65:15 [PTK=CCMP GTK=TKIP]
wpa_supplicant[443]: wlan0: CTRL-EVENT-CONNECTED - Connection to
40:18:b1:0b:65:15 completed [id=0 id_str=]
connmand[424]: wlan0 {update} flags 102467 <UP,RUNNING,LOWER_UP>
Dec 22 08:00:25 connmand[424]: ntp: time slew -0.215447 s
[...] (nothing here related to either connman or wpa_supplicant)
Dec 22 08:00:29 wpa_supplicant[443]: wlan0: Trying to associate with
00:19:77:3a:d1:54 (SSID='name_of_the_ssid' freq=2462 MHz)
connmand[424]: wlan0 {RX} 239 packets 79003 bytes
connmand[424]: Probably roaming right now! Staying connected...
wpa_supplicant[443]: wlan0: Associated with 00:19:77:3a:d1:54
wpa_supplicant[443]: wlan0: WPA: Key negotiation completed with
00:19:77:3a:d1:54 [PTK=CCMP GTK=TKIP]
wpa_supplicant[443]: wlan0: CTRL-EVENT-CONNECTED - Connection to
00:19:77:3a:d1:54 completed [id=0 id_str=]
connmand[424]: wlan0 {update} flags 102467 <UP,RUNNING,LOWER_UP>
Regarding the signal strengh with iwlist : Quality=36/70 Signal level=-74
dBm for 40:18:B1:0B:65:15 and Quality=46/70 Signal level=-64 dBm
for 00:19:77:3A:D1:54
So is it an expected behavior ? If yes why and is it connman,
wpa_supplicant or the AP which take the decision to switch AP ? Is there a
way to force connman to stay on the first AP and only switch if it doesn't
catch the signal anymore ?
Thanks,
Thomas
4 years, 11 months
[PATCH] service: Block wifi autoconnection when hidden connection is in progress
by Saurav Babu
In the following scenario:
1. Device is connected to AP in non hidden mode.
2. Connection is initated to AP in hidden mode.
connman disconnects old service and tries to connect to new service. But
for connecting hidden service it first scans the hidden AP and when
network is added for hidden AP then connection is tried. In the meantime
normal AP got disconnected and was tried to autoconnect even before
hidden AP was scanned successfully.
Ideally non hidden AP should not be autoconnected when hidden AP connection
is in progress.
This patch blocks wifi autoconnection when hidden connection is in
progress and unblocks autoconnection after hidden connection is started
or hidden wifi scan is completed and hidden AP is not found in the scan list.
---
src/connman.h | 2 ++
src/network.c | 4 ++++
src/service.c | 13 ++++++++++++-
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/src/connman.h b/src/connman.h
index ce3ef8d..24461b1 100644
--- a/src/connman.h
+++ b/src/connman.h
@@ -796,6 +796,8 @@ void __connman_service_notify(struct connman_service *service,
int __connman_service_counter_register(const char *counter);
void __connman_service_counter_unregister(const char *counter);
+void __connman_set_wifi_autoconnect(bool autoconnect);
+
#include <connman/peer.h>
int __connman_peer_init(void);
diff --git a/src/network.c b/src/network.c
index 2e423bc..eccb2ef 100644
--- a/src/network.c
+++ b/src/network.c
@@ -1370,6 +1370,8 @@ void connman_network_clear_hidden(void *user_data)
DBG("user_data %p", user_data);
+ __connman_set_wifi_autoconnect(true);
+
/*
* Hidden service does not have a connect timeout so
* we do not need to remove it. We can just return
@@ -1389,6 +1391,8 @@ int connman_network_connect_hidden(struct connman_network *network,
DBG("network %p service %p user_data %p", network, service, user_data);
+ __connman_set_wifi_autoconnect(true);
+
if (!service)
return -EINVAL;
diff --git a/src/service.c b/src/service.c
index f6a76f6..5fdff4b 100644
--- a/src/service.c
+++ b/src/service.c
@@ -48,6 +48,7 @@ static unsigned int autoconnect_timeout = 0;
static unsigned int vpn_autoconnect_timeout = 0;
static struct connman_service *current_default = NULL;
static bool services_dirty = false;
+static bool wifi_autoconnect = true;
struct connman_stats {
bool valid;
@@ -3764,6 +3765,9 @@ static bool auto_connect_service(GList *services,
ignore[CONNMAN_SERVICE_TYPE_VPN] = true;
+ if (!wifi_autoconnect)
+ ignore[CONNMAN_SERVICE_TYPE_WIFI] = true;
+
for (list = services; list; list = list->next) {
service = list->data;
@@ -5921,12 +5925,19 @@ static void prepare_8021x(struct connman_service *service)
service->phase2);
}
+void __connman_set_wifi_autoconnect(bool autoconnect)
+{
+ wifi_autoconnect = autoconnect;
+}
+
static int service_connect(struct connman_service *service)
{
int err;
- if (service->hidden)
+ if (service->hidden) {
+ wifi_autoconnect = false;
return -EPERM;
+ }
switch (service->type) {
case CONNMAN_SERVICE_TYPE_UNKNOWN:
--
1.9.1
4 years, 11 months
unexpected disconnects in wifi
by Vasiliy Tolstov
I'm build for fedora connman 1.33 and have unexpected disconnects 5-10
times on each day:
Dec 20 21:03:13 computer connmand[3181]: wlp2s0 {RX} 1150129 packets
1426722614 bytes
Dec 20 21:03:13 computer connmand[3181]: wlp2s0 {TX} 734497 packets
106013237 bytes
Dec 20 21:03:13 computer connmand[3181]: wlp2s0 {update} flags 36867 <UP>
Dec 20 21:03:13 computer connmand[3181]: wlp2s0 {newlink} index 3
address C8:FF:28:E2:57:49 mtu 1500
Dec 20 21:03:13 computer connmand[3181]: wlp2s0 {newlink} index 3
operstate 2 <DOWN>
Dec 20 21:03:13 computer connmand[3181]: Time request for server
172.16.1.1 failed (101/Network is unreachable)
Dec 20 21:03:13 computer connmand[3181]: wlp2s0 {del} address
172.16.1.4/24 label wlp2s0
Dec 20 21:03:13 computer connmand[3181]: wlp2s0 {del} route 172.16.1.0
gw 0.0.0.0 scope 253 <LINK>
Dec 20 21:03:13 computer connmand[3181]: Skipping disconnect of
6b65656e65746963_managed_psk, network is connecting.
Dec 20 21:03:13 computer connmand[3181]: ipconfig state 7 ipconfig method 1
Dec 20 21:03:14 computer connmand[3181]: ipconfig state 2 ipconfig method 1
Dec 20 21:03:14 computer connmand[3181]: wlp2s0 {RX} 1150129 packets
1426722614 bytes
Dec 20 21:03:14 computer connmand[3181]: wlp2s0 {TX} 734497 packets
106013237 bytes
Dec 20 21:03:14 computer connmand[3181]: wlp2s0 {update} flags 102403
<UP,LOWER_UP>
Dec 20 21:03:14 computer connmand[3181]: wlp2s0 {newlink} index 3
address C8:FF:28:E2:57:49 mtu 1500
Dec 20 21:03:14 computer connmand[3181]: wlp2s0 {newlink} index 3
operstate 5 <DORMANT>
Dec 20 21:03:15 computer connmand[3181]: wlp2s0 {RX} 1150131 packets
1426722896 bytes
Dec 20 21:03:15 computer connmand[3181]: wlp2s0 {TX} 734499 packets
106013521 bytes
Dec 20 21:03:15 computer connmand[3181]: wlp2s0 {update} flags 102467
<UP,RUNNING,LOWER_UP>
Dec 20 21:03:15 computer connmand[3181]: wlp2s0 {newlink} index 3
address C8:FF:28:E2:57:49 mtu 1500
Dec 20 21:03:15 computer connmand[3181]: wlp2s0 {newlink} index 3
operstate 6 <UP>
Dec 20 21:03:15 computer connmand[3181]: ipconfig state 3 ipconfig method 1
Dec 20 21:03:16 computer connmand[3181]: wlp2s0 {add} address
172.16.1.4/24 label wlp2s0 family 2
Dec 20 21:03:16 computer connmand[3181]: wlp2s0 {add} route 172.16.1.0
gw 0.0.0.0 scope 253 <LINK>
Dec 20 21:03:16 computer connmand[3181]: wlp2s0 {add} route 172.16.1.1
gw 0.0.0.0 scope 253 <LINK>
Dec 20 21:03:16 computer connmand[3181]: wlp2s0 {add} route 8.8.8.8 gw
172.16.1.1 scope 0 <UNIVERSE>
Dec 20 21:03:16 computer connmand[3181]: wlp2s0 {add} route 8.8.4.4 gw
172.16.1.1 scope 0 <UNIVERSE>
Dec 20 21:03:16 computer connmand[3181]: wlp2s0 {add} route 0.0.0.0 gw
172.16.1.1 scope 0 <UNIVERSE>
Dec 20 21:03:16 computer connmand[3181]: wlp2s0 {add} route
82.165.8.211 gw 172.16.1.1 scope 0 <UNIVERSE>
Dec 20 21:03:16 computer connmand[3181]: wlp2s0 {del} route
82.165.8.211 gw 172.16.1.1 scope 0 <UNIVERSE>
--
Vasiliy Tolstov,
e-mail: v.tolstov(a)selfip.ru
4 years, 11 months
[PATCH] openvpn: Close stdout and stderr file descriptor from child on exit
by Daniel Wagner
We only added G_IO_IN to the watch and therefore never got the G_IO_HUP.
That leads to a busy loop because can_read_data always return true.
By adding G_IO_HUP & friends we really termanate now in
can_read_data. But we unrefed the channel one time to much.
These two bugs were introduced by 8e182879f709 ("openvpn: Use proper
logging function")
---
vpn/plugins/openvpn.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/vpn/plugins/openvpn.c b/vpn/plugins/openvpn.c
index 7d283b477635..e33950970b13 100644
--- a/vpn/plugins/openvpn.c
+++ b/vpn/plugins/openvpn.c
@@ -321,10 +321,8 @@ static gboolean can_read_data(GIOChannel *chan,
gchar *str;
gsize size;
- if (cond == G_IO_HUP) {
- g_io_channel_unref(chan);
+ if (cond & (G_IO_NVAL | G_IO_ERR | G_IO_HUP))
return FALSE;
- }
g_io_channel_read_line(chan, &str, &size, NULL, NULL);
cbf(str);
@@ -340,7 +338,8 @@ static int setup_log_read(int stdout_fd, int stderr_fd)
chan = g_io_channel_unix_new(stdout_fd);
g_io_channel_set_close_on_unref(chan, TRUE);
- watch = g_io_add_watch(chan, G_IO_IN, can_read_data, connman_debug);
+ watch = g_io_add_watch(chan, G_IO_IN | G_IO_NVAL | G_IO_ERR | G_IO_HUP,
+ can_read_data, connman_debug);
g_io_channel_unref(chan);
if (watch == 0)
@@ -348,7 +347,8 @@ static int setup_log_read(int stdout_fd, int stderr_fd)
chan = g_io_channel_unix_new(stderr_fd);
g_io_channel_set_close_on_unref(chan, TRUE);
- watch = g_io_add_watch(chan, G_IO_IN, can_read_data, connman_error);
+ watch = g_io_add_watch(chan, G_IO_IN | G_IO_NVAL | G_IO_ERR | G_IO_HUP,
+ can_read_data, connman_error);
g_io_channel_unref(chan);
return watch == 0? -EIO : 0;
--
2.9.3
4 years, 11 months
