Main Nav

Hi,

 

I’m forwarding this from a colleague in the UK which looks rather serious.

I’ve not yet read it through but found it so urgent that I’ll forward it right away.

 

Cheers

Anders Nilsson

Umeå university

SUNET Sweden



From: "Paul Hill (phill)" <phill@CISCO.COM>

Subject: Advance notice: Microsoft Windows 8 and Cisco centralised wireless incompatibility.

Date: August 29, 2012 21:22:20 GMT+02:00

Reply-To: Wireless Issues in the JANET community <WIRELESS-ADMIN@JISCMAIL.AC.UK>

 

Hi all,

I wanted to pre-advise colleagues in advance of a formal Field Notice coming
out shortly that a serious software bug exists in all Cisco centralised
wireless controller versions which support pre-standard Management Frame
Protection (MFP) that will render Windows 8 devices completely unable to
connect to Cisco APs under centralised control, with no easy workaround.

This will affect every institution on the list using Cisco centralised
wireless so I hope the non-Cisco colleagues won't mind this broadcast as
it's quite important to avoid clients starting to pop up that can't connect
for no apparent reason. Cisco has asked every employee, every partner and
every other contractor we have a relationship with to proactively reach
out to our/their customers to advise of this problem - so you might hear
this twice or more from various contacts / lists / sources over the coming
weeks.

Problem: Microsoft Windows 8, to be released on October 26th, is among the
first clients to support IEEE 802.11w natively in the OS. Clients running
802.11w fail to connect to Cisco's MFP capable APs because of interoperability
issues in the service capability negotiation. It is /not/ possible to address
this by simply disabling MFP on the Cisco Infrastructure, and Microsoft confirm
that Windows 8 does not provide any way (e.g., RegKey, Group Policy) to turn
off 802.11w as it is considered a positive feature to always have turned on
for security purposes. The Cisco bug ID tracking this is CSCua29504.

Solution: The only two solutions are:
1. Update the Controller code to a fixed version.
2. Downgrade to a pre-Windows 8 wireless NIC driver on the client device -
where that option is available - as 802.11w is NIC driver and/or supplicant
dependant. The only allowance Windows 8 makes is to not enforce 802.11w
on pre-Windows 8 driver sets which will not work with most vendors' NICs
otherwise. Clearly, the support implications of advising end users to do
this will not scale, will not work indefinitely, and Cisco is not relying
on this option as any kind of sustainable or permanent workaround.

The plan is to patch the bug so that Windows 8 and other 802.11w capable
clients can connect to Cisco infrastructure on the 7.0 code train (Early
September), 7.2 code train (Late September) and 7.3 first release code train
(Available by the end of August).

This fix does not implement 802.11w but instead ensures that the communication
from 802.11w enabled clients is interpreted correctly by the Access Point.
There are no plans to patch this on the 5.0, 5.1, 5.2, 6.0 and 7.1 code-trains
which have passed their End of Software Maintenance (EoSM) or End of Life
(EoL) dates, and so 7.0 is the minimum release to move to if still running
<=7.0 and needing the fix; and 7.2 if running 7.1.  This issue does not affect
version 4.2 and previous.

Finally, the IEEE standard version of MFP - 802.11w (called Protected
Management Frames - PMF) - will be supported in 7.4 (early Q1 2013).

For now, I would advise scheduling a software upgrade window on your Cisco
controllers ready for when the fixed code versions are released (if not wishing,
or not able due to controller model, to adopt 7.3 soon).  This will avoid
a flurry of user support cases coming in the day they start arriving on campus
with Windows 8 devices on or soon after launch. The route to obtain the fixed
software versions is via your normal support channel.

It goes without saying that this is a deeply unfortunate situation to have
arisen, but I hope you won't shoot the messenger! :-) As bugs go this is
right up there as quite a stunner. I expect to be quite busy over the next
few months across Public Sector as this ripples out to customers who have
not been reachable in advance for whatever reason.

Please feel free to share this as widely as possible with any colleagues
or other institutions you believe would be interested that are not on this
list.

Regards,
Paul
--
Paul A. Hill  CCDP, CCNP Wireless, CWNP Inc. CWDP & CWSP
Head of Wireless Technologies, Public Sector UK

Cisco Systems Ltd.       E-mail:     phill@cisco.com
10 New Square            Direct Tel: +44 (0)20 8824 8534
Bedfont Lakes            Direct Fax: +44 (0)20 7900 2337
Feltham                  Mobile *:   As Direct Telephone
Middlesex                Main Tel:   +44 (0)20 8824 1000
TW14 8HA                 Main Fax:   +44 (0)20 8824 1001
United Kingdom           Voicemail:  844 48534
* Single Number Reach rings all of my contact devices simultaneously.

Cisco Systems Limited (Company Number: 02558939), is registered in England and Wales with its registered office at 1 Callaghan Square, Cardiff, South Glamorgan CF10 5BT.

This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorised to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.

 

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Comments

Interesting, but we run 7.2 code, and so far only see driver issues on Win 8 machines. If newer driver available, usually gets the Win 8 machine right on our wireless networks. Wonder what we're missing...

Sent from an Etch-a-Sketch. Please excuse squiggly lines.

On Aug 30, 2012, at 1:25, "Anders Nilsson" <anders.nilsson@ADM.UMU.SE> wrote:

Hi,

 

I’m forwarding this from a colleague in the UK which looks rather serious.

I’ve not yet read it through but found it so urgent that I’ll forward it right away.

 

Cheers

Anders Nilsson

Umeå university

SUNET Sweden



From: "Paul Hill (phill)" <phill@CISCO.COM>

Subject: Advance notice: Microsoft Windows 8 and Cisco centralised wireless incompatibility.

Date: August 29, 2012 21:22:20 GMT+02:00

Reply-To: Wireless Issues in the JANET community <WIRELESS-ADMIN@JISCMAIL.AC.UK>

 

Hi all,

I wanted to pre-advise colleagues in advance of a formal Field Notice coming
out shortly that a serious software bug exists in all Cisco centralised
wireless controller versions which support pre-standard Management Frame
Protection (MFP) that will render Windows 8 devices completely unable to
connect to Cisco APs under centralised control, with no easy workaround.

This will affect every institution on the list using Cisco centralised
wireless so I hope the non-Cisco colleagues won't mind this broadcast as
it's quite important to avoid clients starting to pop up that can't connect
for no apparent reason. Cisco has asked every employee, every partner and
every other contractor we have a relationship with to proactively reach
out to our/their customers to advise of this problem - so you might hear
this twice or more from various contacts / lists / sources over the coming
weeks.

Problem: Microsoft Windows 8, to be released on October 26th, is among the
first clients to support IEEE 802.11w natively in the OS. Clients running
802.11w fail to connect to Cisco's MFP capable APs because of interoperability
issues in the service capability negotiation. It is /not/ possible to address
this by simply disabling MFP on the Cisco Infrastructure, and Microsoft confirm
that Windows 8 does not provide any way (e.g., RegKey, Group Policy) to turn
off 802.11w as it is considered a positive feature to always have turned on
for security purposes. The Cisco bug ID tracking this is CSCua29504.

Solution: The only two solutions are:
1. Update the Controller code to a fixed version.
2. Downgrade to a pre-Windows 8 wireless NIC driver on the client device -
where that option is available - as 802.11w is NIC driver and/or supplicant
dependant. The only allowance Windows 8 makes is to not enforce 802.11w
on pre-Windows 8 driver sets which will not work with most vendors' NICs
otherwise. Clearly, the support implications of advising end users to do
this will not scale, will not work indefinitely, and Cisco is not relying
on this option as any kind of sustainable or permanent workaround.

The plan is to patch the bug so that Windows 8 and other 802.11w capable
clients can connect to Cisco infrastructure on the 7.0 code train (Early
September), 7.2 code train (Late September) and 7.3 first release code train
(Available by the end of August).

This fix does not implement 802.11w but instead ensures that the communication
from 802.11w enabled clients is interpreted correctly by the Access Point.
There are no plans to patch this on the 5.0, 5.1, 5.2, 6.0 and 7.1 code-trains
which have passed their End of Software Maintenance (EoSM) or End of Life
(EoL) dates, and so 7.0 is the minimum release to move to if still running
<=7.0 and needing the fix; and 7.2 if running 7.1.  This issue does not affect
version 4.2 and previous.

