Instead of using a flag ipv4_static, just store the value of the rtm
protocol directly inside netconfig object. This allows us to simplify
the logic quite significantly and avoid repeating the conditional
expression needlessly
The routes are installed as a result of a successful installation
of the IP addresses. The gateway is fetched with netconfig_ipv4_get_gateway
helper function according to the origin of the installed IP address.
The route priority offset can be set in main.conf. The default value
of 300 is used if the offset isn’t set.
The API allows to add connected and gateway routes to the main
routing table.
rtnl_route_ipv4_add_gateway() is equivalent to the following
example 'ip route' command:
ip route add default via 10.0.0.1 dev wlan0 proto dhcp src 10.0.0.2 metric 339
rtnl_route_ipv4_add_connected() is equivalent to the following
example 'ip route' command:
sudo ip route add 10.0.0.0/24 dev wlan0 proto dhcp src 10.0.0.2 scope link
The 'ip route' output from the above commands looks as follows:
rtnl_route_ipv4_add_connected():
10.0.0.0/24 dev wlan0 proto dhcp scope link src 10.0.0.2
rtnl_route_ipv4_add_gateway():
default via 10.0.0.1 dev wlan0 proto dhcp src 10.0.0.2 metric 339
The DNS addresses are installed as a result of a successful
installation of the IP addresses. The DNS lists are fetched
with netconfig_ipv4_get_dns helper function according to the
origin of the installed IP address.
iwd reconfigures the wireless interfaces with respective
connection events. Each supported network protocol is
reconfigured. The address for each protocol is
selected as static or dynamic based on availability.
netconfig_ipv4_get_ifaddr helper function allows to fetch IPv4
addresses from static or dynamic sources. The origin of the addresses
is noted in 'ipv4_is_static' flag.
For (Re)Association the HS20 indication element was passed exactly as
it was found in the scan results. The spec defines what bits can be
set and what cannot when this IE is used in (Re)Association. Instead
of assuming the AP's IE conforms to the spec, we now parse the IE and
re-build it for use with (Re)Association.
Since the full IE is no longer used, it was removed from scan_bss, and
replaced with a bit for HS20 support (hs20_capable). This member is
now used the same as hs20_ie was.
The version parsed during scan results is now used when building the
(Re)Association IE.
The parser fully parses the IE and returns the version, Domain ID,
and PPS MO ID. This is meant to be used with an IE in scan results.
The builder only takes the version number, and assumes DGAF disabled,
and no Domain ID or PPS MO ID.
Previously, iwd used to throw net.connman.iwd.Busy when connection
attempt was made while connected. The new behavior allows iwd to
seamlessly disconnect from the connected network and attempt a new
connection.
Since NAI realms, Roaming Consortium and HESSID are defined in 802.11,
they are not a guarentee that the network is Hotspot 2.0. The indication
element in addition to these IE's gives a better idea of Hotspot 2.0
support. Now, when a BSS is added this is_hs20 boolean will get set to
true if the HS20 IE was found in the BSS.
Now, if is_hs20 is set AND one of NAI realms, roaming consortium, or
HESSID is set we know this is a hotspot 2.0 network.
It is possible for a zero-length anti-clogging token payload to cause
IWD to abort. If the length passed into sae_process_anti_clogging was
1, l_memdup would be called with a size of -1. This will cause malloc
to abort.
Fix this by checking for a minimum packet length and dropping the
packet if the length is too small.
The HS20 indication element should always be included during
(Re)Association per the spec. This removes the need for a
dedicated boolean, and now the hs20_ie can be used instead.
The hotspot spec specifically mentions the roaming consortium OI be
3 or 5 bytes long. This requirement also prevents potential buffer
overflows if the user were to configure a long roaming consortium OI.
If the scan was triggered and later aborted, make sure to reset the
triggered value when the CMD_NEW_SCAN_RESULTS event comes in.
src/station.c:station_enter_state() Old State: disconnected, new state: connecting
src/scan.c:scan_notify() Scan notification 33
src/station.c:station_netdev_event() Associating
src/scan.c:scan_notify() Scan notification 34
Aborting (signal 11) [/home/denkenz/iwd-master/src/iwd]
++++++++ backtrace ++++++++
#0 0x7efd4d6a2ef0 in /lib64/libc.so.6
#1 0x42b20d in scan_notify() at src/scan.c:1383
In the same fashion as the WSC WFA OUI, ie.[ch] will now expose the
other vendor OUIs to avoid duplication across multiple files in IWD
as well as used in iwmon.
P2P probe requests are to be sent at min 6.0 Mb/s using OFDM,
specifically the 802.11b rates are prohibited (section 2.4.1 in Wi-Fi
P2p Technical Spec v1.7), some of which use CCK modulation. This is
already the default for 5G but for 2.4G the drivers generally do this
if we set the NL80211_ATTR_TX_NO_CCK_RATE flags with
NL80211_CMD_TRIGGER_SCAN.
The length check was incorrectly assuming that PPS MO ID or
ANQP Domain ID would be present in the IE. Both these are optional
and without then the minimum length is 5 bytes, not 7.
Per the hotspot 2.0 spec, if a matching roaming consortium OI is
found it should be added to the (Re)Association request. vendor_ies
can now be provided to netdev_connect, which get appended to the IE
attribute.
This API will attempt to find a matching roaming consortium OI
if present in the config file. A single matching OI is returned
or NULL if one was not found.
Hotspot 2.0 network providers allow 'roaming' between a users home
network and other providers networks, assuming they are part of the
same roaming consortium. The roaming consortium is advertised as an
IE in beacon/probe frames.
In terms of the hotspot config files this is similar to HESSID, where
if the AP advertises the roaming consortium IE, and the config file
matches we do not need to do ANQP in order to connect.
This is duplicated when the first scan_bss is added to a network
object that contains the IE. Any future BSS's added will not re-add
the IE. Its assumed that all BSS's under a network will contain the
same roaming consortium OIs.
Parses up to 3 (the max) roaming consortium OIs out of the roaming
consortium IE. If more OIs are available via ANQP the 'num_anqp_out'
value will be set to indicate how many more OIs are available.
Builds according to the hotspot 2.0 spec using the vendor specific
IE.
Declare structures to hold the parsed contents of the P2P IEs and WSC
IEs in P2P-related frames and add functions to free memory used by
those structures.
Define structs and types for most P2P attributes and p2p_parse_attrs
similar to wsc_parse_attrs -- a generic parser for attributes in a P2P
IE payload. This parser may write into the provided buffer even on
error but it's private to p2putil.c. The local callers will take care
of keeping the user-provided buffers untouched on error.
Add a utility for building the simplified WSC IEs used in P2P action
frames and public action frames. Only three types of WSC attributes are
mandatory in those frames (but different subsets are needed by different
frame types) so add a single utility for building those IEs. We may
need to add some more optional attributes to those IEs later.
The ifindex is used to index the netdevs in the system (wlan, ethernet,
etc.) but we can also do wifi scanning on interfaces that have no
corresponding netdev object, like the P2P-device virtual interfaces.
Use the wdev id's to reference interfaces, the nl80211 api doesn't care
whether we use a NL80211_ATTR_IFINDEX or NL80211_ATTR_WDEV. Only
wireless interfaces have a wdev id.
Save the actual cmd_id returned from l_genl_family_dump and zero it in
the get_scan_done. There's no need to zero it in scan_cancel because
get_scan_done gets called automatically.
Store the scan_context pointer in scan_results directly instead of
storing the ifindex. We now cancel ongoing GET_SCAN commands when the
scan_context is being freed so there's no point going through the extra
step of looking up the scan_context by ifindex inside the command
callback to guard against non-existent scan_contexts.
method.ops is NULL, which causes method.ops->exit to crash. This
adds a check that method.ops is not NULL before dereferencing.
Fixes:
Aborting (signal 11) [/home/jprestwo/iwd/src/iwd]
++++++++ backtrace ++++++++
0 0x7f016b59cf20 in /lib/x86_64-linux-gnu/libc.so.6
1 0x432057 in resolve_exit() at /home/jprestwo/iwd/src/resolve.c:295
2 0x403b61 in iwd_modules_exit() at /home/jprestwo/iwd/src/main.c:195
3 0x7f016b57fb97 in /lib/x86_64-linux-gnu/libc.so.6
+++++++++++++++++++++++++++
The original idea was to allow the provisioning file to include HESSID
without the NAIRealmNames. Configuring this way would allow for ANQP
to be skipped completely, assuming the AP advertises its HESSID.
The way the code was written still required NAIRealmNames to be
provided in the provisioning file.
The framework enables the service specific implementations
to provide its own variations for the DNS installation tasks.
The selection of the address resolution service can be done
through dns_resolve_method setting.
The module is responsible for the configuration of the address
resolution services. It will consist of the multiple service
specific plugins such as: systemd-resolved plugin, dnsmasq
plugin, etc.
If supported by the driver, we can create an interface directly with a
random MAC if configured to do so. If the driver does not have this
capability, then tell netdev to perform the necessary logic as part of
the interface initialization procedure.
#0 0x7f5e25e71930 in /lib64/libc.so.6
#1 0x446faa in hs20_config_free() at src/hotspot.c:63
#2 0x469542 in l_queue_clear() at ell/queue.c:109
#3 0x4694e7 in l_queue_destroy() at ell/queue.c:83
#4 0x4475c1 in hotspot_exit() at src/hotspot.c:273
#5 0x403170 in iwd_modules_exit() at src/main.c:195
#6 0x404085 in main() at src/main.c:531
#7 0x7f5e25e5cbde in /lib64/libc.so.6
Regulatory domain management is now completely handled by the kernel, so
iwd doesn't really need to query or be aware of changes to this. This
may change in the future, but for now this code has not been used and
can be safely gotten rid of.
After a scan, station can now pause future scans and start ANQP requests
to discover Hotspot's NAI realm. This lets us check if the AP's NAI realm
matches any stored hotspot configuration files. If so we can connect to
this network. If the network provides an HESSID and a matching one is
found in a hotspot provisioning file we can skip ANQP and directly connect
as this is expected to be our 'home network'
The actual ANQP request was handled by netdev, but in the case of P2P
their may be no netdev. For this reason all functionality needed for
an ANQP request has been moved into anqp.c. There are still a few netdev
references, which need to be removed when P2P is introduced. Leaving them
in for now as its still going to work as a first pass implementation
The initial ANQP parser design did not work well with how the hotspot
implementation was turning out. For one, much care was taken into parsing
the EAP credentials which are not really required. The assumption is
that any hotspot network will already be provisioned, so checking that
the EAP parameters match is a bit overkill. Instead only the NAI Realms
will be checked. This greatly simplifies the NAI realm parser, as now it
can just return a string list of realms instead of the full EAP
credential info.
This module will be in charge of managing Hotspot provisioning files
stored under the .hotspot/ directory. This includes a dir watch to
handle file changes/removal as well as an API to match a network
object to a hotspot provisioning file.
Hotspot networks are supposed to include an HESSID in the scan
results. This is more or less an identifier for the overall
network. In addition, the NAI Realms can be obtained via ANQP
and should be the same for each BSS. Since both HESSID and NAI
realms should be the same for a given network in range we can
store these values in the network object itself. This also allows
us to easily find hotspot configuration files by looking at
the HESSID/NAI Realms directly in the network object as opposed
to individual scan_bss's.
In order to do ANQP efficiently IWD needs the ability to suspend scanning
temporarily. This is because both scanning and ANQP go offchannel and must
remain off channel for some amount of time. This cannot be done
simultaneously and if e.g. ANQP is requested after a scan is already
pending, the kernel will wait till that scan finishes before sending out
the frame.
Use memset instead. explicit_bzero should only be used when we're
wiping a secret just prior to the encopassing storage being freed. The
compiler would usually optimize away the memset, leaving the secrets
around.
In rtnlutil we're simply zeroing the structure prior to filling it, so
the use of explicit_bzero is not needed and brings confusion to the
reader since no secrets are being wiped.
netconfig is interested in three station states: connected,
disconnected and connected after it has roamed. On connected
it tries to obtain a new DHCP lease, on disconnected it stops
the DHCP client and discards all addresses from interface, on
connected after roaming it will try to request a previously
issued address.
iwd keeps track of the addresses assigned to the managed
interfaces. The list of assigned IPv4/IPv6 addresses is stored
in ifaddr_list inside of netconfig. The tracking of the IP
addresses will help to remove them from an interface once they
are no longer valid.
netconfig module will be responsible for the orchestration
of the network configuration with the IP addresses.
iwd creates one netconfig structure per interface index.
The purpose of this struct is to hold all of the interface
related addressing states such as: assigned dhcp
clients, known addresses, routes, etc.
A not-yet-merged kernel patch will enable the FRAME_WAIT_CANCEL
event to be emitted when a CMD_FRAME duration expires. This can
shortcut the ridiculously long timeout that is required making
GAS requests with no response drastically quicker to handle.
This adds a new API netdev_anqp_request which will send out a GAS
request, parses the GAS portion of the response and forwards the
ANQP response to the callers callback.
This IE tells us what Advertisement Protocols the AP supports. This
is only here to look for ANQP support, so all this does is iterate
through all other Advertisement Protocol tuples looking for ANQP.
If found, anqp_capable is set in the scan_bss
Currently these are geared to support the WiFi Alliance Hotspot 2.0
ANQP elements, which all fall under the vendor specific ANQP element.
anqp_iter_next behaves similar to the genl parsers, where the id, length
and data will be returned as out parameters. Currently there is only
vendor support for Hotspot 2.0. anqp_iter_is_hs20 can be used to setup
the subtype, length, and data pointer to parse any Hotspot 2.0 ANQP
elements. From here the subtype can be checked and a vendor specific
parser for that subtype can be used to parse the data, e.g.
hs20_parse_osu_provider_nai.
The vendor specific IE was being parsed only to check if the AP supported
WPA, which used a Microsoft OUI. Hotspot/OSEN uses neither WPA or RSN
(although its nearly identical to RSN) so the we also need to check for
this Wifi-Alliance OUI and set bss->osen (new) if found.
The OSEN AKM uses the vendor specific IE, so when finding the RSNE
element we need to handle it specially to ensure that its both
a vendor specific element and it matches the WFA OUI since other
vendor specific elements may be included.
The OSEN AKM is nearly identical to the RSN IE, but differs slightly.
For one, OSEN is encapsulated into the vendor specific IE, and includes
the WFA OUI before the 'normal' RSN elements. OSEN also does not include
a WPA version, since its not technically WPA/WPA2.
Some of the RSN parsing was made common so both RSN/OSEN parsing could
use it.
The handshake object had 4 setters for authenticator/supplicant IE.
Since the IE ultimately gets put into the same buffer, there really
only needs to be a single setter for authenticator/supplicant. The
handshake object can deal with parsing to decide what kind of IE it
is (WPA or RSN).
The Hotspot 2.0 spec introduces 'Anonymous EAP-TLS' as a new EAP method
to be used with OSEN/Hotspot. The protocol details of this aren't
relevant to this patch, but one major difference is that it uses the
expanded EAP type rather than the TLS type. Since the common TLS code
was written with only EAP_TYPE_TLS in mind the vendor ID/type cause the
EAP packet to be malformed when using the expanded EAP type.
To handle this the common TLS code now checks the EAP type, and if its
expanded we shift the payload 7 bytes further to account for the extra
header data.
802.11 defines GAS (generic advertisement service) which can be used
to query supported advertisement protocols from an AP before
authentication/association. Hotspot/OSEN only care about the ANQP
protocol, but the way the IE is structured potentially requires
iterating through several tuples before you reach the ANQP protocol
identifier. Because of this we define all protocol identifiers.
