I've been doing a lot of reading on issues with the 7260 adapter. It seems that it is a very flawed product. We have observed frequent, random disconnects to WiFi networks.
System Model: HP EliteDesk 800 G1 USDT (or HP ZBook 15 G2)
BIOS Version/Date: Hewlett-Packard L01 v02.65, 13-7-2015
OS Name: Microsoft Windows 7 Enterprise
Version: 6.1.7601 Service Pack 1 Build 7601
Hardware Abstraction Layer Version: "6.1.7601.17514"
Product Type: Intel(R) Dual Band Wireless-N 7260
Driver: c:\windows\system32\drivers\netwsw02.sys (220.127.116.11, 3,83 MB (4.011.760 bytes)
We have observed the following over time:
- The client seems to go into a state where it is no longer able to recieve frames.
- This is mainly observed when doing re-authentication via 802.1x. As soon as the 802.1x authentication is either started or restarted when the client is in the "non-recieve" state 802.1x authentication will fail.
- EAP-TLS is used.
We observe the following:
(1) Event 12014: 802.1x authention is starting.
(2) The First EAPoL frame is send by the client
(3) After a 5s timeout expires the second EAPoL packet is send by the client
(4) After a 5s timeout expires the third EAPoL packet is send by the client
(5) After a 5s timeout, the client assumes the authenticator (the AP and the WLC ) are no longer responding. The client is logging how much time it took for this 802.1x authentication session (15054ms)
(6) The client is logging that 802.1x Authentication fails. It is failing because there is no “request identity” being returned to the client.
(7) This is the event logged in the event viewer (12013)
Initially we thought the issue was with the WiFi network not returning the "EAP Request, Identity" frame, as this is expected by the client. However, we've used exentsive capturing and we found that the frame is indeed send from the WLC to the AP (copper tap) and we identified the "EAP Request, Identity" frame in the air via AirSniffer.
It is therefore known beyond any reasonable doubt that the WiFi network is not making a mistake during authentication. We observe the same behaviour with ARP. The client is making an ARP request for the gateway, the gateway responds, but the client is not able to "recieve" the frame and looses its default gateway, pretty much rendering the connection useless. The workaround solution we have right now is to "enable/disbale" the WiFi adapter, or in the case of the HP Z-Books end-users press the "WiFi" button on the machine to enable connectivity again.
Could this be related to the earlier issue: "Sporadic Wireless Disconnects Caused by Data Reordering Issue" as they seem to be very related. We have detailed captures of the issue, incl. ETL traces.
What can we do to get this WiFi adapter to work properly?