Finally, the IEEE standard version of MFP - 802.11w (called Protected
Management Frames - PMF) - will be supported in 7.4 (early Q1 2013).

For now, I would advise scheduling a software upgrade window on your Cisco
controllers ready for when the fixed code versions are released (if not wishing,
or not able due to controller model, to adopt 7.3 soon).  This will avoid
a flurry of user support cases coming in the day they start arriving on campus
with Windows 8 devices on or soon after launch. The route to obtain the fixed
software versions is via your normal support channel.

It goes without saying that this is a deeply unfortunate situation to have
arisen, but I hope you won't shoot the messenger! :-) As bugs go this is
right up there as quite a stunner. I expect to be quite busy over the next
few months across Public Sector as this ripples out to customers who have
not been reachable in advance for whatever reason.

Please feel free to share this as widely as possible with any colleagues
or other institutions you believe would be interested that are not on this
list.

Regards,
Paul
--
Paul A. Hill  CCDP, CCNP Wireless, CWNP Inc. CWDP & CWSP
Head of Wireless Technologies, Public Sector UK

Cisco Systems Ltd.       E-mail:     phill@cisco.com
10 New Square            Direct Tel: +44 (0)20 8824 8534
Bedfont Lakes            Direct Fax: +44 (0)20 7900 2337
Feltham                  Mobile *:   As Direct Telephone
Middlesex                Main Tel:   +44 (0)20 8824 1000
TW14 8HA                 Main Fax:   +44 (0)20 8824 1001
United Kingdom           Voicemail:  844 48534
* Single Number Reach rings all of my contact devices simultaneously.

Cisco Systems Limited (Company Number: 02558939), is registered in England and Wales with its registered office at 1 Callaghan Square, Cardiff, South Glamorgan CF10 5BT.

This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorised to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.

 

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Hi Lee (and you other out there)

 

Well actually after talking with my colleagues I found that those who had tested eduroam on Win8 didn’t experience any problems at all and we are running version 7.0.230 on older WiSM’s.

I suspect that the problem as you say might be the drivers on certain WiFi chip sets. At least the driver for Intel 5300 chipset. ;)

 

 

Cheers

Anders

 

 

Från: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] För Lee H Badman
Skickat: den 30 augusti 2012 12:22
Till: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Ämne: Re: [WIRELESS-LAN] FWD: [WLAN] Fwd: Advance notice: Microsoft Windows 8 and Cisco centralised wireless incompatibility.

 

Interesting, but we run 7.2 code, and so far only see driver issues on Win 8 machines. If newer driver available, usually gets the Win 8 machine right on our wireless networks. Wonder what we're missing...

Sent from an Etch-a-Sketch. Please excuse squiggly lines.


On Aug 30, 2012, at 1:25, "Anders Nilsson" <anders.nilsson@ADM.UMU.SE> wrote:

Hi,

 

I’m forwarding this from a colleague in the UK which looks rather serious.

I’ve not yet read it through but found it so urgent that I’ll forward it right away.

 

Cheers

Anders Nilsson

Umeå university

SUNET Sweden




From: "Paul Hill (phill)" <phill@CISCO.COM>

Subject: Advance notice: Microsoft Windows 8 and Cisco centralised wireless incompatibility.

Date: August 29, 2012 21:22:20 GMT+02:00

Reply-To: Wireless Issues in the JANET community <WIRELESS-ADMIN@JISCMAIL.AC.UK>

 

Hi all,

I wanted to pre-advise colleagues in advance of a formal Field Notice coming
out shortly that a serious software bug exists in all Cisco centralised
wireless controller versions which support pre-standard Management Frame
Protection (MFP) that will render Windows 8 devices completely unable to
connect to Cisco APs under centralised control, with no easy workaround.

This will affect every institution on the list using Cisco centralised
wireless so I hope the non-Cisco colleagues won't mind this broadcast as
it's quite important to avoid clients starting to pop up that can't connect
for no apparent reason. Cisco has asked every employee, every partner and
every other contractor we have a relationship with to proactively reach
out to our/their customers to advise of this problem - so you might hear
this twice or more from various contacts / lists / sources over the coming
weeks.

