RE: Windows Wireless Clients- strange behavior after recent Windows Updates?
Interesting thread. I've only recently been made aware of similar issue on our WLAN that may have been occurring since the start of fall quarter but took a few weeks to filter through to me from our helpdesk and NOC. This also seems new to us and we've made no configuration changes since winter quarter of last year. In our case DHCP transactions seem to occur normally according to DHCP logs. Requests are being received And ACKs returned. The client seems to be receiving the ACKs as they maintain the same IP address being issued during a release/renew. However, as mentioned in other threads the client cannot ping anything on the network but itself. However, in many of the reports I've received and some of the duplication we've been able to produce, a reset of the NIC or even full reboot of the client does not alleviate the issue. Seems only moving to a different controller alleviates the issue. What is interesting, is most of the recent talk has been focused on Cisco sites, but in our case we are an Aruba shop. The one commonality may be mobility as we also run a large mobility domain. This may be just coincidence, but the symptoms sounded so eerily familiar, I thought I would post our experiences to date. After a significant amount of problem replication and troubleshooting last week, I finally opened a case with Aruba TAC on this which is currently being worked. We'll see what they can come up with. Regarding the post from Bruce Johnson: When a mobile station roams from an AP joined to one controller, to an AP joined to another controller, the client may suffer a lack of data connectivity for a period as long as the configured user idle timeout. This may also be a commonality. I reduced the configured 'idle timeout' on our controllers to 300 seconds late last week which seems to have stemmed the number of complaints, but it's still too early to say for sure. Also in similar problems we've had in the past, Aruba has a similar workaround to the one Bruce mentions;' Delete the mobility members from the configuration and re-add them.' Fortunately, though we don't have to re-add them manually, it is still not a very scalable solution for clients stuck out on campus with no connectivity. ___ Jim Galiardi Network Specialist, Network Systems UW Technology University of Washington (206)616-0397 Box 354150 -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[EMAIL PROTECTED] On Behalf Of Lee H Badman Sent: Friday, October 31, 2008 11:35 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: Windows Wireless Clients- strange behavior after recent Windows Updates? It's good to know we have our choice of bugs on this condition:) It's looking very much like the symmetric mobility tunneling that the esteemed gentleman from New Mexico mentioned- set this up on our spare controllers and tested thoroughly, we're looking much better. But we went to this version of code months ago, yet the problem started in the last week- that's the real confusion agent to me. Lee H. Badman Wireless/Network Engineer Information Technology and Services Syracuse University 315 443-3003 -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[EMAIL PROTECTED] On Behalf Of Johnson, Bruce T Sent: Friday, October 31, 2008 11:55 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Windows Wireless Clients- strange behavior after recent Windows Updates? CSCsr40109 Bug Details http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method =3DfetchBu gDetailsbugId=3DCSCsl51486from=3Dsummary Mobility announcements not sent after an upgrade when wrong version =20 Symptom: When a mobile station roams from an AP joined to one controller, to an AP joined to another controller, the client may suffer a lack of data connectivity for a period as long as the configured user idle timeout. debug mobility handoff enable output shows that, after the roam event, the WLC to which the client has roamed does not send the MobileAnnounce message to the WLC from which the client had roamed. Conditions: Multiple WLCs in the same mobility group, running 4.2.112.0. The WLCs had all been upgraded from 4.1.185.0, and then had not been rebooted again. Workaround: There are 2 workarounds for this issue, 1) Delete the mobility members from the configuration and re-add them. 2) After upgrading all WLCs to 4.2.112.0, reboot them all once more. =20 Bruce T. Johnson | Network Engineer | Partners Healthcare=20 Network Engineering | 617.726.9662 | Pager: 31633 | [EMAIL PROTECTED] From: The EDUCAUSE Wireless Issues Constituent Group Listserv on behalf of James Nesbitt Sent: Fri 10/31/2008 11:49 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Windows Wireless Clients- strange behavior after recent Windows Updates? Lee,=20
RE: Windows Wireless Clients- strange behavior after recent Windows Updates?
Oh, also should add this is occurring on our open SSID, so WPA or 802.1x is not a factor for us. ___ Jim Galiardi Network Specialist, Network Systems UW Technology University of Washington (206)616-0397 Box 354150 -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[EMAIL PROTECTED] On Behalf Of Jim Galiardi Sent: Monday, November 03, 2008 10:03 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: Windows Wireless Clients- strange behavior after recent Windows Updates? Interesting thread. I've only recently been made aware of similar issue on our WLAN that may ha= ve been occurring since the start of fall quarter but took a few weeks to f= ilter through to me from our helpdesk and NOC. This also seems new to us a= nd we've made no configuration changes since winter quarter of last year. In our case DHCP transactions seem to occur normally according to DHCP logs= . Requests are being received And ACKs returned. The client seems to be r= eceiving the ACKs as they maintain the same IP address being issued during = a release/renew. However, as mentioned in other threads the client cannot = ping anything on the network but itself. However, in many of the reports I= 've received and some of the duplication we've been able to produce, a rese= t of the NIC or even full reboot of the client does not alleviate the issue= . Seems only moving to a different controller alleviates the issue. What is interesting, is most of the recent talk has been focused on Cisco s= ites, but in our case we are an Aruba shop. The one commonality may be mob= ility as we also run a large mobility domain. This may be just coincidence, but the symptoms sounded so eerily familiar, = I thought I would post our experiences to date. After a significant amount= of problem replication and troubleshooting last week, I finally opened a c= ase with Aruba TAC on this which is currently being worked. We'll see what= they can come up with. Regarding the post from Bruce Johnson:=20 When a mobile station roams from an AP joined to one controller, to an AP = joined to another controller, the client may suffer a lack of data connecti= vity for a period as long as the configured user idle timeout. This may also be a commonality. I reduced the configured 'idle timeout' on= our controllers to 300 seconds late last week which seems to have stemmed = the number of complaints, but it's still too early to say for sure. Also in similar problems we've had in the past, Aruba has a similar workaro= und to the one Bruce mentions;' Delete the mobility members from the config= uration and re-add them.' Fortunately, though we don't have to re-add them= manually, it is still not a very scalable solution for clients stuck out o= n campus with no connectivity.=20 ___ Jim Galiardi Network Specialist, Network Systems UW Technology University of Washington (206)616-0397 Box 354150 -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIREL= [EMAIL PROTECTED] On Behalf Of Lee H Badman Sent: Friday, October 31, 2008 11:35 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: Windows Wireless Clients- strange behavior after recent Window= s Updates? It's good to know we have our choice of bugs on this condition:) It's looking very much like the symmetric mobility tunneling that the esteemed gentleman from New Mexico mentioned- set this up on our spare controllers and tested thoroughly, we're looking much better. But we went to this version of code months ago, yet the problem started in the last week- that's the real confusion agent to me. Lee H. Badman Wireless/Network Engineer Information Technology and Services Syracuse University 315 443-3003 -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[EMAIL PROTECTED] On Behalf Of Johnson, Bruce T Sent: Friday, October 31, 2008 11:55 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Windows Wireless Clients- strange behavior after recent Windows Updates? CSCsr40109 Bug Details http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method =3D3DfetchBu gDetailsbugId=3D3DCSCsl51486from=3D3Dsummary Mobility announcements not sent after an upgrade when wrong version =3D20 Symptom: When a mobile station roams from an AP joined to one controller, to an AP joined to another controller, the client may suffer a lack of data connectivity for a period as long as the configured user idle timeout. debug mobility handoff enable output shows that, after the roam event, the WLC to which the client has roamed does not send the MobileAnnounce message to the WLC from which the client had roamed. Conditions: Multiple WLCs in the same mobility group, running 4.2.112.0. The WLCs had all been upgraded from 4.1.185.0, and then had not been rebooted again. Workaround: There are 2
RE: [WIRELESS-LAN] Windows Wireless Clients- strange behavior after recent Windows Updates?
Hi Jim- Last Friday, on our test/hot-spare controllers, I enabled Secure Mobility Tunneling and rebooted the controllers. Problem went away. Over the weekend, I did this to our production controllers- again, all is well. But then... as I read the notes, the feature to me makes no sense at all for our topology- all controllers and APs managed on same L2 space, all affected users in a single VLAN that has only one L3 head-end. So, for spite I removed the feature this morning on our test/hot-spare controllers- and all is still well. I believe that in our case, the controllers needed to be rebooted. There is a Cisco bug that may explain this for us based on our versions that we came from and went to, but it waited months to reveal itself- that's the zinger that I can't quite rationalize. Ah... how I pine for fat APs on certain days:) Lee H. Badman Wireless/Network Engineer Information Technology and Services Syracuse University 315 443-3003 -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[EMAIL PROTECTED] On Behalf Of Jim Galiardi Sent: Monday, November 03, 2008 1:03 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Windows Wireless Clients- strange behavior after recent Windows Updates? Interesting thread. I've only recently been made aware of similar issue on our WLAN that may have been occurring since the start of fall quarter but took a few weeks to filter through to me from our helpdesk and NOC. This also seems new to us and we've made no configuration changes since winter quarter of last year. In our case DHCP transactions seem to occur normally according to DHCP logs. Requests are being received And ACKs returned. The client seems to be receiving the ACKs as they maintain the same IP address being issued during a release/renew. However, as mentioned in other threads the client cannot ping anything on the network but itself. However, in many of the reports I've received and some of the duplication we've been able to produce, a reset of the NIC or even full reboot of the client does not alleviate the issue. Seems only moving to a different controller alleviates the issue. What is interesting, is most of the recent talk has been focused on Cisco sites, but in our case we are an Aruba shop. The one commonality may be mobility as we also run a large mobility domain. This may be just coincidence, but the symptoms sounded so eerily familiar, I thought I would post our experiences to date. After a significant amount of problem replication and troubleshooting last week, I finally opened a case with Aruba TAC on this which is currently being worked. We'll see what they can come up with. Regarding the post from Bruce Johnson: When a mobile station roams from an AP joined to one controller, to an AP joined to another controller, the client may suffer a lack of data connectivity for a period as long as the configured user idle timeout. This may also be a commonality. I reduced the configured 'idle timeout' on our controllers to 300 seconds late last week which seems to have stemmed the number of complaints, but it's still too early to say for sure. Also in similar problems we've had in the past, Aruba has a similar workaround to the one Bruce mentions;' Delete the mobility members from the configuration and re-add them.' Fortunately, though we don't have to re-add them manually, it is still not a very scalable solution for clients stuck out on campus with no connectivity. ___ Jim Galiardi Network Specialist, Network Systems UW Technology University of Washington (206)616-0397 Box 354150 -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[EMAIL PROTECTED] On Behalf Of Lee H Badman Sent: Friday, October 31, 2008 11:35 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: Windows Wireless Clients- strange behavior after recent Windows Updates? It's good to know we have our choice of bugs on this condition:) It's looking very much like the symmetric mobility tunneling that the esteemed gentleman from New Mexico mentioned- set this up on our spare controllers and tested thoroughly, we're looking much better. But we went to this version of code months ago, yet the problem started in the last week- that's the real confusion agent to me. Lee H. Badman Wireless/Network Engineer Information Technology and Services Syracuse University 315 443-3003 -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[EMAIL PROTECTED] On Behalf Of Johnson, Bruce T Sent: Friday, October 31, 2008 11:55 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Windows Wireless Clients- strange behavior after recent Windows Updates? CSCsr40109 Bug Details http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method =3DfetchBu gDetailsbugId=3DCSCsl51486from=3Dsummary Mobility announcements not sent
802.1X EAP/TLS with Leopard
Our wireless environment consists of strictly Windows XP laptops connecting wirelessly via 802.1X EAP/TLS with an HP Wireless (WESM) infrastructure. We have a Microsoft Certification Authority which issues out client/computer based certificates to the XP laptops via Auto Enrollment in Group Policy. Recently we received a batch of Macbooks running Leopard. For the life of me, I cannot figure out how to get client side certificate (computer certs) installed on the Macs. Has anyone done this successfully? I am not a Mac-person so my knowledge is limited, but I don't even see a way to request certificates on the Mac that are computer/client-based from my Microsoft Certification Authority. If anyone has experience with this, let me know, thanks. JR myhosting.com - Premium Microsoft® Windows® and Linux web and application hosting - http://link.myhosting.com/myhosting ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
RE: [WIRELESS-LAN] Windows Wireless Clients- strange behavior after recent Windows Updates?
Jim, What version of Aruba code are you running? At Emory, we've experienced similar problems since our move to 3.3.1 code (currently on 3.3.1.15). We've been working with Aruba TAC and have identified a bug - bugid 27234. It relates to MobileIP where a wireless client may not be cleanly removed from the mobility table. Symptoms are strong signal level and 802.1x authentication occurs normally but user is unsuccessful in getting an IP address (self-assigned or it just keeps trying to reconnect). A user debug shows the user requesting a DHCP IP address, but the mobility process preventing it from being assigned. We've only seen a handful of users affected by this problem. The users are generally only affected in locations homed to one controller, and can connect normally at other locations homed to different controllers. The good news is that Aruba has a patch for this in 3.3.1.20 code. We are upgrading next weekend to address this problem. There are some workarounds (some drastic) that I'll let Aruba TAC tell you about to temporarily address this. - Stan Brooks - CWNA/CWSP Emory University University Technology Services 404.727.0226 AIM/Y!/Twitter: WLANstan MSN: [EMAIL PROTECTED] GoogleTalk: [EMAIL PROTECTED] -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[EMAIL PROTECTED] On Behalf Of Jim Galiardi Sent: Monday, November 03, 2008 1:03 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Windows Wireless Clients- strange behavior after recent Windows Updates? Interesting thread. I've only recently been made aware of similar issue on our WLAN that may have been occurring since the start of fall quarter but took a few weeks to filter through to me from our helpdesk and NOC. This also seems new to us and we've made no configuration changes since winter quarter of last year. In our case DHCP transactions seem to occur normally according to DHCP logs. Requests are being received And ACKs returned. The client seems to be receiving the ACKs as they maintain the same IP address being issued during a release/renew. However, as mentioned in other threads the client cannot ping anything on the network but itself. However, in many of the reports I've received and some of the duplication we've been able to produce, a reset of the NIC or even full reboot of the client does not alleviate the issue. Seems only moving to a different controller alleviates the issue. What is interesting, is most of the recent talk has been focused on Cisco sites, but in our case we are an Aruba shop. The one commonality may be mobility as we also run a large mobility domain. This may be just coincidence, but the symptoms sounded so eerily familiar, I thought I would post our experiences to date. After a significant amount of problem replication and troubleshooting last week, I finally opened a case with Aruba TAC on this which is currently being worked. We'll see what they can come up with. Regarding the post from Bruce Johnson: When a mobile station roams from an AP joined to one controller, to an AP joined to another controller, the client may suffer a lack of data connectivity for a period as long as the configured user idle timeout. This may also be a commonality. I reduced the configured 'idle timeout' on our controllers to 300 seconds late last week which seems to have stemmed the number of complaints, but it's still too early to say for sure. Also in similar problems we've had in the past, Aruba has a similar workaround to the one Bruce mentions;' Delete the mobility members from the configuration and re-add them.' Fortunately, though we don't have to re-add them manually, it is still not a very scalable solution for clients stuck out on campus with no connectivity. ___ Jim Galiardi Network Specialist, Network Systems UW Technology University of Washington (206)616-0397 Box 354150 -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[EMAIL PROTECTED] On Behalf Of Lee H Badman Sent: Friday, October 31, 2008 11:35 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: Windows Wireless Clients- strange behavior after recent Windows Updates? It's good to know we have our choice of bugs on this condition:) It's looking very much like the symmetric mobility tunneling that the esteemed gentleman from New Mexico mentioned- set this up on our spare controllers and tested thoroughly, we're looking much better. But we went to this version of code months ago, yet the problem started in the last week- that's the real confusion agent to me. Lee H. Badman Wireless/Network Engineer Information Technology and Services Syracuse University 315 443-3003 -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[EMAIL PROTECTED] On Behalf Of Johnson, Bruce T Sent:
