[RFC] Wi-Fi Protected Setup (WPS) connection
by Jose Blanquicet
Hello everybody,
We would like to propose a RFC to change the way to manage the WPS
connections. Following we present our proposal and the reasons for
suggesting it:
Current implementation of WPS connection requires to specify the service to
which the user wants to connect, and when the connection is going to
finalize, a verification is done in *handle_wps_completion* function to
ensure that the SSID of the AP actually being connected was the one
specified by the user. This violates the WiFi Alliance specification over
WPS and the WPS Certification plan because:
1. WiFi Alliance admits to certify devices that have no mean for the
user to choose an AP to connect to, they define them as "Client devices
with only a simple display or a fixed label containing a setup password"
(Pag. 12 of Wi-Fi Simple Configuration Technical Specification Version
2.0.5)
1. The WPS protocol includes the transition from un-configured to
configured state of the AP when the first Enrollee connects, some Access
Points change their SSID during this transition, that would cause the
ConnMan to invalidate the connection. A tipical example of such Access
Point is the Atheros used in test 5.4.2 of Wi-Fi CERTIFIED™ Wi-Fi Protected
Setup™ Interoperability Test Plan – Version 2.0.15
After having performed a detailed study of the wpa_supplicant
implementation for the WPS, we propose to implement a solution with the
following general characteristics:
1. The new implementation must keep current WPS implementation for
compatibility support, but as deprecated.
2. In order to meet the specifications of Wi-Fi Alliance and based on
what the WPS D-Bus Interface of wpa_supplicant offers (Documented in
https://w1.fi/wpa_supplicant/devel/dbus.html#dbus_wps) we propose to add
two methods to the Technology D-Bus Interface: *StartWPS* and *CancelWPS*,
analogous to functions WPS.Start and WPS.Cancel provided by
wpa_supplicant. In this way there is no service specified enabling simple
devices to offer a very basic interface to the user for starting the WPS
session. Both methods would be supported only by WiFi technology.
3. On the other hand, some advanced WiFi modules expose more than one
network interface (one for P2P, one for STA, one for AP ..) that can be
active at the same time, and it is then desirable to not let connman
randomly choose on which start WPS, thus we propose also to add the
possibility to specify the interface over which either the start or cancel
action will be performed. This would not be a mandatory parameter in order
to keep the things easy for more simple systems.
Please find below the implementation proposal:
*StartWPS:*
Following the approach of wpa_supplicant, we propose to add the possibility
to choose which role to assume (enrollee, registrar), which authentication
type use (pin, pbc) and get back the pin to be used (if required), as well
as wpa_supplicant does. At this point, we can briefly define a possible
prototype of the method:
dict StartWPS(dict parameters)
Where the returned dictionary could be empty or composed by at most one
entry, which will be the just generated PIN by the wpa_supplicant, in case
it was requested. On the other hand, the function would receive a
dictionary with possible keys: “Ifname", "Role", "Type" and "Pin"; where
“Ifame” is an optional parameters covering previous defined characteristic
for complex systems. Whereas, parameters "Role", "Type" and "Pin" follow
exactly the same behavior of the table presented in
https://w1.fi/wpa_supplicant/devel/dbus.html#dbus_wps for method Start
of fi.w1.wpa_supplicant1.Interface.WPS
Interface.
When the *StartWPS* method gets called, it should verify if interface was
specified through “Ifname” entry key. If so, WPS Session will be started in
that specific interface, otherwise we suggest to look for the first
available interface with the capabilities to start a WPS Session among the
device_list of the Wi-Fi Technology. If it is found, then use it, if not
return "[service].Error.NotSupported”.
Additionally, current implementation does not allow to start a WPS Session
when the device is playing as Access Point (Tethering). On the contrary,
wpa_supplicant does. Therefore, we propose to also add this possibility to
the new implementation. It would be possible if a Service D-Bus Object is
not required for starting a WPS Session, which would be true if the new
methods are added to the Technology D-Bus Interface, as we propose.
*CancelWPS:*
This function does not require for any particular parameter. So, we propose
to only continue giving the option to specify the interface. Therefore, the
possible prototype of the method would be:
void CancelWPS(dict parameters)
Where the received dictionary could be empty or composed by at most one
single entry if the user wants to specify the interface using the key
“Ifname”. If so, the *CancelWPS* function should cancel the ongoing WPS
Session running in that specific interface. Otherwise, we suggest to do it
over all the Device of the Wi-Fi Technology (device_list).
*Going into details of implementation*:
After having studied the ConnMan architecture we think to associate the WPS
concept to the Device Infrastructure because if we want to add the
possibility of specify the interface (“Ifname”), the Device is the
corresponding represents of a real device inside the ConnMan. Therefore, we
think it is the best choice. Additionally, *StartWPS* and *CancelWPS*
should be added to the device driver:
*static* *struct* connman_device_driver wifi_ng_driver = {
.name = "*wifi*",
.type = *CONNMAN_DEVICE_TYPE_WIFI*,
...
.start_wps = wifi_start_wps,
.cancel_wps = wifi_cancel_wps,
};
It means that WiFi plugging must implements both methods wifi_start_wps and
wifi_cancel_wps. In particular, wifi_start_wps will need to receive the WPS
parameters to then pass them to the ConnMan’s supplicant handler
(gsuppicant/supplicant.c), which is the only one that interacts directly
with the wpa_supplicant.
Next, the supplicant handler will call methods Start or Cancel of the
fi.w1.wpa_supplicant1.Interface.WPS
D-Bus Interface of the wpa_supplicant, with the required parameters. In
case the method Start returns the newly generated PIN it has to be
forwarded towards the Technology to then be added as an entry in the
directory that would be returned by the *StartWPS* method. It would imply
that we have to store the request message of the *StartWPS* method in order
to reply possibly with a the PIN generated by the wpa_supplicant. To do it,
we propose to store that message in the Device structure in order to be
coherent with the association we previously proposed between the WPS and
Device.
Once the WPS Session has been initiated, it could finalize successfully or
fail. The current implementation does not provide further information about
such a events. Given that, we propose to notify the following events (Just
the most commons):
- Success: WPS provisioning has finished successfully.
- Password Authentication Fail: When pin entered in the registrar was
wrong.
- PBC-Overlap: When an enrollee detects two registrars with PBC session
active.
We think to perform those notifications using a D-Bus Signal added to the
Technology Interface, let’s call it *WPSEvent*. It would simply indicate
when one of the described event takes place. We propose to just provide a
string with the name of the event: "success", "pwd-auth-fail" or
"pbc-overlap", following the wpa_supplicant notation. All this information
is already provided by the wpa_supplicant in the event
fi.w1.wpa_supplicant1.Interface.WPS.Event, thus it just need to be
forwarded to the Technology in order to be emitted.
In order to forward WPS events, we propose to follow the implementation of
the communication between the plug-in and the supplicant handler, it means
to use the callback mechanism adding a new callback:
*static* *const* GSupplicantCallbacks callbacks = {
...
.wps_event = wps_event,
};
Thus the wifi plug-in must implement the wps_event function that will
basically just call a Technology function that will emit the proposed
signal.
What do you think about our proposal? Of course, everybody is welcome to
give feedbacks and suggestions.
Best regards,
Jose Blanquicet
3 years, 11 months
[PATCH 1/2] Fast-reconnect and Band-steering support
by naveen＠nestlabs.com
From: Naveen Singh <nasingh(a)google.com>
This patch contains new implementations for following:
1. Band Steering and Load balancing Support: Enterprise AP sometimes
denies association with assoc status code 17. The reason AP sends
this code, is to steer to some other AP (in a different band) or for
doing load balancing (in case this AP is heavily loaded). This will not
work with current connman as connman would take this disconnect
notification as normal disconnect and disable the network. This act
would cause wpa_s search for the next BSSID stop. The next time connect
attempt is issued from connman, the story would repeat again. The idea
of this patch is to not interfere with BSSID selection logic of wpa_s.
wpa_s was sending disconnect reason code on DBUS as a part of
PropertyChanged signal but there was no notification for assoc status
code.
In this commit id of hostapd (c7fb678f3109e62af1ef39be9b12bf8370c35bde)
wpa_s is also sending assoc status code as a part of DBUS
PropertyChanged signal. Idea here is that on a disconnect notification
from wpa_s connman would look into the assoc status code and if it is
set to 17, it would not proceed. This will let wpa_s continue with its
own BSSID selection logic.
2. Optimize DBUS call - In case network path is Not NULL (means a
profile is already plumbed in wpa_s), network_remove should only
be called if the new network is different from what is sitting in
wpa_s. The notion of new network here is SSID, security type and
passphrase. If the new network is same as the one in wpa_s, no need
to do remove, add and select. This would save 3 DBUS calls to wpa_s.
3. Fast Reconnect: On receiving a deauth with reason code 6, 7 or 4
wpa_supplicant will immediately try to connect back. Now with current
implementation of connman, a disconnect notification will cause network
to get disabled and connection procedure would stop. This also impacts
the roaming time in case disconnect is because of any other reason code.
The act of disabling network severly affects wpa_s connection state
machine as it would generate a deauth to current network when half way
the connection was done. The idea here is that we do not disable network
on disconnect and let wpa_s keep trying to find out that network. Only
when connman has another network this network would be removed and new
network would be added.
---
gsupplicant/gsupplicant.h | 2 +
gsupplicant/supplicant.c | 126 ++++++++++++++++++++++++++++++++++++++++++++--
plugins/wifi.c | 51 ++++++++++++++++---
3 files changed, 170 insertions(+), 9 deletions(-)
diff --git a/gsupplicant/gsupplicant.h b/gsupplicant/gsupplicant.h
index a2a7605..2f9806e 100644
--- a/gsupplicant/gsupplicant.h
+++ b/gsupplicant/gsupplicant.h
@@ -353,6 +353,8 @@ struct _GSupplicantCallbacks {
GSupplicantPeerState state);
void (*peer_request) (GSupplicantPeer *peer);
void (*debug) (const char *str);
+ void (*update_disconnect_reasoncode)(GSupplicantInterface *interface, int reasoncode);
+ void (*update_assoc_status_code)(GSupplicantInterface *interface, int reasoncode);
};
typedef struct _GSupplicantCallbacks GSupplicantCallbacks;
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index c8fbef6..32cbc14 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -150,6 +150,13 @@ struct _GSupplicantWpsCredentials {
char *key;
};
+struct added_network_information {
+ char * ssid;
+ GSupplicantSecurity security;
+ char * passphrase;
+ char * private_passphrase;
+};
+
struct _GSupplicantInterface {
char *path;
char *network_path;
@@ -181,6 +188,7 @@ struct _GSupplicantInterface {
GHashTable *bss_mapping;
void *data;
const char *pending_peer_path;
+ struct added_network_information network_info;
};
struct g_supplicant_bss {
@@ -387,6 +395,63 @@ static GSupplicantState string2state(const char *state)
return G_SUPPLICANT_STATE_UNKNOWN;
}
+static bool compare_network_parameters(GSupplicantInterface *interface, GSupplicantSSID *ssid)
+{
+ if (memcmp(interface->network_info.ssid, ssid->ssid, ssid->ssid_len))
+ return FALSE;
+
+ if (interface->network_info.security != ssid->security)
+ return FALSE;
+
+ if (interface->network_info.passphrase &&
+ g_strcmp0(interface->network_info.passphrase, ssid->passphrase) != 0) {
+ return FALSE;
+ }
+
+ if (interface->network_info.private_passphrase &&
+ g_strcmp0(interface->network_info.private_passphrase, ssid->private_key_passphrase) != 0) {
+ return FALSE;
+ }
+
+ return TRUE;
+}
+
+static void remove_network_information(GSupplicantInterface * interface)
+{
+ g_free(interface->network_info.ssid);
+ g_free(interface->network_info.passphrase);
+ g_free(interface->network_info.private_passphrase);
+ interface->network_info.ssid = NULL;
+ interface->network_info.passphrase = NULL;
+ interface->network_info.private_passphrase = NULL;
+}
+
+static int store_network_information(GSupplicantInterface * interface, GSupplicantSSID *ssid)
+{
+ interface->network_info.ssid = g_malloc(ssid->ssid_len + 1);
+ if (interface->network_info.ssid != NULL) {
+ memcpy(interface->network_info.ssid, ssid->ssid, ssid->ssid_len);
+ interface->network_info.ssid[ssid->ssid_len] = '\0';
+ } else {
+ return -ENOMEM;
+ }
+
+ interface->network_info.security = ssid->security;
+
+ if ((ssid->security == G_SUPPLICANT_SECURITY_WEP ||
+ ssid->security == G_SUPPLICANT_SECURITY_PSK ||
+ ssid->security == G_SUPPLICANT_SECURITY_NONE) &&
+ ssid->passphrase) {
+ interface->network_info.passphrase = g_strdup(ssid->passphrase);
+ }
+
+ if (ssid->security == G_SUPPLICANT_SECURITY_IEEE8021X && ssid->private_key_passphrase) {
+ interface->network_info.private_passphrase = g_strdup(ssid->private_key_passphrase);
+ }
+
+ return 0;
+}
+
static void callback_system_ready(void)
{
if (system_ready)
@@ -576,6 +641,30 @@ static void callback_peer_request(GSupplicantPeer *peer)
callbacks_pointer->peer_request(peer);
}
+static void callback_disconnect_reason_code(GSupplicantInterface *interface, int reason_code)
+{
+ if (!callbacks_pointer)
+ return;
+
+ if (!callbacks_pointer->update_disconnect_reasoncode)
+ return;
+
+ if (reason_code != 0)
+ callbacks_pointer->update_disconnect_reasoncode(interface, reason_code);
+}
+
+static void callback_assoc_status_code(GSupplicantInterface *interface, int status_code)
+{
+ if (!callbacks_pointer)
+ return;
+
+ if (!callbacks_pointer->update_assoc_status_code)
+ return;
+
+ callbacks_pointer->update_assoc_status_code(interface, status_code);
+
+}
+
static void remove_group(gpointer data)
{
GSupplicantGroup *group = data;
@@ -619,6 +708,7 @@ static void remove_interface(gpointer data)
g_free(interface->ifname);
g_free(interface->driver);
g_free(interface->bridge);
+ remove_network_information(interface);
g_free(interface);
}
@@ -2135,9 +2225,22 @@ static void interface_property(const char *key, DBusMessageIter *iter,
} else if (g_strcmp0(key, "Networks") == 0) {
supplicant_dbus_array_foreach(iter, interface_network_added,
interface);
- } else
+ } else if (g_strcmp0(key, "DisconnectReason") == 0) {
+ int reason_code;
+ if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_INVALID) {
+ dbus_message_iter_get_basic(iter, &reason_code);
+ callback_disconnect_reason_code(interface, reason_code);
+ }
+ } else if (g_strcmp0(key, "AssocStatusCode") == 0) {
+ int status_code;
+ if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_INVALID) {
+ dbus_message_iter_get_basic(iter, &status_code);
+ callback_assoc_status_code(interface, status_code);
+ }
+ } else {
SUPPLICANT_DBG("key %s type %c",
key, dbus_message_iter_get_arg_type(iter));
+ }
}
static void scan_network_update(DBusMessageIter *iter, void *user_data)
@@ -4111,6 +4214,8 @@ static void interface_add_network_result(const char *error,
interface->network_path = g_strdup(path);
+ store_network_information(interface, data->ssid);
+
supplicant_dbus_method_call(data->interface->path,
SUPPLICANT_INTERFACE ".Interface", "SelectNetwork",
interface_select_network_params,
@@ -4708,6 +4813,19 @@ int g_supplicant_interface_connect(GSupplicantInterface *interface,
g_free(data->path);
dbus_free(data);
+ /*
+ * If this add network is for the same network for which
+ * wpa_supplicant already has a profile then do not need
+ * to add another profile. Only if the profile that needs
+ * to get added is different from what is there in wpa_s
+ * delete the current one. A network is identified by its
+ * SSID, security_type and passphrase (private passphrase
+ * in case security type is 802.11x).
+ */
+ if (compare_network_parameters(interface, ssid)) {
+ return -EALREADY;
+ }
+
intf_data = dbus_malloc0(sizeof(*intf_data));
if (!intf_data)
return -ENOMEM;
@@ -4753,8 +4871,10 @@ static void network_remove_result(const char *error,
result = -ECONNABORTED;
}
- g_free(data->interface->network_path);
- data->interface->network_path = NULL;
+ g_free(data->interface->network_path);
+ data->interface->network_path = NULL;
+
+ remove_network_information(data->interface);
if (data->network_remove_in_progress == TRUE) {
data->network_remove_in_progress = FALSE;
diff --git a/plugins/wifi.c b/plugins/wifi.c
index bb1cabc..e76423d 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -71,6 +71,8 @@
#define P2P_LISTEN_PERIOD 500
#define P2P_LISTEN_INTERVAL 2000
+#define GSUP_80211_ASSOC_STATUS_NO_ADDITIONAL_CLIENT 17
+#define WPA_SUP_LOAD_SHAPING_MAX_RETRIES 3
static struct connman_technology *wifi_technology = NULL;
static struct connman_technology *p2p_technology = NULL;
@@ -128,6 +130,7 @@ struct wifi_data {
unsigned flags;
unsigned int watch;
int retries;
+ int wpa_sup_load_shaping_retries;
struct hidden_params *hidden;
bool postpone_hidden;
struct wifi_tethering_info *tethering_param;
@@ -144,6 +147,8 @@ struct wifi_data {
bool p2p_connecting;
bool p2p_device;
int servicing;
+ int disconnect_reasoncode;
+ int assoc_statuscode;
};
static GList *iface_list = NULL;
@@ -2291,6 +2296,19 @@ static bool handle_wps_completion(GSupplicantInterface *interface,
return true;
}
+static bool handle_assoc_status_code(GSupplicantInterface *interface,
+ struct wifi_data *wifi)
+{
+ if (wifi->state == G_SUPPLICANT_STATE_ASSOCIATING &&
+ wifi->assoc_statuscode == GSUP_80211_ASSOC_STATUS_NO_ADDITIONAL_CLIENT &&
+ wifi->wpa_sup_load_shaping_retries < WPA_SUP_LOAD_SHAPING_MAX_RETRIES) {
+ wifi->wpa_sup_load_shaping_retries ++;
+ return TRUE;
+ }
+ wifi->wpa_sup_load_shaping_retries = 0;
+ return FALSE;
+}
+
static bool handle_4way_handshake_failure(GSupplicantInterface *interface,
struct connman_network *network,
struct wifi_data *wifi)
@@ -2382,6 +2400,10 @@ static void interface_state(GSupplicantInterface *interface)
break;
connman_network_set_connected(network, true);
+
+ wifi->disconnect_reasoncode = 0;
+ wifi->assoc_statuscode = 0;
+ wifi->wpa_sup_load_shaping_retries = 0;
break;
case G_SUPPLICANT_STATE_DISCONNECTED:
@@ -2399,6 +2421,9 @@ static void interface_state(GSupplicantInterface *interface)
if (is_idle(wifi))
break;
+ if (handle_assoc_status_code(interface, wifi))
+ break;
+
/* If previous state was 4way-handshake, then
* it's either: psk was incorrect and thus we retry
* or if we reach the maximum retries we declare the
@@ -2407,12 +2432,6 @@ static void interface_state(GSupplicantInterface *interface)
network, wifi))
break;
- /* We disable the selected network, if not then
- * wpa_supplicant will loop retrying */
- if (g_supplicant_interface_enable_selected_network(interface,
- FALSE) != 0)
- DBG("Could not disable selected network");
-
connman_network_set_connected(network, false);
connman_network_set_associating(network, false);
wifi->disconnecting = false;
@@ -2935,6 +2954,24 @@ static void debug(const char *str)
connman_debug("%s", str);
}
+static void wifi_disconnect_reasoncode(GSupplicantInterface *interface, int reasoncode)
+{
+ struct wifi_data *wifi = g_supplicant_interface_get_data(interface);
+
+ if (wifi != NULL) {
+ wifi->disconnect_reasoncode = reasoncode;
+ }
+}
+
+static void wifi_assoc_status_code(GSupplicantInterface *interface, int status_code)
+{
+ struct wifi_data *wifi = g_supplicant_interface_get_data(interface);
+
+ if (wifi != NULL) {
+ wifi->assoc_statuscode = status_code;
+ }
+}
+
static const GSupplicantCallbacks callbacks = {
.system_ready = system_ready,
.system_killed = system_killed,
@@ -2953,6 +2990,8 @@ static const GSupplicantCallbacks callbacks = {
.peer_changed = peer_changed,
.peer_request = peer_request,
.debug = debug,
+ .update_disconnect_reasoncode = wifi_disconnect_reasoncode,
+ .update_assoc_status_code = wifi_assoc_status_code,
};
--
2.8.0.rc3.226.g39d4020
4 years
[PATCH] Remove old ip/gateway address if different addresses are assigned during DHCP renewal to avoid two ip addresses added to the interface.
by Feng Wang
---
src/dhcp.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/src/dhcp.c b/src/dhcp.c
index 1d2cd48..54d98db 100644
--- a/src/dhcp.c
+++ b/src/dhcp.c
@@ -435,7 +435,7 @@ static void lease_available_cb(GDHCPClient *dhcp_client, gpointer user_data)
char *address, *netmask = NULL, *gateway = NULL;
const char *c_address, *c_gateway;
unsigned char prefixlen, c_prefixlen;
- bool ip_change;
+ bool ip_change = false;
DBG("Lease available");
@@ -467,14 +467,21 @@ static void lease_available_cb(GDHCPClient *dhcp_client, gpointer user_data)
DBG("c_address %s", c_address);
- if (g_strcmp0(address, c_address))
+ if (g_strcmp0(address, c_address)) {
ip_change = true;
- else if (g_strcmp0(gateway, c_gateway))
+ if (c_address) {
+ /* Remove old ip address */
+ __connman_ipconfig_address_remove(dhcp->ipconfig);
+ }
+ }
+ if (g_strcmp0(gateway, c_gateway)) {
ip_change = true;
- else if (prefixlen != c_prefixlen)
+ if (c_gateway) {
+ /* Remove gateway ip address */
+ __connman_ipconfig_gateway_remove(dhcp->ipconfig);
+ }
+ } else if (prefixlen != c_prefixlen)
ip_change = true;
- else
- ip_change = false;
__connman_ipconfig_set_method(dhcp->ipconfig,
CONNMAN_IPCONFIG_METHOD_DHCP);
--
2.8.0.rc3.226.g39d4020
4 years
Hooks for service connect and disconnect
by Martin Chaplet
Hi,
I have issues using a new QMI modem with ofono.
Although QMI standard tools (libqmi) are working very well, I can't use
ofono to make a data connection.
I'm so wondering if there is a way to add some "hooks" for connman to
implement service.connect and disconnect functions.
The idea is to use external tools to bring up/down interface and then
let Connman handle DHCP and more generally all IP and routing features.
Does it seem technically feasible ?
Thanks,
Martin
<http://www.kerlink.com>
4 years, 1 month
re-connect issues
by Thomas Green
We have developed an issue when we have changed a password on an access point. In the past, when we would try to connect, the agent would get a new "request input" call with a "Passphrase" and "Previous Passphrase" in the argument list. It seems what happens now is that we receive an invalid-key error from the connection call. We are running connman v 1.29.
Should we not still be getting the "Previous Passphrase"?
Tom
4 years, 1 month
Connman Ethernet/3G handover
by Florent Le Saout
Hi,
I'm looking for a network manager.
I would like to use ConnMan in an embedded system. It seems that it
provides most of the features I'm looking for, including 3G and VPN
management.
But after some research it seems that there is maybe one missing point
in it. Let say I have the following setup :
* Ethernet connection as preferred connection
* 3/4G connection as backup/failover connection
My Ethernet is always on and dhcp server is properly providing IP, cable
is still plugged in, and power on the line is still there, but sometimes
the internet connectivity is lost. So in that case it ll switch to the
3G/4G connection. But then as soon as possible, when connectivity is
back online via the ethernet, I want to switch back to it for
performance and cost reason.
Is this supported by default, or is there a way to configure it that way ?
I found this
post(http://comments.gmane.org/gmane.linux.network.connman/10238) which
seems to say that it was not supported at that time, since there is no
periodic check (February 2013).
And also from the documentation :
Autoconnecting
Favorite (saved) networks that have autoconnect enabled are
considered when autoconnecting services. These services are marked
with '*' and 'A' in connmanctl, respectively. By default ConnMan
autoconnects these in the order they are shown in the list of
services until one of them gets connected. After that the
autoconnected service is in use and ConnMan won't select a new one
until the network goes out of range. When the service goes out of
range or gets disconnected from the network infrastructure side,
autoconnect is re-run and another favorite autoconnectable service
is selected.
So I want to make sure I got the correct understanding on that ?
Feel free to ask for more informations if this is unclear.
Thanks for your support,
Florent.
--
*Florent LE SAOUT*
R&D department
Embedded Software Developer
KERLINK
4 years, 1 month
connman tether wifi
by 郑大利
Hello,
i'm using connman to manage my wifi.
When in tethering mode,
connmanctl > tether wifi on myNet 12345678,
my cellphone can connect the SSID named myNet,
1 but how connman knows who has connect the net?
2 how to limit the device quantity who wants to connect the tether net? the max device i want is 4.
Best wishes.
4 years, 1 month
[PATCH v3 0/6] Add nftables support
by Daniel Wagner
From: Daniel Wagner <daniel.wagner(a)bmw-carit.de>
Thanks Dragos for testing and feedback. I tested NAT so far which
works nicely for me. The session code part is next.
changes v3:
- fixed error handling when cleaning up (this time for real)
- dropped chain handlers (not used)
- tell kernel to load modules if needed via NLM_F_CREATE
- mask saddr address with netmask for NAT rule (bug fix)
changes v2:
- rebased to current master
- fixed some error handling path (memory leak)
- fixed typo and error handling reported by dtatulea
- compiler complains
- issue no warning if table cleaning up was successful
Daniel Wagner (6):
session: Install SNAT rules only once per device
firewall: Initialize iptables directly from firewall.c
firewall: Add explicit feature API
firewall: Rename firewall.c to firewall-iptables.c
firewall: Add nftables build infrastructure
firewall-nftables: Add nftable support for firewall
Makefile.am | 48 +-
configure.ac | 31 +-
src/connman.h | 22 +-
src/firewall-iptables.c | 622 +++++++++++++++++++++++++
src/firewall-nftables.c | 1153 +++++++++++++++++++++++++++++++++++++++++++++++
src/firewall.c | 542 ----------------------
src/main.c | 2 -
src/nat.c | 21 +-
src/session.c | 187 ++++----
tools/iptables-unit.c | 112 -----
10 files changed, 1940 insertions(+), 800 deletions(-)
create mode 100644 src/firewall-iptables.c
create mode 100644 src/firewall-nftables.c
delete mode 100644 src/firewall.c
--
2.5.5
4 years, 1 month
Re: autoload of nft modules
by Daniel Wagner
On 04/27/2016 02:54 PM, Pablo Neira Ayuso wrote:
> On Wed, Apr 27, 2016 at 10:52:13AM +0200, Daniel Wagner wrote:
>> Dragos and I are working on getting nft support into ConnMan [1]. Now we
>> face a small problem with the rule we load, which are essentially:
>>
>> nft add table connman
>> nft add chain connman nat-prerouting \
>> { type nat hook prerouting priortiy 0 ; }
>> nft add chain connman nat-postrouting \
>> { type nat hook postrouting priortiy 0 ; }
>> nft add chain connman filter-output \
>> { type filter hook output priority 0 ; }
>>
>> These work nicely using the nft CLI but when we run those commands
>> via libnftnl after a fresh reboot of the system, there is a ENOENT at
>> the third rule.
>
> Most likely you're missing the NLM_F_CREATE flags in your netlink
> messages.
Yes, that did they the trick.
> Please, send us patches for the example so other don't hit this
> problem.
Will do.
thanks,
daniel
4 years, 1 month
fedora systemd errors
by Vasiliy Tolstov
Hi! I'm check my systemd journal logs and see this errors:
Apr 29 01:44:39 acer.yoctocloud.net kernel: ath: phy0: Enable LNA combining
Apr 29 01:44:39 acer.yoctocloud.net kernel: ath: phy0: ASPM enabled: 0x42
Apr 29 01:44:39 acer.yoctocloud.net kernel: ath: EEPROM regdomain: 0x6c
Apr 29 01:44:39 acer.yoctocloud.net kernel: ath: EEPROM indicates we
should expect a direct regpair map
Apr 29 01:44:39 acer.yoctocloud.net kernel: ath: Country alpha2 being used: 00
Apr 29 01:44:39 acer.yoctocloud.net kernel: ath: Regpair used: 0x6c
Apr 29 01:44:39 acer.yoctocloud.net connmand[643]: wlan0 {create}
index 3 type 1 <ETHER>
Apr 29 01:44:39 acer.yoctocloud.net kernel: ieee80211 phy0: Selected
rate control algorithm 'minstrel_ht'
Apr 29 01:44:39 acer.yoctocloud.net kernel: ieee80211 phy0: Atheros
AR9565 Rev:2 mem=0xffffc90000500000, irq=18
Apr 29 01:44:39 acer.yoctocloud.net connmand[643]: wlan0 {update}
flags 4098 <DOWN>
Apr 29 01:44:39 acer.yoctocloud.net connmand[643]: wlan0 {newlink}
index 3 address B8:86:87:C7:CA:5D mtu 1500
Apr 29 01:44:39 acer.yoctocloud.net connmand[643]: wlan0 {newlink}
index 3 operstate 2 <DOWN>
Apr 29 01:44:39 acer.yoctocloud.net kernel: IPv6: ADDRCONF(NETDEV_UP):
wlan0: link is not ready
Apr 29 01:44:39 acer.yoctocloud.net connmand[643]: Adding interface
wlan0 [ wifi ]
Apr 29 01:44:39 acer.yoctocloud.net connmand[643]: wlan0 {update}
flags 36931 <UP,RUNNING>
te.
Apr 29 01:44:39 acer.yoctocloud.net connmand[643]: wlan0 {newlink}
index 3 address B8:86:87:C7:CA:5D mtu 1500
Apr 29 01:44:39 acer.yoctocloud.net connmand[643]: wlan0 {newlink}
index 3 operstate 0 <UNKNOWN>
Apr 29 01:44:39 acer.yoctocloud.net connmand[643]: wlan0 {update}
flags 36867 <UP>
Apr 29 01:44:39 acer.yoctocloud.net connmand[643]: wlan0 {newlink}
index 3 address B8:86:87:C7:CA:5D mtu 1500
Apr 29 01:44:39 acer.yoctocloud.net connmand[643]: wlan0 {newlink}
index 3 operstate 2 <DOWN>
Apr 29 01:44:39 acer.yoctocloud.net connmand[643]: wlan0 {newlink}
index 3 address B8:86:87:C7:CA:5D mtu 1500
Apr 29 01:44:39 acer.yoctocloud.net connmand[643]: wlan0 {newlink}
index 3 operstate 2 <DOWN>
Apr 29 01:44:39 acer.yoctocloud.net systemd-udevd[537]: Error changing
net interface name 'wlan0' to 'wlp2s0': Device or resource busy
Apr 29 01:44:39 acer.yoctocloud.net systemd-udevd[537]: could not
rename interface '3' from 'wlan0' to 'wlp2s0': Device or resource busy
Does it possible to allow rename device from wlan0?
As i understand systemd-udevd can't rename device because it already in up state
--
Vasiliy Tolstov,
e-mail: v.tolstov(a)selfip.ru
4 years, 1 month