Problem: Microsoft Windows 8, to be released on October 26th, is among the
first clients to support IEEE 802.11w natively in the OS. Clients running
802.11w fail to connect to Cisco's MFP capable APs because of interoperability
issues in the service capability negotiation. It is /not/ possible to address
this by simply disabling MFP on the Cisco Infrastructure, and Microsoft confirm
that Windows 8 does not provide any way (e.g., RegKey, Group Policy) to turn
off 802.11w as it is considered a positive feature to always have turned on
for security purposes. The Cisco bug ID tracking this is CSCua29504.

Solution: The only two solutions are:
1. Update the Controller code to a fixed version.
2. Downgrade to a pre-Windows 8 wireless NIC driver on the client device -
where that option is available - as 802.11w is NIC driver and/or supplicant
dependant. The only allowance Windows 8 makes is to not enforce 802.11w
on pre-Windows 8 driver sets which will not work with most vendors' NICs
otherwise. Clearly, the support implications of advising end users to do
this will not scale, will not work indefinitely, and Cisco is not relying
on this option as any kind of sustainable or permanent workaround.

The plan is to patch the bug so that Windows 8 and other 802.11w capable
clients can connect to Cisco infrastructure on the 7.0 code train (Early
September), 7.2 code train (Late September) and 7.3 first release code train
(Available by the end of August).

This fix does not implement 802.11w but instead ensures that the communication
from 802.11w enabled clients is interpreted correctly by the Access Point.
There are no plans to patch this on the 5.0, 5.1, 5.2, 6.0 and 7.1 code-trains
which have passed their End of Software Maintenance (EoSM) or End of Life
(EoL) dates, and so 7.0 is the minimum release to move to if still running
<=7.0 and needing the fix; and 7.2 if running 7.1.  This issue does not affect
version 4.2 and previous.

Finally, the IEEE standard version of MFP - 802.11w (called Protected
Management Frames - PMF) - will be supported in 7.4 (early Q1 2013).

For now, I would advise scheduling a software upgrade window on your Cisco
controllers ready for when the fixed code versions are released (if not wishing,
or not able due to controller model, to adopt 7.3 soon).  This will avoid
a flurry of user support cases coming in the day they start arriving on campus
with Windows 8 devices on or soon after launch. The route to obtain the fixed
software versions is via your normal support channel.

It goes without saying that this is a deeply unfortunate situation to have
arisen, but I hope you won't shoot the messenger! :-) As bugs go this is
right up there as quite a stunner. I expect to be quite busy over the next
few months across Public Sector as this ripples out to customers who have
not been reachable in advance for whatever reason.

Please feel free to share this as widely as possible with any colleagues
or other institutions you believe would be interested that are not on this
list.

Regards,
Paul
--
Paul A. Hill  CCDP, CCNP Wireless, CWNP Inc. CWDP & CWSP
Head of Wireless Technologies, Public Sector UK

Cisco Systems Ltd.       E-mail:     phill@cisco.com
10 New Square            Direct Tel: +44 (0)20 8824 8534
Bedfont Lakes            Direct Fax: +44 (0)20 7900 2337
Feltham                  Mobile *:   As Direct Telephone
Middlesex                Main Tel:   +44 (0)20 8824 1000
TW14 8HA                 Main Fax:   +44 (0)20 8824 1001
United Kingdom           Voicemail:  844 48534
* Single Number Reach rings all of my contact devices simultaneously.

Cisco Systems Limited (Company Number: 02558939), is registered in England and Wales with its registered office at 1 Callaghan Square, Cardiff, South Glamorgan CF10 5BT.

