This can be used, e.g., with mac80211-based Linux drivers with
nl80211. This allows over-the-air FT protocol to be used (IEEE
802.11r).
Since the nl80211 interface needed for this is very recent (added
today into wireless-testing.git), driver_nl80211.c has backwards
compatibility code that uses WEXT for association if the kernel does
not support the new commands. This compatibility code can be
disabled by defining NO_WEXT_COMPAT. That code will also be removed
at some point to clean up driver_nl80211.c.
On "eap_tnc_process" function error case, data->in_buf keeps reference
to a local scope variable. For example this will cause segmentation
fault in "eap_tnc_deinit" function "wpabuf_free(data->in_buf)"
statement.
This was broken by 510c02d4a3 which added
validation of eap_ttls_phase2_eap_init() return value. The main problem
in the code trying to initialize a new phase 2 EAP method
unconditionally; this should only happen if there is a new method in the
inner method sequence.
This is based on a patch and report by Masashi Honma
<honma@ictec.co.jp>. The issue is more generic than just TNC, though,
since failure to initialize any phase 2 EAP method can result in NULL
dereference.
On PEAP(TNC), hostapd integrated RADIUS server doesn't return
EAP-Failure when "Recommendation = none". So, EAP data retransmittion
occurs.
My co-worker "Ryuji Ohba" made below patch.
If every secondary BSS is configured with a pre-set BSSID, hostapd does
not enforce the BSSID mask requirements anymore, i.e., they are used
only if hostapd is responsible for generating MAC addresses for virtual
interfaces.
This is needed to make mac80211 work with multi-BSS configuration. The
previous design ended up setting DTIM period for secondary BSSes before
setting the Beacon and driver_nl80211.c was not really prepared for
that. Eventually, the Beacon configuration routines should be combined
into a single driver operation, but for now, just moving this call is
the simplest workaround.
hostapd will now go through the RIC Request and process each RDIE. Only
WMM TSPEC requests are currently supported; all other request
descriptors will be declined.
RIC Response is written by hostapd and verified by wpa_supplicant (MIC
validation). wpa_supplicant does not yet have code to notify the driver
about the resource request results.
This adds first part of FT resource request as part of Reassocition
Request frame (i.e., FT Protocol, not FT Resource Request Protocol).
wpa_supplicant can generate a test resource request when driver_test.c
is used with internal MLME code and hostapd can verify the FTIE MIC
properly with the included RIC Request.
The actual RIC Request IEs are not processed yet and hostapd does not
yet reply with RIC Response (nor would wpa_supplicant be able to
validate the FTIE MIC for a frame with RIC Response).
Windows XP and Vista clients can get confused about EAP-Identity/Request
when they probe the network with EAPOL-Start. In such a case, they may
assume the network is using IEEE 802.1X and prompt user for a
certificate while the correct (non-WPS) behavior would be to ask for the
static WEP key. As a workaround, use Microsoft Provisioning IE to
advertise that legacy 802.1X is not supported.
This seems to make Windows ask for a static WEP key when adding a new
network, but at least Windows XP SP3 was still marking IEEE 802.1X
enabled for the network. Anyway, this is better than just leaving the
network configured with IEEE 802.1X and automatic WEP key distribution.
When using the internal TLS implementation, EAP-FAST unauthenticated
provisioning ends up proposing multiple cipher suites. It looks like
Cisco AP (at least 350 and 1200 series) local authentication server does
not know how to search cipher suites from the list and seem to require
that the last entry in the list is the one that it wants to use.
However, TLS specification requires the list to be in the client
preference order. As a workaround, ass anon-DH AES-128-SHA1 again at the
end of the list to allow the Cisco code to find it.
This fixed EAP-FAST provisioning with the following IOS version:
Cisco IOS Software, C350 Software (C350-K9W7-M), Version 12.3(8)JEA3,
RELEASE SOFTWARE (fc2)
Compiled Wed 21-Nov-07 14:08 by ccai
This is just there very first step on being able to do something with
wireless LAN on Vista. There is some example code for requesting a scan,
but it does not work in its current form. Anyway, this adds a wpa_printf
noting that Native 802.11 drivers are not yet supported.
This is done with wired interfaces to fix IEEE 802.1X authentication
when the authenticator uses the group address (which should be happening
with wired Ethernet authentication).
This allows wpa_supplicant to complete wired authentication successfully
on Vista with a NDIS 6 driver, but the change is likely needed for
Windows XP, too.
Do not use just the driver name for this since driver_ndis.c supports
both wired and wireless NDIS drivers and needs to indicate the driver
type after initialization.
Calculate the estimated medium time using integer variables since there
is no real need to use floating point arithmetics here. In addition,
make sure there is no division by zero regardless of how invalid the
request from the station is. Reject invalid parameters and refuse
requests that would take most of the bandwidth by themselves.
Add test code into wpa_supplicant mlme.c to allow WMM-AC negotiation to
be tested with driver_test.
The new file wps_nfc.c and ndef.c implements NFC device independent
operation, wps_nfc_pn531.c implements NFC device dependent operation.
This patch is only for the following use case:
- Enrollee = wpa_supplicant
- Registrar = hostapd internal Registrar
Following NFC methods can be used:
- Enrollee PIN with NFC
- Registrar PIN with NFC
- unencrypted credential with NFC
Encrypted credentials are not supported.
Enrollee side operation:
Registrar side operation:
Example configuration.
CONFIG_WPS=y
CONFIG_WPS_NFC=y
CONFIG_WPS_NFC_PN531=y
I used NFC device "NXP PN531". The NFC device access method is
confidential, so I used outer library. Please download below files from
https://www.saice-wpsnfc.bz/index.php
[WPS NFC Library]
WpsNfcLibrary/WpsNfc.h
WpsNfcLibrary/WpsNfcType.h
WpsNfcLibrary/WpsNfcVersion.h
WpsNfcLibrary/linux/libnfc_mapping_pn53x.dll
WpsNfcLibrary/linux/wpsnfc.dll
[NFC Reader/Writer Kernel Driver]
NFCKernelDriver-1.0.3/linux/kobj/sonyrw.ko
<WiFi test>
The hostapd/wpa_supplicant with this patch passed below tests on
"Wi-Fi WPS Test Plan Version 1.6".
4.2.5 Add device using NFC Method with password token
(I used SONY STA instead of NXP STA.)
4.2.6 Add device using NFC Method with configuration token
5.1.9 Add to AP using NFC Method with password token
through internal registrar
(I used SONY AP instead of NXP AP.)
5.1.10 Add to AP using NFC Method with configuration token
through internal registrar
Many deployed APs do not handle negotiation of security parameters well
when both TKIP and CCMP (or both WPA and WPA2) are enabled. The most
common end result seems to be ending up with the least secure option..
As a workaround, check whether the AP advertises WPA2/CCMP in Beacon
frames and add those options for the credential if needed. This allows
the client to select the most secure configuration regardless of how
broken the AP's WPS implementation is as far as auth/encr type
negotiation is concerned.
This updates the terminogy to match with the final WMM specification. In
addition, some of the WMM TSPEC structure fields were in incorrect order
and used without byte order swapping. Those are also taken care of this
cleanup patch.
