driver.h contains the definitions needed in driver wrapper
implementations (driver_*.c) and driver_i.h contains the definitions
that are used in core hostapd code to interact with the driver wrappers.
The configuration parsing functions seemed to have worked fine before,
but these were real bugs even if they did not show up in practice.
hostapd_ip_diff() was broken for IPv6 addresses (overwrote address and
always returned 1.
This updated all doxygen runs to use the same style that was used for
wpa_supplicant full documents. The full vs. fast configurations are now
otherwise identical apart from fast not generating dot files or
latex/pdf version of the documentation.
Generate a SHA1 hash -based UUID from the local MAC address if the UUID
was not configured. This makes it easier to prepare for WPS since there
is no need to generate an UUID.
mac80211 can now figure out which key to use for injected frames (in
most cases), so we can remove the workaround for configuring IGTK on the
monitor interface that is used for injecting frames.
There is not really much else the Authenticator can do if it does not
receive valid EAP response from the Supplicant/EAP peer. EAP-Failure
would need to be sent before trying to start again with
EAP-Request/Identity, but that is not allowed before the EAP peer
actually replies. Anyway, forcing a new association is likely to clean
up peer state, too, so it can help fixing some issues that could have
caused the peer not to be able to reply in the first place.
It looks like this never survived the move from IEEE 802.1X-2001 to
IEEE 802.1X-2004 and EAP state machine (RFC 4137). The retransmission
scheduling and control is now in EAP authenticator and the
calculateTimeout() producedure is used to determine timeout for
retransmission (either dynamic backoff or value from EAP method hint).
The recommended calculations based on SRTT and RTTVAR (RFC 2988) are not
yet implemented since there is no round-trip time measurement available
yet.
This should make EAP authentication much more robust in environments
where initial packets are lost for any reason. If the EAP method does
not provide a hint on timeout, default schedule of 3, 6, 12, 20, 20, 20,
... seconds will be used.
Previously, only the delivery option 1 from RFC 4284
(EAP-Request/Identity from the AP) was supported. Now option 3
(subsequent EAP-Request/Identity from RADIUS server) can also be used
when hostapd is used as a RADIUS server. The eap_user file will need to
have a Phase 1 user entry pointing to Identity method in order for this
to happen (e.g., "* Identity" in the end of the file). The identity hint
is configured in the same was as for AP/Authenticator case (eap_message
in hostapd.conf).
This commit changes just the name and Action category per D7.0. The
retransmit/timeout processing in the AP is not yet updated with the
changes in D7.0.
dot11RSNAConfigGroupUpdateTimeOut and
dot11RSNAConfigPairwiseUpdateTimeOut MIB variables were only used in
draft versions of IEEE 802.11i, so rename these in order not to use
confusing name here.
Replaced EAPOL-Key timeout to use following timeouts (in
milliseconds): 100,1000,1000,1000 (this was 1000,1000,1000,0). There
is no point in sending out the final EAPOL-Key frame which would be
immediately followed by disconnection. After the change to allow
response to any pending EAPOL-Key frame, it is fine to send the first
retransmission quickly to avoid long wait in cases where Supplicant
did not receive the first frame for any reason. The new sequence will
still provide 3.1 seconds of time to get any response frame, so this
does not reduce the previous time.
Accept response to any pending request, not just the last one. This
gives the Supplicant more time to reply since hostapd will now allow up
to three seconds for the reply to the first EAPOL-Key frame transmission
(and two seconds for the first retry and one second for the last) while
the previous version invalidated any old request immediately when
sending a retransmitted frame.
If the Supplicant replies to more than one request, only the first reply
to arrive at the Authenticator will be processed. As far as the
Supplicant is concerned, this behavior does not differ from the previous
one except for being less likely to cause unneeded retransmissions of
EAPOL-Key frames.
This can help in cases where power saving is used when the group key is
rekeyed or when there is excessive traffic on the channel that can delay
(or drop) EAPOL-Key frames.
driver_test can now be used either over UNIX domain socket or UDP
socket. This makes it possible to run the test over network and makes it
easier to port driver_test to Windows.
hostapd configuration: test_socket=UDP:<listen port>
wpa_supplicant configuration: driver_param=test_udp=<dst IP addr>:<port>
Unfortunately, at least the current libnl git snapshot changes the API
in backwards incompatible way and in a way that makes it difficult to
to allow building against the latest libnl code.
This is currently happening way too frequently (mac80211 monitor
interface sends TX info for every frame) and the end result makes it
difficult to read hostapd debug log if there is large amount of data
traffic.
Only one of the authentication frame types is encrypted. In order for
static WEP encryption to work properly (i.e., to not encrypt the frame),
we need to tell mac80211 about the frames that must not be encrypted.
If the phy info from nl80211 does not include 802.11b mode, generate
that mode based on 802.11g information. This allows hw_mode=b to be used
with drivers that support 2.4 GHz band.
This is just making an as-is copy of EAP-AKA server and peer
implementation into a new file and by using the different EAP method
type that is allocated for EAP-AKA' (50). None of the other differences
between EAP-AKA and EAP-AKA' are not yet included.
It is likely that once EAP-AKA' implementation is done and is found to
work correctly, large part of the EAP-AKA and EAP-AKA' code will be
shared. However, it is not reasonable to destabilize EAP-AKA
implementation at this point before it is clearer what the final
differences will be.
Since the Registrar may not yet know the UUID-E when a new PIN is
entered, use of a wildcard PIN that works with any UUID-E can be useful.
Such a PIN will be bound to the first Enrollee trying to use it and it
will be invalidated after the first use.
If a STA reassociates and changes key_mgmt (e.g., from WPA-PSK to WPS),
hostapd needs to reset some of the existing STA and WPA state machine
variables to allow correct processing for the new association.
WPS IE is now passed from hostapd association processing into EAP-WSC
and WPS processing. Request Type attribute is parsed from this
information and if the request is for a WLAN Manager Registrar,
additional management keys are derived (to be used with UPnP).
This depends on a patch to Linux nl80211/mac80211 that has not yet been
merged into wireless-testing. If that change is not present, the old
mechanism (WEXT) will be used instead.
It is better to pass both HT Capabilities and HT Operation IEs in the
same function call since it may be easier for the driver wrappers to
handle the changes without having to wait for the other IE in the
wrapper code.
If country_code is set in hostapd.conf, hostapd will now update nl80211
regulatory data by setting the alpha2 string for CRDA. In other words,
"iw reg set <alpha2>" is not needed anymore when using hostapd.
This adds WPS support for both hostapd and wpa_supplicant. Both programs
can be configured to act as WPS Enrollee and Registrar. Both PBC and PIN
methods are supported.
Currently, hostapd has more complete configuration option for WPS
parameters and wpa_supplicant configuration style will likely change in
the future. External Registrars are not yet supported in hostapd or
wpa_supplicant. While wpa_supplicant has initial support for acting as
an Registrar to configure an AP, this is still using number of hardcoded
parameters which will need to be made configurable for proper operation.
Changed accounting_sta_start() to call accounting_sta_get_id()
internally in accounting.c so that external callers do not need to do
anything to allocate unique accounting id. When starting a new session,
a unique identifier is needed anyway, so no need to keep these
operations separate.
This was used to allow hostapd to associate as a non-AP STA to another
AP one the same channel while still acting as an AP with the Host AP
driver. This was very experimental and did not work with all firmware
versions. Nowadays, much better way of doing this is to use mac80211
virtual non-AP STA interface. As such, this experimental code can be
removed from hostapd to reduce the code size and make MLME code easier
to understand since it is now only handling AP functionality.
This code was originally added as a mechanism to handle long waits
during channel selection and/or radar detection. It is not currently
really used and makes the setup sequence nearly impossible to
understand. Let's get rid of the unwanted complexity. This needs to be
redesigned if it is ever needed again.
This code was not finished and did not work with the current mac80211
design. In order to avoid confusing users, it is better to remove this
completely for now and look at new implementation to work with mac80211.
It the message was large enough to require fragmentation (e.g., if a large
Session Ticket data is included), More Fragment flag was set, but no
more fragments were actually sent (i.e., Access-Accept was sent out).
These typedefs were causing build issues with new kernel/C library headers,
so lets get rid of them since they do not seem to be needed anymore. This
applies only if CONFIG_FULL_DYNAMIC_VLAN is enabled which is not even
mentioned in the defconfig file, so this should not change behavior more
most users.
If the driver wrapper does not implement passive_scan handler, do not try
to use strerror() to figure out what the error meant. This is not really an
error that the user should be notified about.
(e.g., via driver_nl80211 when using mac80211) instead of using hostapd as
the source of the regulatory information (i.e., information from CRDA is
now used with mac80211); this allows 5 GHz channels to be used with hostapd
(if allowed in the current regulatory domain).
