There is no real reason to maintain these in the current development
branch anymore. If someone really needs support for the obsolete
driver interfaces, these can be found in older wpa_supplicant
branches.
driver_atmel.c
- vendor-specific interface for ATMEL AT76C5XXx cards
- for some old out-of-tree driver; not for the upstream atmel*
drivers
driver_ndiswrapper.c
- vendor-specific interface for an out-of-tree driver
- ndiswrapper should work with driver_wext.c, too
driver_ipw.c
- vendor-specific interface for old ipw2100/2200 driver
- the upstream driver works with driver_wext.c (and does not work
with the old interface)
driver_hermes.c
- vendor driver that was not even included in the main wpa_supplicant
releases
In order to enable protection mechanisms for different HT opmodes the
driver needs to be aware of the current HT opmode that is calculated by
hostapd. Hence, pass the current opmode to the nl80211 driver via
the bss attribute NL80211_ATTR_BSS_HT_OPMODE.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
tdls_prohibit=1 and tdls_prohibit_chan_switch=1 and now be used to
disable use of TDLS or TDLS channel switching in the BSS using
extended cabilities IE as defined in IEEE 802.11z.
Need to be able to handle TDLS Setup Response frame with LinkId IE
when non-zero status code is used. In addition, allow finding of a
TDLS entry based on real BSSID instead of the one used in the LinkId
to allow negative testing of different BSS.
The TDLS link itself is bidirectional, but there is explicit
initiator/responder roles. Remove the other direction of the link if it
exists when processing TDLS Setup Confirm to make sure that the link
counters are stored for the current TDLS entery.
This is also changing the control interface search for TDLS counters
to require initiator/responder addresses in the correct order instead
of matching entries regardless of the role.
Make sure that received management frames are long enough before
processing them. This avoids a potential segmentation fault if a
driver delivers an invalid frame all the way to hostapd.
The changes are:
1. the word "and" in the hunting-and-pecking string passed to the KDF
should be capitalized.
2. the primebitlen used in the KDF should be a short not an int.
3. the computation of MK in hostap is based on an older version of the
draft and is not the way it's specified in the RFC.
4. the group being passed into computation of the Commit was not in
network order.
This avoids an issue when a received EAPOL-Key frame from a peer
is initiating IBSS RSN Authenticator and Supplicant for the peer
and the following new-STA-in-IBSS event from the driver is adding
yet another instance of Authenticator/Supplicant. The EAPOL-Key
RX case was already checking whether an instance had been started;
the driver new-STA event needs to do same.
The driver may get confused if we set the initial TX GTK before having
fully configured and connected to an IBSS, so better delay this
operation until the connection (join/start IBSS) has been completed.
If the EAPOL processing times out (e.g., if the AP stops replying
to messages for some reason) during WPS negotiation, we need to
indicate WPS-FAIL event from eapol_cb since no other WPS failure is
reported for this particular case.
Previously, only the Configuration Error values were indicated in
WPS-FAIL events. Since those values are defined in the specification
it is not feasible to extend them for indicating other errors. Add
a new error indication value that is internal to wpa_supplicant and
hostapd to allow other errors to be indicated.
Use the new mechanism to indicate if negotiation fails because of
WEP or TKIP-only configurations being disallows by WPS 2.0.
This needs to be done both in the more normal location in
p2p_timeout_connect_listen() (internal timeout after driver event) and
in p2p_listen_end() as a workaround for the case where the driver event
is delayed to happen after the internal timeout.
The test with very large iterations count is commented out since it
takes quite long to derive (it does pass, though). In addition, the
last test vector is commented out since pbkdf2_sha1() does not support
arbitrary binary passphrases (\0 inside the string).
Previously, both NULL and ff:ff:ff:ff:ff:ff addr were used in various
places to indicate default/broadcast keys. Make this more consistent
and useful by defining NULL to mean default key (i.e., used both for
unicast and broadcast) and ff:ff:ff:ff:ff:ff to indicate broadcast
key (i.e., used only with broadcast).
When hostapd is removing a virtual BSS interface, the loop here was
incorrectly not updating the iterator during list traversal and
ended up in an infinite loop in some cases.
Use NULL instead of (u8 *) "" as the seq value and make sure the
driver wrapper implementations can handle NULL value. This was
previously already done in number of places, but not everywhere.
The BSS table entries may be in more or less random order and it is
better to show the most likely WPS configuration method in a way that is
somewhat more consistent instead of just showing the method of the first
BSS entry found in the table.
The proto configuration may be left to non-zero when moving from one
configuration to another. To avoid misidentifying a network
configuration as enabling WPA, check key_mgmt field, too.
wpa_supplicant seems to crash from time to time on a NetBSD 4.0 MIPS
platform. The root cause turned out to be a MIPS alignment issue.
In my wpa_supplicant crash case, in function
wpa_driver_bsd_event_receive (from driver_bsd.c), the buf[2048] address
is started from i.e. 0x7fffd546, which is not 4 bytes aligned. Later
when it is casted to (struct if_msghdr *), and rtm->rtm_flags is used.
rtm->rtm_flags is "int" type, but its address is not 4 bytes aligned.
This is because the start address of rtm is not 4 bytes aligned.
Unfortunately in NetBSD MIPS kernel (unlike Linux MIPS kernel emulates
unaligned access in its exception handler), the default behavior is to
generate a memory fault to the application that accesses unaligned
memory address. Thus comes the early mentioned wpa_supplicant crash. An
interesting note is when I'm using the wpa_supplicant version 0.4.9, I
never saw this problem. Maybe the stack layout is different. But I
didn't look into details.
I used below patch to resolve this problem. Now it runs correctly for at
least several hours. But you might have a better fix (maybe we can use
malloc/free so that it is at least cache line aligned?). I'm also not
sure if other drivers should have the same problem.
