Please let us know if the network you are attempting to connect to is 802.11a/b/g/n or ac, is it 2.4 or 5.2 GHz?. Are you able to see the SSID and detect Wireless networks? Have you tested if the NUC is able to connect to other networks?
You might want to install driver 17.14.0, which can be downloaded in the following location:
Also, apply the settings recommended in the following document, as they may improve the connection in most environments:
Hello Jonathan -
The network is 802.11n only in 2.4 GHz and 802.11n/ac in 5 Ghz. Same SSID in both bands. I am able to see the SSID and attempt to connect to it both with Windows managing connectivity and with the Intel software managing connectivity. I see the authentication attempt in the RADIUS server logs but it does not complete properly.
I have verified the settings as suggested by the second link in your post.
As mentioned in my first post, the system will connect to WPA2-PSK networks just fine (and sees all other SSIDs in range as well), it appears the driver fails to complete the 802.1x authentication properly. Unfortunately, our enterprise network is 802.1x so PSK is not an option for us.
The driver package you have listed above leaves me with driver version 188.8.131.52 (12/8/2014) - the same version previously tested.
Thank you for the help.
Try using the Intel® PROSet/Wireless Software and drivers for IT administrators (current version 17.14.0). It would be advised to remove the version already installed from Windows Programs and Features.
During the setup process it will let you install additional features for enterprise environments.
Also, it will give you the option to create customized profiles, so you can manage the wireless connections to match the configuration in your environment.
If the issue persists, we would like to know if you are using Windows or PROset to manager the wireless connections.
If you have created a package with Intel® PROset/wireless software, please let us know the details about the package.
Hello Jonathan -
I have removed the existing toolset installation and installed from the link you provided also installing the Enterprise options.
Disappointingly, this has not solved the problem. Using PROSet to manage the wireless connections and asking it to connect to our enterprise network, it claims to only partially detect the network configuration. I verified the remaining settings match our network configuration in Network Policy Server on our Windows server. (PEAP and MS-CHAP-V2 being acceptable)
Configuring PROSet to use both manually entered credentials (with and without domain name) or Windows Login, NPS reports that the client has sent invalid credentials. In the Windows Event Log for NPS on the server, an entry is made for event 6273 as follows:
Network Policy Server denied access to a user.
Contact the Network Policy Server administrator for more information.
Security ID: DOMAIN\username
Account Name: DOMAIN\username
Account Domain: DOMAIN
Fully Qualified Account Name: DOMAIN\username
Security ID: NULL SID
Account Name: -
Fully Qualified Account Name: -
Called Station Identifier: wapmac
Calling Station Identifier: D8-FC-93-1B-BF-B1
NAS IPv4 Address: 10.10.1.14
NAS IPv6 Address: -
NAS Identifier: -
NAS Port-Type: Wireless - IEEE 802.11
NAS Port: 0
Client Friendly Name: Third Floor WAP371
Client IP Address: 10.10.1.14
Connection Request Policy Name: Wireless Network
Network Policy Name: Wireless Network
Authentication Provider: Windows
Authentication Server: windowsservername
Authentication Type: PEAP
EAP Type: -
Account Session Identifier: -
Logging Results: Accounting information was written to the local log file.
Reason Code: 16
Reason: Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.
Notably here the EAP Type field should be populated with "Microsoft: Secured password (EAP-MSCHAP v2)" as it is with all other devices which connect to this network using PEAP, however, in the case of the NUC with the 7260 card, this field is empty leading me to believe that the driver is not properly sending the authentication request.
It is also disappointing that the PROSet tools can not use the machine account to connect to the wireless - we are using this configuration with several computers with success and is my preference for these workstations.
Your help is appreciated.
It seems that there may be something missing in the configuration of the Wireless profile. Here are the detailed steps required to create a customized profile using Intel® PROSet/Wireless Software.
When you customize the installation of Intel® PROSet/Wireless Software to include the Enterprise features, it will give you the option to create, import and export Wireless connection profiles.
After the installation, you should have the "WiFi Connection Utility" application installed in the computer.
In the main screen of the WiFi Connection Utility, click "Profiles" to manage wireless profiles.
Then, you will have the option to "Add" a new profile, or change the properties of an existing one.
When you create a profile, first you will need to enter the profile name and SSID of the network in the General Settings.
After that, you can modify the Security Settings, starting with the PEAP user configuration, in your case you will need to use Enterprise Security, then set the Authentication, Encryption and Credentials according to the settings of your network. This is where you can set 802.1X configuration.
In this same screen, you can set "Cisco Options" as required to match the network settings.
In the next step, enter the PEAP server options according to your environment.
Once you enter the Security Settings, go to the Advanced Options, here you can configure Auto Application Launch, Auto Connect, Band Selection and other options for the Wireless Profile.
After the profile is created, you will be able to connect to it, Export it to a file so you can copy it to another system and Import the profile.
Thank you for your help.
I have worked through the steps provided in your previous post and while the driver now appears to properly negotiate EAP according to the NPS logs, the driver fails to DHCP an address or otherwise converse on the network.
The WAP logs show:
Mar 17 2015 09:43:32 debug hostapd station: d8:fc:93:1b:bf:b1 deauthenticated Mar 17 2015 09:43:32 info hostapd STA d8:fc:93:1b:bf:b1 deauthed from BSSID xx:xx reason 3: STA is leaving IBSS or ESS Mar 17 2015 09:43:32 info hostapd Assoc request from d8:fc:93:1b:bf:b1 BSSID xx:xx SSID network Mar 17 2015 09:43:31 info hostapd STA d8:fc:93:1b:bf:b1 deauthenticated for reason 16: Group key handshake timeout Mar 17 2015 09:43:31 info hostapd Station d8:fc:93:1b:bf:b1 had an authentication failure, reason 17 Mar 17 2015 09:43:05 info hostapd STA d8:fc:93:1b:bf:b1 associated with BSSID xx:xx Mar 17 2015 09:43:05 info hostapd Assoc request from d8:fc:93:1b:bf:b1 BSSID xx:xx SSID network
At this time, I have initiated an RMA with my vendor and will be returning the cards as the driver clearly does not support 802.1x properly and I've spent too much time trying to get it to work when all other wireless devices (Windows with Broadcom, iOS, OS X, Android devices, etc.) have no trouble with this network - with NO custom configuration.
I have to apologize as it appears that ultimately the problem might not have been with the Intel drivers.
After replacing the cards I saw the same behavior. I looked deeper into the situation and it appears that now with Windows 8.1 that Windows will not properly process EAP when the server presents a wildcard certificate, even if the FQDN of the server is listed as SAN on the certificate. This appears to be unique to Windows 8.1 in that we have Windows Vista/7/8, iOS, Android, and OS X clients that happily connect to this network with either certificate (of course the self signed certificate has to be accepted on non-domain devices).
No error message is presented anywhere (client or server) that would lead a person to this conclusion or even in this direction. The server throws error 6273 in the NPS logs (invalid credentials).
After changing the server certificate to a domain signed certificate in only the server's FQDN (with the Server Authentication purpose) the Windows 8.1 clients would connect properly. Non-domain devices on other OSes will have to manually accept the certificate.
Since I no longer have the Intel cards in my possession I cannot test with them, however, I'm posting this for others who might come across this issue without any kind of explanation - check your RADIUS certificate and make sure it is not a wildcard, even if the FQDN is in the SAN field.