This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorised to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.

 

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Are you by any chance running into the problem with Intel 5300/5100 chipsets connecting to 11n 3x3 APs? Juniper let us in on an Intel driver bug where the chipset claims to have 3x3 capability even on 2x2 hardware. If you're connecting to a 2x2 AP you'll never notice, but on a 3x3 the AP actually sends traffic at 3 stream speeds. End result is that the station is able to send fine, and receive broadcasts if another station has lowered the broadcast/multicast rate on that AP, but it never receives any unicast traffic. The usual tell-tale is the station receives an IP via DHCP an upstream routers have correct ARP entries, but the client can't do anything after that. The real kicker is that the bug is present in the (now ancient) 12.x Intel drivers that are *still* being shipped in Microsoft Update. You have to troll through support.intel.com and get a recent 14.x or 15.x series driver to fix the problem. Frank Sweetser fs at wpi.edu | For every problem, there is a solution that Manager of Network Operations | is simple, elegant, and wrong. Worcester Polytechnic Institute | - HL Mencken On 08/30/2012 08:06 AM, Anders Nilsson wrote: > Hi Lee (and you other out there) > > > > Well actually after talking with my colleagues I found that those who had > tested eduroam on Win8 didn’t experience any problems at all and we are > running version 7.0.230 on older WiSM’s. > > I suspect that the problem as you say might be the drivers on certain WiFi > chip sets. At least the driver for Intel 5300 chipset. ;) > > > > > > Cheers > > Anders > > > > > > *Från:*The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *För *Lee H Badman > *Skickat:* den 30 augusti 2012 12:22 > *Till:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > *Ämne:* Re: [WIRELESS-LAN] FWD: [WLAN] Fwd: Advance notice: Microsoft Windows > 8 and Cisco centralised wireless incompatibility. > > > > Interesting, but we run 7.2 code, and so far only see driver issues on Win 8 > machines. If newer driver available, usually gets the Win 8 machine right on > our wireless networks. Wonder what we're missing... > > Sent from an Etch-a-Sketch. Please excuse squiggly lines. > > > On Aug 30, 2012, at 1:25, "Anders Nilsson" > wrote: > > Hi, > > > > I’m forwarding this from a colleague in the UK which looks rather serious. > > I’ve not yet read it through but found it so urgent that I’ll forward it > right away. > > > > Cheers > > Anders Nilsson > > Umeå university > > SUNET Sweden > > > > > *From: *"Paul Hill (phill)" > > > *Subject: Advance notice: Microsoft Windows 8 and Cisco centralised > wireless incompatibility.* > > *Date: *August 29, 2012 21:22:20 GMT+02:00 > > *To: *WIRELESS-ADMIN@JISCMAIL.AC.UK > > *Reply-To: *Wireless Issues in the JANET community > > > > > > Hi all, > > I wanted to pre-advise colleagues in advance of a formal Field Notice coming > out shortly that a serious software bug exists in all Cisco centralised > wireless controller versions which support pre-standard Management Frame > Protection (MFP) that will render Windows 8 devices completely unable to > connect to Cisco APs under centralised control, with no easy workaround. > > This will affect every institution on the list using Cisco centralised > wireless so I hope the non-Cisco colleagues won't mind this broadcast as > it's quite important to avoid clients starting to pop up that can't connect > for no apparent reason. Cisco has asked every employee, every partner and > every other contractor we have a relationship with to proactively reach > out to our/their customers to advise of this problem - so you might hear > this twice or more from various contacts / lists / sources over the coming > weeks. > > Problem: Microsoft Windows 8, to be released on October 26th, is among the > first clients to support IEEE 802.11w natively in the OS. Clients running > 802.11w fail to connect to Cisco's MFP capable APs because of interoperability > issues in the service capability negotiation. It is /not/ possible to address > this by simply disabling MFP on the Cisco Infrastructure, and Microsoft > confirm > that Windows 8 does not provide any way (e.g., RegKey, Group Policy) to turn > off 802.11w as it is considered a positive feature to always have turned on > for security purposes. The Cisco bug ID tracking this is CSCua29504. > > Solution: The only two solutions are: > 1. Update the Controller code to a fixed version. > 2. Downgrade to a pre-Windows 8 wireless NIC driver on the client device - > where that option is available - as 802.11w is NIC driver and/or supplicant > dependant. The only allowance Windows 8 makes is to not enforce 802.11w > on pre-Windows 8 driver sets which will not work with most vendors' NICs > otherwise. Clearly, the support implications of advising end users to do > this will not scale, will not work indefinitely, and Cisco is not relying > on this option as any kind of sustainable or permanent workaround. > > The plan is to patch the bug so that Windows 8 and other 802.11w capable > clients can connect to Cisco infrastructure on the 7.0 code train (Early > September), 7.2 code train (Late September) and 7.3 first release code train > (Available by the end of August). > > This fix does not implement 802.11w but instead ensures that the communication > from 802.11w enabled clients is interpreted correctly by the Access Point. > There are no plans to patch this on the 5.0, 5.1, 5.2, 6.0 and 7.1 code-trains > which have passed their End of Software Maintenance (EoSM) or End of Life > (EoL) dates, and so 7.0 is the minimum release to move to if still running > <=7.0 and needing the fix; and 7.2 if running 7.1. This issue does not affect > version 4.2 and previous. > > Finally, the IEEE standard version of MFP - 802.11w (called Protected > Management Frames - PMF) - will be supported in 7.4 (early Q1 2013). > > For now, I would advise scheduling a software upgrade window on your Cisco > controllers ready for when the fixed code versions are released (if not > wishing, > or not able due to controller model, to adopt 7.3 soon). This will avoid > a flurry of user support cases coming in the day they start arriving on campus > with Windows 8 devices on or soon after launch. The route to obtain the fixed > software versions is via your normal support channel. > > It goes without saying that this is a deeply unfortunate situation to have > arisen, but I hope you won't shoot the messenger! :-) As bugs go this is > right up there as quite a stunner. I expect to be quite busy over the next > few months across Public Sector as this ripples out to customers who have > not been reachable in advance for whatever reason. > > Please feel free to share this as widely as possible with any colleagues > or other institutions you believe would be interested that are not on this > list. > > Regards, > Paul > -- > Paul A. Hill CCDP, CCNP Wireless, CWNP Inc. CWDP & CWSP > Head of Wireless Technologies, Public Sector UK > > Cisco Systems Ltd. E-mail: phill@cisco.com > 10 New Square Direct Tel: +44 (0)20 8824 8534 > Bedfont Lakes Direct Fax: +44 (0)20 7900 2337 > Feltham Mobile *: As Direct Telephone > Middlesex Main Tel: +44 (0)20 8824 1000 > TW14 8HA Main Fax: +44 (0)20 8824 1001 > United Kingdom Voicemail: 844 48534 > * Single Number Reach rings all of my contact devices simultaneously. > > Cisco Systems Limited (Company Number: 02558939), is registered in England > and Wales with its registered office at 1 Callaghan Square, Cardiff, South > Glamorgan CF10 5BT. > > This e-mail may contain confidential and privileged material for the sole > use of the intended recipient. Any review, use, distribution or disclosure > by others is strictly prohibited. If you are not the intended recipient > (or authorised to receive for the recipient), please contact the sender by > reply e-mail and delete all copies of this message. > > > > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Hi All,

 

