Right now iwd uses Control Port over NL80211 feature if the kernel /
driver supports it. On some kernels this feature is still buggy, so add
an iwd.conf entry to allow the user to override id.
For now the default is to disable this feature until it is more stable.
The single AP test worked fine, but adding a failure test caused some
problems. Since the kernel is never restarted between tests it maintains
old stale scan results from the previous test. This was causing an
assert to sometimes fail in the second test being run because it was
returning > 1 ordered networks. This change iterates through the ordered
network list and chooses the appropriate network rather than assuming
get_ordered_networks() will always return only one network object
Now, a user can setup an AP as follows:
- Set device "Mode" to ap (ap interface will appear on bus)
- call "Start()" on AP interface
Issuing "Stop()" on the AP interface will stop and cleanup
the internal AP structures, but the AP interface will remain
up. To shutdown completely the device Mode must be switched
back to station. If the AP interface is running, the Mode can
directly be switched to station without calling Stop; this
has the same effect and will take down the AP interface.
Some of the PEAP server implementation brake the protocol
and don’t set the M flag for the first packet during the
fragmented transmission. To stay compatible with such
devices, we relax this requirement in iwd.
This patch allows alternating between the passive and active
scans taking into consideration an existence of the known
hidden networks and previous observation of them in the scan
results, as well as an ability to randomize the MAC address.
The state of scan is split between the two variables sc->state
and sc->start_cmd_id. Not checking start_cmd_id used to cause
sending a scan request while periodic scan was just triggered
resulting in EBUSY.
Instead of manually sending a deauth/disassociate to a station
during an error or removal, the kernel can do it automatically
with DEL_STATION by including the MGMT_SUBTYPE attribute. This
removes the need for ap_error_deauth_sta and introduces
ap_deauthenticate_sta. Now AP can be explicit when it chooses
to deauth or disassociate.
All handshake packet handling has been removed from ap and
moved to eapol. After association, the AP registers a new
authenticator state machine which handles the AP side of
the handshake. AP will receive a handshake event once the
4-way handshake is complete.
Includes:
- support for handling ptk 2/4 and 4/4. Also sending 1/4 and 3/4.
- new API to register an authenticator SM. This automatically
sends 1/4 to kick off authentication with an sta.
These checks allow both a station and authenticator to use
the same netdev key install functions. For NEW_KEY and
SET_STATION, the iftype is checked and either handshake->aa
or ->spa is used as the station address for the KEY/STATION
commands. Also, in the failure cases, a disconnect command
is issued only if the iftype is station as this doesn't
apply to AP.
Handshake related netdev events were removed in favor of
handshake events. Now events will be emitted on the handshake
object related to the 4-way handshake and key settings. Events
are:
HANDSHAKE_EVENT_STARTED
HANDSHAKE_EVENT_SETTING_KEYS
HANDSHAKE_EVENT_COMPLETE
HANDSHAKE_EVENT_FAILED
Right now, since netdev only operates in station mode, nothing
listens for COMPLETE/FAILED, as device/wsc gets notified by the
connect_cb when the connection was successful. The COMPLETE/
FAILED were added in preperation for AP moving into eapol/netdev.
==1057== 32 bytes in 1 blocks are definitely lost in loss record 1 of 1
==1057== at 0x4C2AF0F: malloc (vg_replace_malloc.c:299)
==1057== by 0x15E9A2: l_malloc (util.c:62)
==1057== by 0x15EA9D: l_memdup (util.c:121)
==1057== by 0x133D9A: network_set_psk (network.c:350)
==1057== by 0x13BD29: wsc_try_credentials (wsc.c:136)
==1057== by 0x13C121: wsc_connect_cb (wsc.c:220)
==1057== by 0x110FAF: netdev_connect_failed (netdev.c:525)
==1057== by 0x16AAF4: process_unicast (genl.c:390)
==1057== by 0x16AF03: received_data (genl.c:509)
==1057== by 0x166CB6: io_callback (io.c:123)
==1057== by 0x16580D: l_main_iterate (main.c:376)
==1057== by 0x16594B: l_main_run (main.c:423)
load_settings ensures that ttls->eap is correctly initialized. So this
code should be treated as an error condition.
We also do not support EAP chaining, so remove that logic as well
CONFIG_DRIVER_NL80211 isn't an option for the kernel. Maybe it was
mistakenly added based on the hostap configuration instructions in
doc/test-runner.txt
If the intent was to add CONFIG_CFG80211 and CONFIG_MAC80211, they're
already in the relevant kernel defconfigs.
dbus_init() currently does not check for the g_dbus object being
properly initialized and this leads to crashes when dbus is not yet
running.
Ensure g_dbus is properly initialized and return false otherwise.
In this case the caller can understand that something went wrong and
stop the initialization procedure.
Program received signal SIGSEGV, Segmentation fault.
0x00005555555bc089 in l_dbus_add_service_watch (dbus=0x0,
name=0x5555555e5b0a "org.ofono",
connect_func=0x5555555aa81e <ofono_found>,
disconnect_func=0x5555555aa8e6 <ofono_disappeared>,
user_data=0x0, destroy=0x0) at ell/dbus.c:1621
1621 if (!dbus->name_cache)
(gdb) bt
name=0x5555555e5b0a "org.ofono",
connect_func=0x5555555aa81e <ofono_found>,
disconnect_func=0x5555555aa8e6 <ofono_disappeared>,
user_data=0x0, destroy=0x0) at ell/dbus.c:1621
user_data=0x0) at ell/plugin.c:115
function=0x5555555b40fd <plugin_start>,
user_data=0x0) at ell/queue.c:441
version=0x0) at ell/plugin.c:201
src/plugin.c:82
src/main.c:417
When the response structure is generated, not all of the memory was
initialized to 0.
==1045== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==1045== at 0x5134D52: send (in /lib64/libc-2.25.so)
==1045== by 0x168AB5: l_checksum_update (checksum.c:338)
==1045== by 0x186777: tls_write_mac (tls-record.c:58)
==1045== by 0x1869D1: tls_tx_record_plaintext (tls-record.c:120)
==1045== by 0x186DEA: tls_tx_record (tls-record.c:201)
==1045== by 0x185A3B: l_tls_write (tls.c:2064)
==1045== by 0x14584F: eap_ttls_eap_tx_packet (eap-ttls.c:321)
==1045== by 0x14236C: eap_send_response (eap.c:165)
==1045== by 0x147904: eap_mschapv2_send_response (eap-mschapv2.c:468)
==1045== by 0x147A10: eap_mschapv2_handle_challenge (eap-mschapv2.c:492)
==1045== by 0x147E9A: eap_mschapv2_handle_request (eap-mschapv2.c:615)
==1045== by 0x142693: __eap_handle_request (eap.c:240)
==1045== Address 0x1ffeffe7f9 is on thread 1's stack
==1045== in frame #4, created by tls_tx_record (tls-record.c:177)
==1045== Uninitialised value was created by a stack allocation
==1045== at 0x1477AE: eap_mschapv2_send_response (eap-mschapv2.c:443)
==1045==
==1045== Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s)
==1045== at 0x5134E3B: sendmsg (in /lib64/libc-2.25.so)
==1045== by 0x17F691: operate_cipher (cipher.c:356)
==1045== by 0x17F9D8: l_cipher_encrypt (cipher.c:446)
==1045== by 0x186BAA: tls_tx_record_plaintext (tls-record.c:152)
==1045== by 0x186DEA: tls_tx_record (tls-record.c:201)
==1045== by 0x185A3B: l_tls_write (tls.c:2064)
==1045== by 0x14584F: eap_ttls_eap_tx_packet (eap-ttls.c:321)
==1045== by 0x14236C: eap_send_response (eap.c:165)
==1045== by 0x147904: eap_mschapv2_send_response (eap-mschapv2.c:468)
==1045== by 0x147A10: eap_mschapv2_handle_challenge (eap-mschapv2.c:492)
==1045== by 0x147E9A: eap_mschapv2_handle_request (eap-mschapv2.c:615)
==1045== by 0x142693: __eap_handle_request (eap.c:240)
==1045== Address 0x1ffeffe7f9 is on thread 1's stack
==1045== in frame #4, created by tls_tx_record (tls-record.c:177)
==1045== Uninitialised value was created by a stack allocation
==1045== at 0x1477AE: eap_mschapv2_send_response (eap-mschapv2.c:443)
==1045==
