Remove all fields before sun_path before printing or comparing sun_path
contents. Using offsetof should be portable. In addition, set sun_len
for FreeBSD.
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.
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.
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
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.
This patch replaces the station's ht capability information with the
negotiated one in NL80211_CMD_NEW_STATION. This negotiated ht
capability will be needed for rate control initialization in the
driver.
Signed-off-by: vasanth <vasanth@atheros.com>
The EAP server state machine will need to have special code in
getDecision() to avoid starting passthrough operations before having
completed Identity round in the beginning of reauthentication. This was
broken when moving into using the full authenticator state machine from
RFC 4137 in 0.6.x.
The old behavior of generating new DH keys can be maintained for non-OOB
cases and only OOB (in this case, with UFD) will use the pre-configured
DH keys to allow the public key hash to be checked.
Not all embedded devices have USB interface and it is useful to be able
to remove unneeded functionality from the binary. In addition, the
current implementation has some UNIX specific calls in it which may make
it not compile cleanly on all target systems.
Need to set WLAN_STA_WPS and WLAN_STA_MAYBE_WPS flags even if WPA is not
enabled. This allows open and static WEP modes to initiate WPS
negotiation with madwifi-like drivers.
This uses similar, but not identical, interface to madwifi. It is easier
to keep this separate to avoid conflicts with potential changes in the
driver interfaces.
TX/RX bytes are now reported correctly (typo ended up leaving TX bytes
uninitialized and set RX bytes value to use correct TX bytes). TX/RX
packet counts are not yet available from kernel, so we have to clear the
values to avoid reporting bogus data.
On WPS init/deinit process, the hostapd clears it's own WPS IE
with 0 length WPS IE. But it fails. Because the parameter to
ioctl is too short. Then hostapd prints a below message.
ioctl[IEEE80211_IOCTL_SET_APPIEBUF]: Invalid argument
Allow more than one pending PutWLANMessage data to be stored (M2/M2D
from multiple external Registrars) and drop pending M2/M2D messages when
the Enrollee replies with M3.
It looks like Intel wsccmd may send a bogus NewWLANEventMAC
(11:22:33:44:55:66) when acting as an wired external Registrar. Work
around this by going through all STAs if the address does not match and
pick the STA that is in an ongoing WPS registration.
If you don't choose OpenSSL as TLS implementation and choose to enable
CONFIG_EAP_TNC you have to link against libdl. The OpenSSL libraries
implicitly link against them, so this might be a reason why it wasn't
noticed yet. I assume the same applies to hostapd.
We can now handle up to 65535 byte result buffer which is the maximum
due to WEXT using 16-bit length field. Previously, this was limited to
32768 bytes in practice even through we tried with 65536 and 131072
buffers which we just truncated into 0 in the 16-bit variable.
This more or less doubles the number of BSSes we can received from scan
results.
MadWifi is unlikely to be in ../head relative to hostapd or
wpa_supplicant, as it would be inside the hostap git repository.
MadWifi sources are more likely to be in a directory called "madwifi"
and residing outside the hostap repository. Using "madwifi" also
demonstrates that the top-level madwifi directory is needed.
Try to match PRI/SEC channel with neighboring 20/40 MHz BSSes per
IEEE 802.11n/D7.0 11.14.3.2. This is not yet complete implementation,
but at least some parts of the 40 MHz coex are improved.
40 MHz operation maybe rejected (i.e., fall back to using 20 MHz) or
pri/sec channels may be switched if needed.