I questioned our Cisco SE about this and he passed along the following bug description.

As you’ll read this affects WPA/WPA2-AES only. I’ve tested and confirmed WPA/TKIP works fine.

The message is a bit misleading in my view.

 

-Pete

 

802.11w-capable client fails pairwise key handshake with AES.

 

Symptom:

 

An 802.11w-capable client, such as a PC running Windows 8, cannot connect to an

SSID using WPA or WPA2 key management with AES encryption. The AP will send the

M1 pairwise key message, but the PC will never respond with M2.

 

With "debug client" in effect, a message similar to the following will be seen:

 

*dot1xMsgTask: Jun 12 20:23:37.471: 00:11:22:33:44:55 Retransmit failure for

EAPOL-Key M1

to mobile 00:11:22:33:44:55, retransmit count 5, mscb deauth count 0

 

Conditions:

 

Client is 802.11w-capable, wireless infrastructure is CUWN, SSID using WPA2/AES

or WPA/AES. This bug affects CUWN 5.2.178.0 and above, but not CUWN 4.2 or

earlier, nor does it affect autonomous IOS APs.

 

Workaround:

 

Use WPA/TKIP or WPA2/TKIP instead. Note that this will limit the client

to 802.11g/802.11a data rates.

 

Another workaround is to use a Windows 7, rather than Windows 8 driver, for the

Adapter.

 

Status  
Fixed 
(Resolved) 
Severity  
2 - severe 

Last Modified  
In Last 2 weeks 

Product  
Cisco 5500 Series Wireless Controllers

Technology  


1st Found-In  
5.2(178.0)
6.0(183.0)
7.0(98.0)
7.2(103.0)
7.2(104.20) 

Fixed-In  
7.0(236.0)
7.3(1.67)
7.2(110.4)
7.0(235.1)
7.2(111.1)
7.4(1.20) 

Component(s)  
wlc-security 

 

 

Message from chris@mit.edu

