This cleans up the driver wrapper interface by getting rid of sta_info.h
dependency in all drivers that use MLME implementation in hostapd
(driver_hostap.c and driver_nl80211.c).
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.
