[PATCH 0/2] Annotate case statements
by Daniel Wagner
GCC is complaining.
Daniel Wagner (2):
service: Annotate case statement with fall through
vpn: Annotate case statement with fall through
src/service.c | 1 +
vpn/vpn-provider.c | 1 +
2 files changed, 2 insertions(+)
--
2.20.1
1 year, 6 months
[PATCH] vpn: Follow coding style M12 in enum switch and fix debug log msg
by Jussi Laakkonen
This commit modifies 2ba4926433585b337aff8beeb0285b55e3d22468 switch to
follow coding style M12. With enum's "default" should not be used.
Also, add space to vpn.c:vpn_disconnect() debug log message to separate
words in output.
---
vpn/plugins/vpn.c | 2 +-
vpn/vpn-provider.c | 5 ++++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/vpn/plugins/vpn.c b/vpn/plugins/vpn.c
index 38aa3a7e..ddf4a6c6 100644
--- a/vpn/plugins/vpn.c
+++ b/vpn/plugins/vpn.c
@@ -555,7 +555,7 @@ static int vpn_disconnect(struct vpn_provider *provider)
data->state = VPN_STATE_DISCONNECT;
if (!vpn_driver_data->vpn_driver->disconnect) {
- DBG("Driver has no disconnect() implementation, set provider"
+ DBG("Driver has no disconnect() implementation, set provider "
"state to disconnect.");
vpn_provider_set_state(provider, VPN_PROVIDER_STATE_DISCONNECT);
}
diff --git a/vpn/vpn-provider.c b/vpn/vpn-provider.c
index c3df20b0..3f049e60 100644
--- a/vpn/vpn-provider.c
+++ b/vpn/vpn-provider.c
@@ -1119,7 +1119,10 @@ int __vpn_provider_connect(struct vpn_provider *provider, DBusMessage *msg)
*/
case VPN_PROVIDER_STATE_DISCONNECT:
return -EINPROGRESS;
- default:
+ case VPN_PROVIDER_STATE_UNKNOWN:
+ case VPN_PROVIDER_STATE_IDLE:
+ case VPN_PROVIDER_STATE_CONNECT:
+ case VPN_PROVIDER_STATE_READY:
break;
}
--
2.20.1
1 year, 6 months
[PATCH v2 5/5] service: Call vpn_auto_connect() when default service changes.
by Jussi Laakkonen
This commit adds call to vpn_auto_connect() when default service changes
and the service is not a VPN service. With this change it is ensured
that VPNs are being autoconnected when the default network changes.
---
Changes since v2:
* Move vpn_auto_connect() function prototype to top.
src/service.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/service.c b/src/service.c
index e9901d02..7f09edc1 100644
--- a/src/service.c
+++ b/src/service.c
@@ -148,6 +148,7 @@ static struct connman_ipconfig *create_ip4config(struct connman_service *service
static struct connman_ipconfig *create_ip6config(struct connman_service *service,
int index);
static void dns_changed(struct connman_service *service);
+static void vpn_auto_connect(void);
struct find_data {
const char *path;
@@ -1593,6 +1594,16 @@ static void default_changed(void)
if (service->domainname &&
connman_setting_get_bool("AllowDomainnameUpdates"))
__connman_utsname_set_domainname(service->domainname);
+
+ /*
+ * Connect VPN automatically when new default service
+ * is set and connected, unless new default is VPN
+ */
+ if (is_connected(service->state) &&
+ service->type != CONNMAN_SERVICE_TYPE_VPN) {
+ DBG("running vpn_auto_connect");
+ vpn_auto_connect();
+ }
}
__connman_notifier_default_changed(service);
@@ -3413,8 +3424,6 @@ error:
return -EINVAL;
}
-static void vpn_auto_connect(void);
-
static void do_auto_connect(struct connman_service *service,
enum connman_service_connect_reason reason)
{
--
2.20.1
1 year, 6 months
[PATCH v2 0/5] Include VPNs in service.c autoconnect process.
by Jussi Laakkonen
Changes since v2:
* Patch 0/5: Update "Fourth" description.
* Patch 3/5: Remove unnecessary debug logging.
* Patch 4/5:
* Conform to formatting rules.
* Modify comments to be more simple and put more info to commit msg.
* Update commit message to be more coherent and understandable.
This set of patches includes VPN connections into service.c autoconnect
procedure. The general autoconnection of VPNs is improved and is
triggered also when the default service changes.
First, run_vpn_auto_connect() is enhanced to re-add itself to mainloop
if there are VPNs with autoconnect set. Delay increases every 30s by 1s
up to 10s if the connection does not succeed, starting with 1s delay
after initial.
Second, the service state is indicated when automatically triggered
connection succeeds in order to get the state processed also by
plugins/vpn.c.
Third, the enhanced run_vpn_auto_connect() is required to be removed
from mainloop if running and there is a change in network conditions.
It is needed because with increasing delays the VPN connection may
have delay set in 10s and with changing network conditions the
connection should happen more quickly.
Fourth, service auto connection in service.c is going through new
do_auto_connect() function. It starts service auto connection
( __connman_service_auto_connect()) for other than VPN type services
and VPN auto connection (vpn_auto_connect()) is started for all types
of services. Main reason for adding this new function is that
auto_connect_service() ignores VPN type services.
Fifth, when default service changes and the new default is not VPN it
is set to trigger vpn_auto_connect() to ensure attempt of VPN
autoconnection in case networking conditions change.
Jussi Laakkonen (5):
service: Re-add run_vpn_auto_connect() with increasing delays to main
loop
service: Indicate service state when autoconnect succeeds.
service: Remove existing VPN auto connect from main loop.
service: Implement a do_auto_connect() to include VPNs in autoconnect.
service: Call vpn_auto_connect() when default service changes.
src/service.c | 143 +++++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 130 insertions(+), 13 deletions(-)
--
2.20.1
1 year, 6 months
[PATCH 0/5] Include VPNs in service.c autoconnect process.
by Jussi Laakkonen
This set of patches includes VPN connections into service.c autoconnect
procedure. The general autoconnection of VPNs is improved and is
triggered also when the default service changes.
First, run_vpn_auto_connect() is enhanced to re-add itself to mainloop
if there are VPNs with autoconnect set. Delay increases every 30s by 1s
up to 10s if the connection does not succeed, starting with 1s delay
after initial.
Second, the service state is indicated when automatically triggered
connection succeeds in order to get the state processed also by
plugins/vpn.c.
Third, the enhanced run_vpn_auto_connect() is required to be removed
from mainloop if running and there is a change in network conditions.
It is needed because with increasing delays the VPN connection may
have delay set in 10s and with changing network conditions the
connection should happen more quickly.
Fourth, the service connection in service.c is going through new
do_auto_connect() function that calls __connman_service_auto_connect()
for other than VPN services and vpn_auto_connect() for VPNs. Reason is
simply that processes are different. VPN is the only service that
requires another service to run it on.
Fifth, when default service changes and the new default is not VPN it
is set to trigger vpn_auto_connect() to ensure attempt of VPN
autoconnection in case networking conditions change.
Jussi Laakkonen (5):
service: Re-add run_vpn_auto_connect() with increasing delays to main
loop
service: Indicate service state when autoconnect succeeds.
service: Remove existing VPN auto connect from main loop.
service: Implement a do_auto_connect() to include VPNs in autoconnect.
service: Call vpn_auto_connect() when default service changes.
src/service.c | 151 +++++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 138 insertions(+), 13 deletions(-)
--
2.20.1
1 year, 6 months
The DHCP/DNS confusion (aka no-one cares about /etc/resolv.conf)
by tormen＠mail.ch
Hi,
I am having a knot in my brain ;) ... please help:
Who is handeling dhcp requests with connmand?
Now I would have thgought:
(a) either wpa_supplicant and/or connman
run dhcpcd or dhclient or pump once a physical layer link is
established ... and they would update/touch /etc/resolv.conf if they
received a DNS server via DHCP
(b) or does connmand handles dhcp itself
// But if it's (a):
I don't see any trace in the log of connmand doing so and
I just removed /etc/resolv.conf and connected to wifi network and
no /etc/resolv.conf got created.
// But if it's (b):
I did not see anything in the log of connmand doing so and
there seems only the --nodnsproxy parameter... which does
not help me solve my problem either, because I not want to use
the internal DNS proxy but still have /etc/resolv.conf
configured.
So I am lost.
I am using: /etc/systemd/system/connman.service.d/disable_dns_proxy.conf
(so connmand is running as `/usr/bin/connmand -n --nodnsproxy`)
Do I then need something like systemd-resolved ??
Or maybe I am missing something super obvious ?
It would be helpful if the output of connmand -n would talk about DNS
server / DHCP / resolv.conf... but if I did not miss it, there was
nothing.
Reason I am asking: I would like that /etc/resolv.conf get's created
when connecting (via wpa_supplicant) to wireless network which sends a
specific DNS server for this wifi network (e.g. for local
'login'/'authenication' via web-browser).
Thanks a lot for helping me remove the fog I am in :)
Tormen
1 year, 6 months
[PATCH 0/3] Improve VPN state transitions when re-connecting
by Jussi Laakkonen
This set of patches improves the VPN state transitions when doing a
cycle of connect -> disconnect -> connect transitions in case
networking conditions change rapidly. Also cleanup of VPN routes and
improves as a positive consequence.
First patch forces the VPN provider of connman-vpnd to do full state
transition in case of re-connection (connect -> ready -> disconnect ->
idle -> connect). This makes sure that reference counters of the
provider reach zero and the routes are then removed properly, which
allows connman to set the interface down as well.
Second patch makes the vpn provider driver to explicitely change the
state to disconnect when disconnecting a VPN plugin that has no
disconnect() function implemented or registered as callback.
Otherwise in such cases the state transition cycle is incomplete,
e.g., when current network is lost.
Third patch changes the vpn.c vpn_disconnect_check_provider() to call
disconnection via provider to ensure full state transition cycle.
Jussi Laakkonen (3):
vpn: Let previous connection to finish before starting new one.
vpn: Set provider state to disconnect if driver has no disconnect
impl.
vpn: Disconnect via provider when transport is gone or not valid.
plugins/vpn.c | 5 +++--
vpn/plugins/vpn.c | 7 +++++++
vpn/vpn-provider.c | 25 ++++++++++++++++++++++++-
3 files changed, 34 insertions(+), 3 deletions(-)
--
2.20.1
1 year, 6 months
Huawei ME909s-120
by Stéphane David
Hello,
I have some trouble to start a 4G modem with connman.
- Raspberry Pi 3B+ with latest Raspbian Stretch (Linux 4.14.50-v7+)
- USB to MPCIE adapter with a HUAWEI ME909s-120 (4G Modem)
- connman 1.33
The modem is well detected on boot, we can see ttyUSBx ports and
ecm_ether port
$ dmesg
[ 138.235050] usb 1-1.3: new high-speed USB device number 6 using dwc_otg
[ 138.366928] usb 1-1.3: New USB device found, idVendor=12d1,
idProduct=15c1
[ 138.366942] usb 1-1.3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 138.366950] usb 1-1.3: Product: HUAWEI Mobile V7R11
[ 138.366961] usb 1-1.3: Manufacturer: Huawei Technologies Co., Ltd.
[ 138.366969] usb 1-1.3: SerialNumber: 0123456789ABCDEF
[ 138.540782] cdc_ether 1-1.3:2.0 wwan0: register 'cdc_ether' at
usb-3f980000.usb-1.3, Mobile Broadband Network Device, 02:1e:10:1f:00:00
[ 138.540959] usbcore: registered new interface driver cdc_ether
[ 138.548007] usbcore: registered new interface driver usbserial
[ 138.548045] usbcore: registered new interface driver usbserial_generic
[ 138.548080] usbserial: USB Serial support registered for generic
[ 138.562184] usbcore: registered new interface driver option
[ 138.562231] usbserial: USB Serial support registered for GSM modem
(1-port)
[ 138.562684] option 1-1.3:2.2: GSM modem (1-port) converter detected
[ 138.566270] usb 1-1.3: GSM modem (1-port) converter now attached to
ttyUSB0
[ 138.566548] option 1-1.3:2.3: GSM modem (1-port) converter detected
[ 138.567323] usb 1-1.3: GSM modem (1-port) converter now attached to
ttyUSB1
[ 138.568591] cdc_ether 1-1.3:2.0 eth1: renamed from wwan0
[ 138.568742] option 1-1.3:2.4: GSM modem (1-port) converter detected
[ 138.568952] usb 1-1.3: GSM modem (1-port) converter now attached to
ttyUSB2
[ 138.569130] option 1-1.3:2.5: GSM modem (1-port) converter detected
[ 138.569294] usb 1-1.3: GSM modem (1-port) converter now attached to
ttyUSB3
[ 138.569448] option 1-1.3:2.6: GSM modem (1-port) converter detected
[ 138.569579] usb 1-1.3: GSM modem (1-port) converter now attached to
ttyUSB4
$ ifconfig
eth1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 02:1e:10:1f:00:00 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
a udev rule translate wwan0 to eth1 (eth0 is the ethernet port on RPI)
i can establish a connection with picocom on port ttyUSB2 and send AT
commands
$ picocom /dev/ttyUSB2 --b 115200 -l
Set the operator APN name to use for the data connectivity
AT+CGDCONT=1,"IP","hologram"
Activate the data connection for the network interface exposed to host
system with the APN profile previously created.
AT^NDISDUP=1,1,
Now the eth1 interface is running and receive it's IP address from the
network.
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.171.18.100 netmask 255.255.255.248 broadcast
10.171.18.103
inet6 fe80::361d:6a22:fd47:61d2 prefixlen 64 scopeid 0x20<link>
ether 02:1e:10:1f:00:00 txqueuelen 1000 (Ethernet)
RX packets 1 bytes 318 (318.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 31 bytes 4463 (4.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ping is also ok
$ ping -I eth1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 10.171.18.100 eth1: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=211 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=113 time=83.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=113 time=78.9 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=113 time=77.9 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=113 time=78.9 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=113 time=78.0 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=113 time=85.4 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=113 time=84.3 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=113 time=84.3 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=113 time=82.3 ms
^C
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9010ms
rtt min/avg/max/mdev = 77.928/94.592/211.622/39.109 ms
but i never see a new service inside connman only eth0 ?
ogate@1gate-b827eb5d7000:~$ connmanctl
connmanctl> services
*AO Wired ethernet_b827eb5d9c12_cable
connmanctl>
What i'm doing wrong ?
thanks,
Stéphane David
1 year, 6 months
Connman API document and test for C / C++
by JH
Hi,
It seems most API documents and test code in test and doc are all
based on Python program, are there any document / test program based
on C /C++?
Thank you.
Kind regards,
- jupiter
1 year, 6 months
Directly create settings to /var/lib/connmn to setup WiFi
by JH
Hi,
In an embedded system, there is no interactive manual involvement to
setup WiFi from the command line connmanctl, rather than calling
connmanctl command line to set up WiFi manually, can it be done in a C
program to create the WiFi service
wifi_d4ca6e001bc0_5450472d4d434e46_managed_psk, and to create the
settings file to
/var/lib/connmn/wifi_d4ca6e001bc0_5450472d4d434e46_managed_psk/settings?
This is an essential requirement for almost every embedded system, but
no one talked about it, how did you accomplish it? Are you all using
command line connmanctl?
Thank you.
Kind regards,
- jupiter
1 year, 6 months
