2019-09-10 11:19:01 +02:00
|
|
|
// SPDX-License-Identifier: GPL-2.0+
|
2019-09-25 13:13:40 +02:00
|
|
|
/*
|
2017-04-13 10:42:32 +02:00
|
|
|
* Copyright (C) 2006 - 2017 Red Hat, Inc.
|
2008-11-04 22:36:51 +00:00
|
|
|
* Copyright (C) 2007 - 2008 Novell, Inc.
|
2006-11-25 15:41:04 +00:00
|
|
|
*/
|
|
|
|
|
|
2017-01-18 17:41:12 +01:00
|
|
|
#ifndef __NM_SUPPLICANT_INTERFACE_H__
|
|
|
|
|
#define __NM_SUPPLICANT_INTERFACE_H__
|
2006-11-25 15:41:04 +00:00
|
|
|
|
|
|
|
|
#include "nm-supplicant-types.h"
|
|
|
|
|
|
2020-01-05 14:27:27 +01:00
|
|
|
#include "c-list/src/c-list.h"
|
|
|
|
|
|
2006-11-25 15:41:04 +00:00
|
|
|
/*
|
|
|
|
|
* Supplicant interface states
|
2010-10-06 11:05:21 -05:00
|
|
|
* A mix of wpa_supplicant interface states and internal states.
|
2006-11-25 15:41:04 +00:00
|
|
|
*/
|
2017-02-14 01:30:25 +01:00
|
|
|
typedef enum {
|
supplicant: large rework of wpa_supplicant handling
Avoid GDBusProxy, instead use GDBusConnection directly. I very much
prefer this because that way we have explicit control over what happens
on D-Bus. With GDBusProxy this is hidden under another layer of complex
code. The hardest part when using a D-Bus interface is to manage the
state via an asynchronous medium. GDBusProxy contains state about the
D-Bus interface and duplicate the state that we track. This makes it hard
to reason about things.
Rework creation of NMSupplicantInterface. Previously, a NMSupplicantInterface
had multiple initialization states. In particular, the first state would not
yet tie the interface to a certain D-Bus object path. Instead, NMSupplicantInterface
would try and retry to create the D-Bus object.
Now, NMSupplicantManager has an asynchronous method to create interface
instances. The manager only creates an interface instance after the D-Bus
path is known. That means, a NMSupplicantInterface instance is now
strongly tied to a name-owner and D-Bus path.
It follows that the state of NMSupplicantInterface can only go from STARTING,
via the supplicant states, to DOWN. Never back. That was already previously
the case that the state from DOWN was final and once the 3 initial
states were passed, the interface's state would never go back to the initial
state. Now this is more strict and more formalized. The 3 initialization states
are combined.
I think the tighter state handling simplifies users of NMSupplicantInterface.
See for example "nm-device-ethernet.c". It's still complicated, because handling
state is fundamentally difficult.
NMSupplicantManager will take care to D-Bus activate wpa_supplicant only
when necessary (poke). Previously, creating the manager instance
would always start suppliant service. Now, it's started on demand.
2020-01-21 15:05:16 +01:00
|
|
|
NM_SUPPLICANT_INTERFACE_STATE_INVALID = 0,
|
|
|
|
|
|
|
|
|
|
NM_SUPPLICANT_INTERFACE_STATE_STARTING = 1,
|
2020-01-08 15:37:38 +01:00
|
|
|
|
2012-05-11 17:15:40 -05:00
|
|
|
NM_SUPPLICANT_INTERFACE_STATE_DISABLED,
|
2010-10-06 11:05:21 -05:00
|
|
|
NM_SUPPLICANT_INTERFACE_STATE_DISCONNECTED,
|
|
|
|
|
NM_SUPPLICANT_INTERFACE_STATE_INACTIVE,
|
|
|
|
|
NM_SUPPLICANT_INTERFACE_STATE_SCANNING,
|
2011-03-17 12:35:58 -05:00
|
|
|
NM_SUPPLICANT_INTERFACE_STATE_AUTHENTICATING,
|
2010-10-06 11:05:21 -05:00
|
|
|
NM_SUPPLICANT_INTERFACE_STATE_ASSOCIATING,
|
|
|
|
|
NM_SUPPLICANT_INTERFACE_STATE_ASSOCIATED,
|
|
|
|
|
NM_SUPPLICANT_INTERFACE_STATE_4WAY_HANDSHAKE,
|
|
|
|
|
NM_SUPPLICANT_INTERFACE_STATE_GROUP_HANDSHAKE,
|
|
|
|
|
NM_SUPPLICANT_INTERFACE_STATE_COMPLETED,
|
2020-01-08 15:37:38 +01:00
|
|
|
|
2006-11-25 15:41:04 +00:00
|
|
|
NM_SUPPLICANT_INTERFACE_STATE_DOWN,
|
2017-02-14 01:30:25 +01:00
|
|
|
} NMSupplicantInterfaceState;
|
2006-11-25 15:41:04 +00:00
|
|
|
|
supplicant: large rework of wpa_supplicant handling
Avoid GDBusProxy, instead use GDBusConnection directly. I very much
prefer this because that way we have explicit control over what happens
on D-Bus. With GDBusProxy this is hidden under another layer of complex
code. The hardest part when using a D-Bus interface is to manage the
state via an asynchronous medium. GDBusProxy contains state about the
D-Bus interface and duplicate the state that we track. This makes it hard
to reason about things.
Rework creation of NMSupplicantInterface. Previously, a NMSupplicantInterface
had multiple initialization states. In particular, the first state would not
yet tie the interface to a certain D-Bus object path. Instead, NMSupplicantInterface
would try and retry to create the D-Bus object.
Now, NMSupplicantManager has an asynchronous method to create interface
instances. The manager only creates an interface instance after the D-Bus
path is known. That means, a NMSupplicantInterface instance is now
strongly tied to a name-owner and D-Bus path.
It follows that the state of NMSupplicantInterface can only go from STARTING,
via the supplicant states, to DOWN. Never back. That was already previously
the case that the state from DOWN was final and once the 3 initial
states were passed, the interface's state would never go back to the initial
state. Now this is more strict and more formalized. The 3 initialization states
are combined.
I think the tighter state handling simplifies users of NMSupplicantInterface.
See for example "nm-device-ethernet.c". It's still complicated, because handling
state is fundamentally difficult.
NMSupplicantManager will take care to D-Bus activate wpa_supplicant only
when necessary (poke). Previously, creating the manager instance
would always start suppliant service. Now, it's started on demand.
2020-01-21 15:05:16 +01:00
|
|
|
static inline gboolean
|
2020-04-01 11:56:21 +02:00
|
|
|
nm_supplicant_interface_state_is_operational (NMSupplicantInterfaceState state)
|
supplicant: large rework of wpa_supplicant handling
Avoid GDBusProxy, instead use GDBusConnection directly. I very much
prefer this because that way we have explicit control over what happens
on D-Bus. With GDBusProxy this is hidden under another layer of complex
code. The hardest part when using a D-Bus interface is to manage the
state via an asynchronous medium. GDBusProxy contains state about the
D-Bus interface and duplicate the state that we track. This makes it hard
to reason about things.
Rework creation of NMSupplicantInterface. Previously, a NMSupplicantInterface
had multiple initialization states. In particular, the first state would not
yet tie the interface to a certain D-Bus object path. Instead, NMSupplicantInterface
would try and retry to create the D-Bus object.
Now, NMSupplicantManager has an asynchronous method to create interface
instances. The manager only creates an interface instance after the D-Bus
path is known. That means, a NMSupplicantInterface instance is now
strongly tied to a name-owner and D-Bus path.
It follows that the state of NMSupplicantInterface can only go from STARTING,
via the supplicant states, to DOWN. Never back. That was already previously
the case that the state from DOWN was final and once the 3 initial
states were passed, the interface's state would never go back to the initial
state. Now this is more strict and more formalized. The 3 initialization states
are combined.
I think the tighter state handling simplifies users of NMSupplicantInterface.
See for example "nm-device-ethernet.c". It's still complicated, because handling
state is fundamentally difficult.
NMSupplicantManager will take care to D-Bus activate wpa_supplicant only
when necessary (poke). Previously, creating the manager instance
would always start suppliant service. Now, it's started on demand.
2020-01-21 15:05:16 +01:00
|
|
|
{
|
|
|
|
|
return state > NM_SUPPLICANT_INTERFACE_STATE_STARTING
|
|
|
|
|
&& state < NM_SUPPLICANT_INTERFACE_STATE_DOWN;
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-20 12:22:00 +01:00
|
|
|
static inline gboolean
|
|
|
|
|
nm_supplicant_interface_state_is_associated (NMSupplicantInterfaceState state)
|
|
|
|
|
{
|
|
|
|
|
return state >= NM_SUPPLICANT_INTERFACE_STATE_AUTHENTICATING
|
|
|
|
|
&& state <= NM_SUPPLICANT_INTERFACE_STATE_COMPLETED;
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-22 10:19:24 +02:00
|
|
|
typedef enum {
|
|
|
|
|
NM_SUPPLICANT_AUTH_STATE_UNKNOWN,
|
|
|
|
|
NM_SUPPLICANT_AUTH_STATE_STARTED,
|
|
|
|
|
NM_SUPPLICANT_AUTH_STATE_SUCCESS,
|
|
|
|
|
NM_SUPPLICANT_AUTH_STATE_FAILURE,
|
|
|
|
|
_NM_SUPPLICANT_AUTH_STATE_NUM,
|
|
|
|
|
} NMSupplicantAuthState;
|
|
|
|
|
|
2006-11-25 15:41:04 +00:00
|
|
|
#define NM_TYPE_SUPPLICANT_INTERFACE (nm_supplicant_interface_get_type ())
|
|
|
|
|
#define NM_SUPPLICANT_INTERFACE(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), NM_TYPE_SUPPLICANT_INTERFACE, NMSupplicantInterface))
|
|
|
|
|
#define NM_SUPPLICANT_INTERFACE_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST ((klass), NM_TYPE_SUPPLICANT_INTERFACE, NMSupplicantInterfaceClass))
|
|
|
|
|
#define NM_IS_SUPPLICANT_INTERFACE(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), NM_TYPE_SUPPLICANT_INTERFACE))
|
|
|
|
|
#define NM_IS_SUPPLICANT_INTERFACE_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass), NM_TYPE_SUPPLICANT_INTERFACE))
|
|
|
|
|
#define NM_SUPPLICANT_INTERFACE_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj), NM_TYPE_SUPPLICANT_INTERFACE, NMSupplicantInterfaceClass))
|
|
|
|
|
|
supplicant: large rework of wpa_supplicant handling
Avoid GDBusProxy, instead use GDBusConnection directly. I very much
prefer this because that way we have explicit control over what happens
on D-Bus. With GDBusProxy this is hidden under another layer of complex
code. The hardest part when using a D-Bus interface is to manage the
state via an asynchronous medium. GDBusProxy contains state about the
D-Bus interface and duplicate the state that we track. This makes it hard
to reason about things.
Rework creation of NMSupplicantInterface. Previously, a NMSupplicantInterface
had multiple initialization states. In particular, the first state would not
yet tie the interface to a certain D-Bus object path. Instead, NMSupplicantInterface
would try and retry to create the D-Bus object.
Now, NMSupplicantManager has an asynchronous method to create interface
instances. The manager only creates an interface instance after the D-Bus
path is known. That means, a NMSupplicantInterface instance is now
strongly tied to a name-owner and D-Bus path.
It follows that the state of NMSupplicantInterface can only go from STARTING,
via the supplicant states, to DOWN. Never back. That was already previously
the case that the state from DOWN was final and once the 3 initial
states were passed, the interface's state would never go back to the initial
state. Now this is more strict and more formalized. The 3 initialization states
are combined.
I think the tighter state handling simplifies users of NMSupplicantInterface.
See for example "nm-device-ethernet.c". It's still complicated, because handling
state is fundamentally difficult.
NMSupplicantManager will take care to D-Bus activate wpa_supplicant only
when necessary (poke). Previously, creating the manager instance
would always start suppliant service. Now, it's started on demand.
2020-01-21 15:05:16 +01:00
|
|
|
#define NM_SUPPLICANT_INTERFACE_SUPPLICANT_MANAGER "supplicant-manager"
|
|
|
|
|
#define NM_SUPPLICANT_INTERFACE_DBUS_OBJECT_PATH "dbus-object-path"
|
|
|
|
|
#define NM_SUPPLICANT_INTERFACE_IFINDEX "ifindex"
|
2020-01-05 07:33:15 +01:00
|
|
|
#define NM_SUPPLICANT_INTERFACE_SCANNING "scanning"
|
|
|
|
|
#define NM_SUPPLICANT_INTERFACE_CURRENT_BSS "current-bss"
|
|
|
|
|
#define NM_SUPPLICANT_INTERFACE_P2P_GROUP_JOINED "p2p-group-joined"
|
|
|
|
|
#define NM_SUPPLICANT_INTERFACE_P2P_GROUP_PATH "p2p-group-path"
|
|
|
|
|
#define NM_SUPPLICANT_INTERFACE_P2P_GROUP_OWNER "p2p-group-owner"
|
|
|
|
|
#define NM_SUPPLICANT_INTERFACE_DRIVER "driver"
|
|
|
|
|
#define NM_SUPPLICANT_INTERFACE_P2P_AVAILABLE "p2p-available"
|
|
|
|
|
#define NM_SUPPLICANT_INTERFACE_AUTH_STATE "auth-state"
|
|
|
|
|
|
|
|
|
|
#define NM_SUPPLICANT_INTERFACE_STATE "state"
|
supplicant: large rework of wpa_supplicant handling
Avoid GDBusProxy, instead use GDBusConnection directly. I very much
prefer this because that way we have explicit control over what happens
on D-Bus. With GDBusProxy this is hidden under another layer of complex
code. The hardest part when using a D-Bus interface is to manage the
state via an asynchronous medium. GDBusProxy contains state about the
D-Bus interface and duplicate the state that we track. This makes it hard
to reason about things.
Rework creation of NMSupplicantInterface. Previously, a NMSupplicantInterface
had multiple initialization states. In particular, the first state would not
yet tie the interface to a certain D-Bus object path. Instead, NMSupplicantInterface
would try and retry to create the D-Bus object.
Now, NMSupplicantManager has an asynchronous method to create interface
instances. The manager only creates an interface instance after the D-Bus
path is known. That means, a NMSupplicantInterface instance is now
strongly tied to a name-owner and D-Bus path.
It follows that the state of NMSupplicantInterface can only go from STARTING,
via the supplicant states, to DOWN. Never back. That was already previously
the case that the state from DOWN was final and once the 3 initial
states were passed, the interface's state would never go back to the initial
state. Now this is more strict and more formalized. The 3 initialization states
are combined.
I think the tighter state handling simplifies users of NMSupplicantInterface.
See for example "nm-device-ethernet.c". It's still complicated, because handling
state is fundamentally difficult.
NMSupplicantManager will take care to D-Bus activate wpa_supplicant only
when necessary (poke). Previously, creating the manager instance
would always start suppliant service. Now, it's started on demand.
2020-01-21 15:05:16 +01:00
|
|
|
#define NM_SUPPLICANT_INTERFACE_BSS_CHANGED "bss-changed"
|
|
|
|
|
#define NM_SUPPLICANT_INTERFACE_PEER_CHANGED "peer-changed"
|
2020-01-05 07:33:15 +01:00
|
|
|
#define NM_SUPPLICANT_INTERFACE_WPS_CREDENTIALS "wps-credentials"
|
2018-10-10 23:08:15 +02:00
|
|
|
#define NM_SUPPLICANT_INTERFACE_GROUP_STARTED "group-started"
|
|
|
|
|
#define NM_SUPPLICANT_INTERFACE_GROUP_FINISHED "group-finished"
|
2010-11-22 08:25:09 -06:00
|
|
|
|
2016-09-28 15:58:24 +02:00
|
|
|
typedef struct _NMSupplicantInterfaceClass NMSupplicantInterfaceClass;
|
2006-11-25 15:41:04 +00:00
|
|
|
|
2020-01-05 14:27:27 +01:00
|
|
|
struct _NMSupplicantInterfacePrivate;
|
|
|
|
|
|
|
|
|
|
struct _NMSupplicantInterface {
|
|
|
|
|
GObject parent;
|
|
|
|
|
CList supp_lst;
|
|
|
|
|
struct _NMSupplicantInterfacePrivate *_priv;
|
|
|
|
|
};
|
|
|
|
|
|
2006-11-25 15:41:04 +00:00
|
|
|
GType nm_supplicant_interface_get_type (void);
|
|
|
|
|
|
supplicant: large rework of wpa_supplicant handling
Avoid GDBusProxy, instead use GDBusConnection directly. I very much
prefer this because that way we have explicit control over what happens
on D-Bus. With GDBusProxy this is hidden under another layer of complex
code. The hardest part when using a D-Bus interface is to manage the
state via an asynchronous medium. GDBusProxy contains state about the
D-Bus interface and duplicate the state that we track. This makes it hard
to reason about things.
Rework creation of NMSupplicantInterface. Previously, a NMSupplicantInterface
had multiple initialization states. In particular, the first state would not
yet tie the interface to a certain D-Bus object path. Instead, NMSupplicantInterface
would try and retry to create the D-Bus object.
Now, NMSupplicantManager has an asynchronous method to create interface
instances. The manager only creates an interface instance after the D-Bus
path is known. That means, a NMSupplicantInterface instance is now
strongly tied to a name-owner and D-Bus path.
It follows that the state of NMSupplicantInterface can only go from STARTING,
via the supplicant states, to DOWN. Never back. That was already previously
the case that the state from DOWN was final and once the 3 initial
states were passed, the interface's state would never go back to the initial
state. Now this is more strict and more formalized. The 3 initialization states
are combined.
I think the tighter state handling simplifies users of NMSupplicantInterface.
See for example "nm-device-ethernet.c". It's still complicated, because handling
state is fundamentally difficult.
NMSupplicantManager will take care to D-Bus activate wpa_supplicant only
when necessary (poke). Previously, creating the manager instance
would always start suppliant service. Now, it's started on demand.
2020-01-21 15:05:16 +01:00
|
|
|
NMSupplicantInterface *nm_supplicant_interface_new (NMSupplicantManager *supplicant_manager,
|
|
|
|
|
NMRefString *object_path,
|
|
|
|
|
int ifindex,
|
|
|
|
|
NMSupplicantDriver driver);
|
|
|
|
|
|
|
|
|
|
NMRefString *nm_supplicant_interface_get_name_owner (NMSupplicantInterface *self);
|
|
|
|
|
NMRefString *nm_supplicant_interface_get_object_path (NMSupplicantInterface * iface);
|
2006-11-25 15:41:04 +00:00
|
|
|
|
supplicant: large rework of wpa_supplicant handling
Avoid GDBusProxy, instead use GDBusConnection directly. I very much
prefer this because that way we have explicit control over what happens
on D-Bus. With GDBusProxy this is hidden under another layer of complex
code. The hardest part when using a D-Bus interface is to manage the
state via an asynchronous medium. GDBusProxy contains state about the
D-Bus interface and duplicate the state that we track. This makes it hard
to reason about things.
Rework creation of NMSupplicantInterface. Previously, a NMSupplicantInterface
had multiple initialization states. In particular, the first state would not
yet tie the interface to a certain D-Bus object path. Instead, NMSupplicantInterface
would try and retry to create the D-Bus object.
Now, NMSupplicantManager has an asynchronous method to create interface
instances. The manager only creates an interface instance after the D-Bus
path is known. That means, a NMSupplicantInterface instance is now
strongly tied to a name-owner and D-Bus path.
It follows that the state of NMSupplicantInterface can only go from STARTING,
via the supplicant states, to DOWN. Never back. That was already previously
the case that the state from DOWN was final and once the 3 initial
states were passed, the interface's state would never go back to the initial
state. Now this is more strict and more formalized. The 3 initialization states
are combined.
I think the tighter state handling simplifies users of NMSupplicantInterface.
See for example "nm-device-ethernet.c". It's still complicated, because handling
state is fundamentally difficult.
NMSupplicantManager will take care to D-Bus activate wpa_supplicant only
when necessary (poke). Previously, creating the manager instance
would always start suppliant service. Now, it's started on demand.
2020-01-21 15:05:16 +01:00
|
|
|
void _nm_supplicant_interface_set_state_down (NMSupplicantInterface * self,
|
|
|
|
|
gboolean force_remove_from_supplicant,
|
|
|
|
|
const char *reason);
|
2015-02-01 03:08:16 -06:00
|
|
|
|
2017-02-14 19:30:21 +01:00
|
|
|
typedef void (*NMSupplicantInterfaceAssocCb) (NMSupplicantInterface *iface,
|
|
|
|
|
GError *error,
|
|
|
|
|
gpointer user_data);
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
nm_supplicant_interface_assoc (NMSupplicantInterface *self,
|
|
|
|
|
NMSupplicantConfig *cfg,
|
|
|
|
|
NMSupplicantInterfaceAssocCb callback,
|
|
|
|
|
gpointer user_data);
|
2006-12-19 19:15:31 +00:00
|
|
|
|
|
|
|
|
void nm_supplicant_interface_disconnect (NMSupplicantInterface * iface);
|
2006-11-25 15:41:04 +00:00
|
|
|
|
2019-02-21 11:06:55 +01:00
|
|
|
typedef void (*NMSupplicantInterfaceDisconnectCb) (NMSupplicantInterface *iface,
|
|
|
|
|
GError *error,
|
|
|
|
|
gpointer user_data);
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
nm_supplicant_interface_disconnect_async (NMSupplicantInterface * self,
|
|
|
|
|
GCancellable * cancellable,
|
|
|
|
|
NMSupplicantInterfaceDisconnectCb callback,
|
|
|
|
|
gpointer user_data);
|
|
|
|
|
|
2020-04-24 16:42:13 +02:00
|
|
|
typedef void (*NMSupplicantInterfaceRequestScanCallback) (NMSupplicantInterface *self,
|
|
|
|
|
GCancellable *cancellable,
|
|
|
|
|
gpointer user_data);
|
|
|
|
|
|
2018-08-12 11:43:25 +02:00
|
|
|
void nm_supplicant_interface_request_scan (NMSupplicantInterface *self,
|
|
|
|
|
GBytes *const*ssids,
|
2020-04-24 16:42:13 +02:00
|
|
|
guint ssids_len,
|
|
|
|
|
GCancellable *cancellable,
|
|
|
|
|
NMSupplicantInterfaceRequestScanCallback callback,
|
|
|
|
|
gpointer user_data);
|
2006-11-26 Dan Williams <dcbw@redhat.com>
Scan using wpa_supplicant over DBus.
* src/nm-device-802-11-wireless.c
- remove wireless extensions netlink event handler bits
(wireless_event_helper, nm_device_802_11_wireless_event)
- remove wireless extensions scan event handler bits
(process_scan_results, add_new_ap_to_device_list, hexstr2bin,
hex2byte, hex2num, request_and_convert_scan_results,
free_process_scan_cb_data, scan_results_timeout,
schedule_scan_results_timeout, cancel_scan_results_timeout)
- Rename nm_device_802_11_wireless_scan() -> request_wireless_scan()
and request scans from the supplicant interface rather than directly
- Move functionality of convert_scan_results() to cull_scan_list() and
supplicant_iface_scanned_ap_cb()
- (supplicant_iface_scan_result_cb): new function; schedule a new scan
at the scan interval when the current scan has finished
- (supplicant_iface_state_cb): start scanning when the supplicant
interface enters the READY state, and stop scanning when it
enters the DOWN state
- (cull_scan_list): weed out old access points from the scan list
- (supplicant_iface_scanned_ap_cb): convert a supplicant scanned access
point into an NMAccessPoint and merge it into the device's scan list
* src/supplicant-manager/nm-supplicant-interface.c
src/supplicant-manager/nm-supplicant-interface.h
- Add a new signal "scan-result" which is issued when the supplicant
notifies NM that a scan has completed
- Add a new signal "scanned-ap" that notifies listeners of a new access
point found in the scan. Called once for each access point that
the supplicant interface object receives from the supplicant as a
result of the "scanResults" method call
- (wpas_iface_query_scan_results): don't wait 4s before querying
for the initial scan results
- (scan_request_cb): new function; send listeners the result
(success, error) of a wireless scan request
- (nm_supplicant_interface_request_scan): new function; ask the
supplicant to perform an immediate wireless scan
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2128 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2006-11-26 20:49:48 +00:00
|
|
|
|
2017-02-14 01:30:25 +01:00
|
|
|
NMSupplicantInterfaceState nm_supplicant_interface_get_state (NMSupplicantInterface * self);
|
2006-12-04 19:09:44 +00:00
|
|
|
|
2017-02-14 01:30:25 +01:00
|
|
|
const char *nm_supplicant_interface_state_to_string (NMSupplicantInterfaceState state);
|
2008-10-26 16:32:29 +00:00
|
|
|
|
2009-05-13 11:16:29 -04:00
|
|
|
gboolean nm_supplicant_interface_get_scanning (NMSupplicantInterface *self);
|
|
|
|
|
|
supplicant: large rework of wpa_supplicant handling
Avoid GDBusProxy, instead use GDBusConnection directly. I very much
prefer this because that way we have explicit control over what happens
on D-Bus. With GDBusProxy this is hidden under another layer of complex
code. The hardest part when using a D-Bus interface is to manage the
state via an asynchronous medium. GDBusProxy contains state about the
D-Bus interface and duplicate the state that we track. This makes it hard
to reason about things.
Rework creation of NMSupplicantInterface. Previously, a NMSupplicantInterface
had multiple initialization states. In particular, the first state would not
yet tie the interface to a certain D-Bus object path. Instead, NMSupplicantInterface
would try and retry to create the D-Bus object.
Now, NMSupplicantManager has an asynchronous method to create interface
instances. The manager only creates an interface instance after the D-Bus
path is known. That means, a NMSupplicantInterface instance is now
strongly tied to a name-owner and D-Bus path.
It follows that the state of NMSupplicantInterface can only go from STARTING,
via the supplicant states, to DOWN. Never back. That was already previously
the case that the state from DOWN was final and once the 3 initial
states were passed, the interface's state would never go back to the initial
state. Now this is more strict and more formalized. The 3 initialization states
are combined.
I think the tighter state handling simplifies users of NMSupplicantInterface.
See for example "nm-device-ethernet.c". It's still complicated, because handling
state is fundamentally difficult.
NMSupplicantManager will take care to D-Bus activate wpa_supplicant only
when necessary (poke). Previously, creating the manager instance
would always start suppliant service. Now, it's started on demand.
2020-01-21 15:05:16 +01:00
|
|
|
NMRefString *nm_supplicant_interface_get_current_bss (NMSupplicantInterface *self);
|
2015-04-05 23:31:02 -05:00
|
|
|
|
2018-06-15 13:57:30 +02:00
|
|
|
gint64 nm_supplicant_interface_get_last_scan (NMSupplicantInterface *self);
|
2012-06-07 15:04:14 -05:00
|
|
|
|
2010-10-05 14:19:56 -05:00
|
|
|
const char *nm_supplicant_interface_get_ifname (NMSupplicantInterface *self);
|
|
|
|
|
|
2012-05-01 17:59:35 -05:00
|
|
|
guint nm_supplicant_interface_get_max_scan_ssids (NMSupplicantInterface *self);
|
|
|
|
|
|
supplicant: large rework of wpa_supplicant handling
Avoid GDBusProxy, instead use GDBusConnection directly. I very much
prefer this because that way we have explicit control over what happens
on D-Bus. With GDBusProxy this is hidden under another layer of complex
code. The hardest part when using a D-Bus interface is to manage the
state via an asynchronous medium. GDBusProxy contains state about the
D-Bus interface and duplicate the state that we track. This makes it hard
to reason about things.
Rework creation of NMSupplicantInterface. Previously, a NMSupplicantInterface
had multiple initialization states. In particular, the first state would not
yet tie the interface to a certain D-Bus object path. Instead, NMSupplicantInterface
would try and retry to create the D-Bus object.
Now, NMSupplicantManager has an asynchronous method to create interface
instances. The manager only creates an interface instance after the D-Bus
path is known. That means, a NMSupplicantInterface instance is now
strongly tied to a name-owner and D-Bus path.
It follows that the state of NMSupplicantInterface can only go from STARTING,
via the supplicant states, to DOWN. Never back. That was already previously
the case that the state from DOWN was final and once the 3 initial
states were passed, the interface's state would never go back to the initial
state. Now this is more strict and more formalized. The 3 initialization states
are combined.
I think the tighter state handling simplifies users of NMSupplicantInterface.
See for example "nm-device-ethernet.c". It's still complicated, because handling
state is fundamentally difficult.
NMSupplicantManager will take care to D-Bus activate wpa_supplicant only
when necessary (poke). Previously, creating the manager instance
would always start suppliant service. Now, it's started on demand.
2020-01-21 15:05:16 +01:00
|
|
|
gboolean nm_supplicant_interface_get_p2p_available (NMSupplicantInterface *self);
|
|
|
|
|
|
2018-10-10 23:08:15 +02:00
|
|
|
gboolean nm_supplicant_interface_get_p2p_group_joined (NMSupplicantInterface *self);
|
|
|
|
|
|
2018-12-11 18:21:37 +01:00
|
|
|
const char* nm_supplicant_interface_get_p2p_group_path (NMSupplicantInterface *self);
|
|
|
|
|
|
2018-10-10 23:08:15 +02:00
|
|
|
gboolean nm_supplicant_interface_get_p2p_group_owner (NMSupplicantInterface *self);
|
|
|
|
|
|
2018-10-15 15:11:34 +02:00
|
|
|
void nm_supplicant_interface_p2p_start_find (NMSupplicantInterface *self,
|
|
|
|
|
guint timeout);
|
|
|
|
|
void nm_supplicant_interface_p2p_stop_find (NMSupplicantInterface *self);
|
|
|
|
|
|
2018-10-10 23:14:08 +02:00
|
|
|
void nm_supplicant_interface_p2p_connect (NMSupplicantInterface * self,
|
|
|
|
|
const char * peer,
|
|
|
|
|
const char * wps_method,
|
|
|
|
|
const char * wps_pin);
|
|
|
|
|
void nm_supplicant_interface_p2p_cancel_connect (NMSupplicantInterface * self);
|
|
|
|
|
void nm_supplicant_interface_p2p_disconnect (NMSupplicantInterface * self);
|
|
|
|
|
|
2020-01-05 07:33:15 +01:00
|
|
|
void nm_supplicant_interface_set_global_capabilities (NMSupplicantInterface *self,
|
|
|
|
|
NMSupplCapMask value);
|
2012-09-18 17:33:57 -05:00
|
|
|
|
2020-01-05 07:33:15 +01:00
|
|
|
NMTernary nm_supplicant_interface_get_capability (NMSupplicantInterface *self,
|
|
|
|
|
NMSupplCapType type);
|
2012-09-18 17:33:57 -05:00
|
|
|
|
2020-01-05 07:33:15 +01:00
|
|
|
NMSupplCapMask nm_supplicant_interface_get_capabilities (NMSupplicantInterface *self);
|
2019-07-15 11:30:19 +00:00
|
|
|
|
2017-04-13 10:42:32 +02:00
|
|
|
void nm_supplicant_interface_enroll_wps (NMSupplicantInterface *self,
|
|
|
|
|
const char *const type,
|
|
|
|
|
const char *bssid,
|
|
|
|
|
const char *pin);
|
|
|
|
|
|
|
|
|
|
void nm_supplicant_interface_cancel_wps (NMSupplicantInterface *self);
|
|
|
|
|
|
2019-08-22 10:19:24 +02:00
|
|
|
NMSupplicantAuthState nm_supplicant_interface_get_auth_state (NMSupplicantInterface *self);
|
|
|
|
|
|
2017-01-18 17:41:12 +01:00
|
|
|
#endif /* __NM_SUPPLICANT_INTERFACE_H__ */
|
