On 3/30/2014 1:30 PM, Steve Bohrer wrote:
On 3/28/2014 6:58 PM, Curtis, Bruce wrote:
We have seen a small number of similar problems but in some cases they
may have been Intel wireless chips that did not get DHCP when other clients
were also connected to an AP.
http://www.intel.com/support/wireless/wlan/sb/CS-034535.htm
A work around that some folks here found (not sure if it works for both
Intel and Broadcom) was to disable 802.11n on the problem machines so they
just used the older 802.11 speeds. Once 802.11n was disabled on the problem
machines they obtained IPs via DHCP just fine. Since it was only a small
number of machines we have not discovered more details but I suspect it may
be related to our disabling of lower 802.11n speeds on our wireless
network. (Lower 802.11 speeds are also disabled).
Bruce, I believe this particular issue is an Intel driver bug -- disabling N
support apparently avoids the buggy code, so your network's disabled lower
802.11n speeds may not be relevant. (I'm afraid this is just "stuff I've seen
online when exploring Win 8.1 wifi issues" thus I don't have a reference.)
While it's virtually impossible to sort out all of the root causes that are
"fixed" by disabling 11n, the Intel one at least sounds like a 2 vs 3 stream
bug that our Juniper support guys let us in on a while back.
In short, the bug is that certain drivers will cause two stream cards (like
the incredibly popular 5100) to falsely advertise three stream capability to
the AP. The AP believes the card and sends unicast traffic at 3 stream
speeds, which the client, not understanding, drops. However, broadcast
traffic gets sent at the lowest connected client rate. This in turn means
that if a legacy or further away client connects to the AP, the broken card
can suddenly do enough broadcast based traffic to get an IP address, but
nothing more.
We are having Win8.1 Broadcom and Intel issues on a Meraki network, so it is
not only Cisco gear that triggers these issues.
I've also seen it suggested online that the bug-fixed versions of the Intel
drivers had not be certified or whatever for Win8.1, thus some users hit this
issue when the 8.1 upgrade forced their systems back to a buggy version of the
driver.
Last time I checked, windows update was still by default shipping ancient
versions of the Intel drivers with the bug intact. I'd be less than
astonished if this were also the case for other manufacturers.
Broadcom Win 8.1 problems also sometimes seem to be helped by going to a Win7
driver (when available) but it is not clear to me if this is a driver bug by
Broadcom, or if Win8.1 has changed driver requirements in a way that breaks
WPA2-Enterprise.
Still no real evidence of "root causes" for Win8.1 wifi flakiness on
Enterprise networks. One of our affected users has a new Surface Pro something
tablet with Broadcom wifi, and I was hopeful that if he pursued it with MS
support we might find if the issue was the drivers or the OS, but so far he's
not really gotten anywhere.
One thing I find a bit frustrating is users who are sure that the issue is our
network rather than their laptop, because their laptop works fine on all the
WPA2-Personal networks they try. As far as I can tell, a device's wifi stack
can be fine for WPA2-Personal yet totally hosed for WPA2-Enterprise.
If I had a nickel for every time I heard a complaint that boiled down to "But
it works in my basement at home!" I'd probably have enough to buy them all
enterprise class devices instead...
--
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
**********
Participation and subscription information for this EDUCAUSE Constituent Group
discussion list can be found at http://www.educause.edu/groups/.