The big problem is that workaround isn't really feasible if you have an 11n infrastructure.  85% of my clients are 11n.

-Chris

Does this problem happen when the WLAN is configured with WPA2/AES only? What if the WLAN is configured with WPA/TKIP and WPA2/AES? will the Windows 8 client connect with WPA/TKIP in this case? --- Dennis Xu Network Analyst, Computing and Communication Services University of Guelph 5198244120 x 56217 ----- Original Message ----- From: "Chris Murphy" To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Sent: Thursday, August 30, 2012 9:28:57 PM Subject: Re: [WIRELESS-LAN] SV: [WIRELESS-LAN] FWD: [WLAN] Fwd: Advance notice: Microsoft Windows 8 and Cisco centralised wireless incompatibility. The big problem is that workaround isn't really feasible if you have an 11n infrastructure. 85% of my clients are 11n. -Chris
Our network supports 802.11n with both WPA2/AES and WPA/TKIP. When the W8 client was configured for WPA2/AES it wouldn't connect. When configured for WPA/TKIP it connected w/o a problem. Sent from my iPhone
Hmmm... Sounds like a problem related to a specific chipset. WPA2/AES works great with 7.0.230 and Intel 5300 and MFP set to optional. Cheers Anders Nilsson -----Ursprungligt meddelande----- Från: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] För Peter Bove Skickat: den 31 augusti 2012 04:52 Till: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Ämne: Re: [WIRELESS-LAN] SV: [WIRELESS-LAN] FWD: [WLAN] Fwd: Advance notice: Microsoft Windows 8 and Cisco centralised wireless incompatibility. Our network supports 802.11n with both WPA2/AES and WPA/TKIP. When the W8 client was configured for WPA2/AES it wouldn't connect. When configured for WPA/TKIP it connected w/o a problem. Sent from my iPhone
Message from iam@st-andrews.ac.uk

I've checked with a Cisco Engineer and this is a non-issue. It is Cisco being pro-active about fixing the bug so that 11w capable clients can join the Cisco wireless network. Below is what the Cisco engineer explained. The bug is CSCua29504: 802.11w-capable client fails a pairwise key handshake with AES 802.11w capable clients using WPA/WPA2 with AES, and will not be able to successfully connect to Cisco Controller-based Access Points configured with CUWN releases 5.2.178.0 to 7.2.110.0. This bug does not impact customers running WPA/TKIP. It does not impact releases prior to 5.2.178.0, nor does it impact standalone (autonomous) releases. The 7.3 release, (posted on August 30th 2012) fixes this interoperability issue. So, if you intend on supporting clients with 802.11w, (which will not be broadly available until the November / December timeframe this year), Cisco recommends upgrading the Wireless LAN Controllers to the new 7.3 code which is  available on Cisco CCO. However, if for some reason you do not want to move forward to the 7.3 release then the same fix will be posted by the end of September in the 7.0 and 7.2 code trains  - thus eliminating the issue from all supported software versions. -- ian
Ok good but who is doing WPA today. WPA2/AES is the only encryption we use (and everyone else should use as well ) and as far I know this is where the bug will bite us. I was under the impression that Cisco would release a patch today for the 7.0 train. Cheers Anders Nilsson Umeå university SUNET Sweden -----Ursprungligt meddelande----- Från: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] För Ian McDonald Skickat: den 3 september 2012 10:33 Till: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Ämne: Re: [WIRELESS-LAN] FWD: [WLAN] Fwd: Advance notice: Microsoft Windows 8 and Cisco centralised wireless incompatibility. I've checked with a Cisco Engineer and this is a non-issue. It is Cisco being pro-active about fixing the bug so that 11w capable clients can join the Cisco wireless network. Below is what the Cisco engineer explained. The bug is CSCua29504: 802.11w-capable client fails a pairwise key handshake with AES 802.11w capable clients using WPA/WPA2 with AES, and will not be able to successfully connect to Cisco Controller-based Access Points configured with CUWN releases 5.2.178.0 to 7.2.110.0. This bug does not impact customers running WPA/TKIP. It does not impact releases prior to 5.2.178.0, nor does it impact standalone (autonomous) releases. The 7.3 release, (posted on August 30th 2012) fixes this interoperability issue. So, if you intend on supporting clients with 802.11w, (which will not be broadly available until the November / December timeframe this year), Cisco recommends upgrading the Wireless LAN Controllers to the new 7.3 code which is  available on Cisco CCO. However, if for some reason you do not want to move forward to the 7.3 release then the same fix will be posted by the end of September in the 7.0 and 7.2 code trains  - thus eliminating the issue from all supported software versions. -- ian
Message from trent.hurt@louisville.edu

I opened a TAC case and they gave me an engineering patch specific for my code release. They told me that the code that contains the fix will be released before Win8 official release date, but they could not give me an exact date.
Message from iam@st-andrews.ac.uk

My understanding is also that this will be fixed before the Win8 release date, though the most specific I could get was by the end of September. -- ian
Unfortunately it means we're all doing controller and ncs and mse upgrades in the very short window between the release dates from Cisco and Microsoft... On 9/4/2012 10:40 AM, Ian McDonald wrote: > My understanding is also that this will be fixed before the Win8 release date, though the most specific I could get was by the end of September. > > -- > ian > >
Message from cwieri39@calvin.edu

Just as an FYI for those running Cisco, I noticed today that 7.0.235.3 was released on Sep 11 2012 for both 4400 series and 5508 series controllers. One of the resolved caveats is bug CSCua29504 which is the Windows 8 802.11w-capable client bug. Chris Wieringa >>> On 9/3/2012 at 5:55 AM, Anders Nilsson wrote: > Ok good but who is doing WPA today. WPA2/AES is the only encryption we use > (and everyone else should use as well ) and as far I know this is where the > bug will bite us. > I was under the impression that Cisco would release a patch today for the > 7.0 train. > > Cheers > Anders Nilsson > Umeå university > SUNET Sweden > > -----Ursprungligt meddelande----- > Från: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] För Ian McDonald > Skickat: den 3 september 2012 10:33 > Till: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Ämne: Re: [WIRELESS-LAN] FWD: [WLAN] Fwd: Advance notice: Microsoft Windows 8 > and Cisco centralised wireless incompatibility. > > I've checked with a Cisco Engineer and this is a non-issue. It is Cisco being > pro-active about fixing the bug so that 11w capable clients can join the Cisco > wireless network. Below is what the Cisco engineer explained. > > The bug is CSCua29504: 802.11w-capable client fails a pairwise key handshake > with AES 802.11w capable clients using WPA/WPA2 with AES, and will not be > able to successfully connect to Cisco Controller-based Access Points > configured with CUWN releases 5.2.178.0 to 7.2.110.0. This bug does not > impact customers running WPA/TKIP. > It does not impact releases prior to 5.2.178.0, nor does it impact > standalone (autonomous) releases. > > The 7.3 release, (posted on August 30th 2012) fixes this interoperability > issue. So, if you intend on supporting clients with 802.11w, (which will not > be broadly available until the November / December timeframe this year), > Cisco recommends upgrading the Wireless LAN Controllers to the new 7.3 code > which is available on Cisco CCO. However, if for some reason you do not want > to move forward to the 7.3 release then the same fix will be posted by the > end of September in the 7.0 and 7.2 code trains - thus eliminating the issue > from all supported software versions. > > -- > ian > >
I just tested the latest Windows 8 version to be released (Windows 8 Enterprise Evaluation build 9200) and I can connect to our secure WLANs with WPA2/AES. Our controllers are running version 7.0.230.0. It seems Microsoft has fixed this issue on Win 8? --- Dennis Xu Network Analyst, Computing and Communication Services University of Guelph 5198244120 x 56217
On 9/17/2012 1:28 PM, Dennis Xu wrote: > I just tested the latest Windows 8 version to be released (Windows 8 Enterprise Evaluation build 9200) and I can connect to our secure WLANs with WPA2/AES. Our controllers are running version 7.0.230.0. It seems Microsoft has fixed this issue on Win 8? 7.0.230.3 is out, it has the fix in it. The most recent 7.3 code also has the fix in it. -Rick -- Rick Coloccia, Jr. Network Manager State University of NY College at Geneseo 1 College Circle, 119 South Hall Geneseo, NY 14454 V: 585-245-5577 F: 585-245-5579 ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Close
Close


Annual Conference
September 29–October 2
View Proceedings

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.