RE: [WIRELESS-LAN] More client weirdness
I stopped thinking about going to 8.0 releases since this was published https://www.cisco.com/c/en/us/products/collateral/wireless/8540-wireless-controller/eos-eol-notice-c51-739984.html Yahya Jaber. Sr. Wireless Engineer IT Network & Communications – Engineering Building 14, Level 3, Rm 308-WS07 KAUST 23955-6900 Thuwal, KSA Email yahya.ja...@kaust.edu.sa<mailto:yahya.ja...@kaust.edu.sa> Office +966 (0) 12 8081237 Mobile +966 (0) 558697555 On Call Rotation Mobile: +966 54 470 1177 From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Blasingame, Bob Sent: Wednesday, April 25, 2018 22:22 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness Hopefully this is no longer a problem for you. We ran into this same issue and just resolved it this past weekend with a code upgrade. We have 702W and 2702 APs on 5508s running 8.0.140, with random clients (mostly iPhones) dropping after five minutes. Finally send in client debug and Prime client troubleshooting logs to TAC. Said we were hitting this bug https://bst.cloudapps.cisco.com/bugsearch/bug/CSCve81314/?rfs=iqvred and gave us code 8.0.152.6 which has resolved the issue. Bob Blasingame Network and Communications Engineer IT Infrastructure Xavier University 513-745-4899 Get Technical HELP anytime!<http://www.xavier.edu/ts/helpdesk/> [cid:image001.gif@01D3DD36.DB7C3840] From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Tristan Gulyas Sent: Monday, April 9, 2018 11:03 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Hi all, Sounds like the same issue we're seeing. There seems to be an intermittent spread of devices. Anything from devices not receiving DHCP to devices remaining connected for 5-10 minutes and then ceasing to pass traffic any further. Today's request was from two users with iPhone X devices, but her MacBook Pro works fine on the same AP. I can confirm the Dell laptops with Killer 1535s are still an issue. I attempted a replacement of one 702W and the issue returned straight away, so we're confident it's not hardware. We use AAA-Override for interface-name but we don't do CoA after auth. Thanks all - this has been a *huge* help. Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu<mailto:tristan.gul...@monash.edu> monash.edu<http://monash.edu/> On 10 Apr 2018, at 9:52 am, Jason Cook mailto:jason.c...@adelaide.edu.au>> wrote: We also seen the same/similar issues on 702w, however it seems an iPad has been the biggest issue. The user moves down the hall to a 3602i and no worries, moves back to the 702w and it’s a problem. Other devices including her iPhone is fine. Strangely it seems to occur randomly (days or weeks apart), and always the same device. Rebooting the AP will resolve it, or just time! But waiting for resolution could be hours. On 8.2.164.0 -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Gray, Sean Sent: Tuesday, 10 April 2018 12:36 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Hi Tristan, So the problem with the specific student I mentioned seemed to resolve itself. Our latest issue, that seems to again only impact the 702w involves a couple of MacBook Air users, running either Sierra or High Sierra. A debug shows that on occasion when trying to connect to a.1x network they make it as far as the DHCP required state and then never request an IP. They hit the timeout, the WLC deletes the client and the dance begins again. Thanks Sean From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.ED
RE: [WIRELESS-LAN] More client weirdness
Hopefully this is no longer a problem for you. We ran into this same issue and just resolved it this past weekend with a code upgrade. We have 702W and 2702 APs on 5508s running 8.0.140, with random clients (mostly iPhones) dropping after five minutes. Finally send in client debug and Prime client troubleshooting logs to TAC. Said we were hitting this bug https://bst.cloudapps.cisco.com/bugsearch/bug/CSCve81314/?rfs=iqvred and gave us code 8.0.152.6 which has resolved the issue. Bob Blasingame Network and Communications Engineer IT Infrastructure Xavier University 513-745-4899 Get Technical HELP anytime!<http://www.xavier.edu/ts/helpdesk/> [cid:image001.gif@01D3DCA8.FC72BA30] From: The EDUCAUSE Wireless Issues Constituent Group Listserv On Behalf Of Tristan Gulyas Sent: Monday, April 9, 2018 11:03 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness Hi all, Sounds like the same issue we're seeing. There seems to be an intermittent spread of devices. Anything from devices not receiving DHCP to devices remaining connected for 5-10 minutes and then ceasing to pass traffic any further. Today's request was from two users with iPhone X devices, but her MacBook Pro works fine on the same AP. I can confirm the Dell laptops with Killer 1535s are still an issue. I attempted a replacement of one 702W and the issue returned straight away, so we're confident it's not hardware. We use AAA-Override for interface-name but we don't do CoA after auth. Thanks all - this has been a *huge* help. Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu<mailto:tristan.gul...@monash.edu> monash.edu<http://monash.edu/> On 10 Apr 2018, at 9:52 am, Jason Cook mailto:jason.c...@adelaide.edu.au>> wrote: We also seen the same/similar issues on 702w, however it seems an iPad has been the biggest issue. The user moves down the hall to a 3602i and no worries, moves back to the 702w and it’s a problem. Other devices including her iPhone is fine. Strangely it seems to occur randomly (days or weeks apart), and always the same device. Rebooting the AP will resolve it, or just time! But waiting for resolution could be hours. On 8.2.164.0 -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Gray, Sean Sent: Tuesday, 10 April 2018 12:36 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Hi Tristan, So the problem with the specific student I mentioned seemed to resolve itself. Our latest issue, that seems to again only impact the 702w involves a couple of MacBook Air users, running either Sierra or High Sierra. A debug shows that on occasion when trying to connect to a.1x network they make it as far as the DHCP required state and then never request an IP. They hit the timeout, the WLC deletes the client and the dance begins again. Thanks Sean From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tristan Gulyas Sent: April-08-18 8:03 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Hi all, We've hit this issue as well. Ever since moving from 8.3.112.7 to 8.3.135.2. What we see: * Devices with the Killer NIC 1535 authenticate but can't pass traffic. * Apple devices will connect, pass traffic for a while, then go dead. We believe we may have seen this on a 1532 series AP as well. Debugs don't seem to give us much. 3702i, 3802i appear to be unaffected. Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu<mailto:tristan.gul...@monash.edu&g
RE: [WIRELESS-LAN] More client weirdness
Good to hear, is it working ok? Looks and sounds like it's pretty good. Hoping to take a look at it later this year once we are on 8.5 -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv On Behalf Of Curtis K. Larsen Sent: Saturday, 14 April 2018 12:42 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness Yes, we are playing with DNA Center. We have one production WLC connected to it, one floorplan imported and we get a lot of assurance data from it. We have upgraded a WLC using it, and are trying to get the sensor piece working at the moment. -- Curtis K. Larsen Senior Network Engineer University of Utah IT/CIS Office 801-587-1313 Cell 801-425-7528 From: The EDUCAUSE Wireless Issues Constituent Group Listserv on behalf of Jason Cook Sent: Thursday, April 12, 2018 6:34 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness It's certainly less than ideal.. Has anyone played with DNA-C in the wireless world? -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: The EDUCAUSE Wireless Issues Constituent Group Listserv On Behalf Of Lee H Badman Sent: Friday, 13 April 2018 4:22 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness It bothers me greatly that this OS and these controllers are supposed to also figure into the fabric/DNA story. Compounding current problems- which I know I've been putting up with since 2006- with the whole automation thing just sounds like a less than stellar strategy. Lee Badman | Network Architect Certified Wireless Network Expert (#200) Information Technology Services 206 Machinery Hall 120 Smith Drive Syracuse, New York 13244 t 315.443.3003 f 315.443.4325 e lhbad...@syr.edu<mailto:lhbad...@syr.edu> w its.syr.edu SYRACUSE UNIVERSITY syr.edu From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Jason Cook Sent: Thursday, April 12, 2018 3:17 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness If you want to cut straight to flash issues (and a download link for the poller) 54:50 -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: Jason Cook Sent: Thursday, 12 April 2018 3:54 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: RE: [WIRELESS-LAN] More client weirdness That flash bug is annoying, the Cisco software engineers have a script for identifying and fixing som
RE: [WIRELESS-LAN] More client weirdness
That’s funny, I’ve been discussing that issue with him as well 😊 Hopefully they find a way to recover them -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: The EDUCAUSE Wireless Issues Constituent Group Listserv On Behalf Of Tristan Gulyas Sent: Friday, 13 April 2018 9:20 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness Hi Jason, We've been running wlanpoller for some time, however we hit an issue where the flash filesystem gets marked offline as a result of an fsck, assumed due to a process that locks the flash memory. These couldn't be recovered. I was in that session and the engineer who presented is actively involved in working on our issue with the BU - one of the slides is based on the output from our network :) Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu<mailto:tristan.gul...@monash.edu> monash.edu<http://monash.edu/> On 12 Apr 2018, at 4:23 pm, Jason Cook mailto:jason.c...@adelaide.edu.au>> wrote: That flash bug is annoying, the Cisco software engineers have a script for identifying and fixing some. It doesn’t fix all issues but can at least pre-identify and allow you to manually sort before it becomes an issue. I’ve only just started playing with it. We’ll see if we have any failures at upgrade. We’ve been having a few 2702i’s go down recently while faulty cables are replaced. It’s called wlanpoller, does plenty of other things but since we are doing an upgrade shortly I’ve just started with that. You can ask for it from TAC I got info about this while at Cisco Live Melbourne this year. https://www.ciscolive.com/global/on-demand-library/ Look for “Troubleshooting WLANs - Automating Log Collection and Analysis - BRKEWN-3671” -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Tristan Gulyas Sent: Thursday, 12 April 2018 2:35 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Hi Lee, This is a serious consideration at the moment and would be doing so if we weren't hit by a significant flash corruption bug, which would result in a number of APs failing due to the software change, requiring thousands (and possibly tens of thousands) of contractor dollars to have them replaced since we don't run console cables into our APs, due to the reboot. We'd prefer to only do this once more if we can (i.e. to get away from the flash corruption bug). Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu<mailto:tristan.gul...@monash.edu> monash.edu<http://monash.edu/> On 11 Apr 2018, at 10:25 pm, Lee H Badman mailto:lhbad...@syr.edu>> wrote: Any thoughts of rolling back to older code, rather than living with the issue? Lee Badman | Network Architect Certified Wireless Network Expert (#200) Information Technology Services 206 Machinery Hall 120 Smith Drive Syracuse, New York 13244 t 315.443.3003 f 315.443.4325 e lhbad...@syr.edu<mail
Re: [WIRELESS-LAN] More client weirdness
Yes, we are playing with DNA Center. We have one production WLC connected to it, one floorplan imported and we get a lot of assurance data from it. We have upgraded a WLC using it, and are trying to get the sensor piece working at the moment. -- Curtis K. Larsen Senior Network Engineer University of Utah IT/CIS Office 801-587-1313 Cell 801-425-7528 From: The EDUCAUSE Wireless Issues Constituent Group Listserv on behalf of Jason Cook Sent: Thursday, April 12, 2018 6:34 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness It’s certainly less than ideal.. Has anyone played with DNA-C in the wireless world? -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: The EDUCAUSE Wireless Issues Constituent Group Listserv On Behalf Of Lee H Badman Sent: Friday, 13 April 2018 4:22 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness It bothers me greatly that this OS and these controllers are supposed to also figure into the fabric/DNA story. Compounding current problems- which I know I’ve been putting up with since 2006- with the whole automation thing just sounds like a less than stellar strategy. Lee Badman | Network Architect Certified Wireless Network Expert (#200) Information Technology Services 206 Machinery Hall 120 Smith Drive Syracuse, New York 13244 t 315.443.3003 f 315.443.4325 e lhbad...@syr.edu<mailto:lhbad...@syr.edu> w its.syr.edu SYRACUSE UNIVERSITY syr.edu From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Jason Cook Sent: Thursday, April 12, 2018 3:17 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness If you want to cut straight to flash issues (and a download link for the poller) 54:50 -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: Jason Cook Sent: Thursday, 12 April 2018 3:54 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: RE: [WIRELESS-LAN] More client weirdness That flash bug is annoying, the Cisco software engineers have a script for identifying and fixing some. It doesn’t fix all issues but can at least pre-identify and allow you to manually sort before it becomes an issue. I’ve only just started playing with it. We’ll see if we have any failures at upgrade. We’ve been having a few 2702i’s go down recently while faulty cables are replaced. It’s called wlanpoller, does plenty of other things but since we are doing an upgrade shortly I’ve just started with that. You can ask for it from TAC I got info about this while at Cisco Live Melbourne this year. https://www.ciscolive.com/global/on-demand-library/ Look for “Troubleshooting WLANs - Automating Log Collection and Analysis - BRKEWN-3671” -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and d
Re: [WIRELESS-LAN] More client weirdness
Hi Jason, We've been running wlanpoller for some time, however we hit an issue where the flash filesystem gets marked offline as a result of an fsck, assumed due to a process that locks the flash memory. These couldn't be recovered. I was in that session and the engineer who presented is actively involved in working on our issue with the BU - one of the slides is based on the output from our network :) Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu <mailto:tristan.gul...@monash.edu> monash.edu <http://monash.edu/> > On 12 Apr 2018, at 4:23 pm, Jason Cook wrote: > > That flash bug is annoying, the Cisco software engineers have a script for > identifying and fixing some. It doesn’t fix all issues but can at least > pre-identify and allow you to manually sort before it becomes an issue. I’ve > only just started playing with it. We’ll see if we have any failures at > upgrade. We’ve been having a few 2702i’s go down recently while faulty cables > are replaced. > > It’s called wlanpoller, does plenty of other things but since we are doing an > upgrade shortly I’ve just started with that. You can ask for it from TAC > I got info about this while at Cisco Live Melbourne this year. > https://www.ciscolive.com/global/on-demand-library/ > <https://www.ciscolive.com/global/on-demand-library/> > Look for “Troubleshooting WLANs - Automating Log Collection and Analysis - > BRKEWN-3671” > > > -- > Jason Cook > Information Technology and Digital Services > The University of Adelaide, AUSTRALIA 5005 > Ph: +61 8 8313 4800 > > CRICOS Provider Number 00123M > --- > This email message is intended only for the addressee(s) and contains > information which may be confidential and/or copyright. If you are not the > intended recipient please do not read, save, forward, disclose, or copy the > contents of this email. If this email has been sent to you in error, please > notify the sender by reply email and delete this email and any copies or > links to this email completely and immediately from your system. No > representation is made that this email is free of viruses. Virus scanning is > recommended and is the responsibility of the recipient. > > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > On Behalf Of Tristan Gulyas > Sent: Thursday, 12 April 2018 2:35 PM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: Re: [WIRELESS-LAN] More client weirdness > > Hi Lee, > > This is a serious consideration at the moment and would be doing so if we > weren't hit by a significant flash corruption bug, which would result in a > number of APs failing due to the software change, requiring thousands (and > possibly tens of thousands) of contractor dollars to have them replaced since > we don't run console cables into our APs, due to the reboot. We'd prefer to > only do this once more if we can (i.e. to get away from the flash corruption > bug). > > Cheers, > Tristan > -- > TRISTAN GULYAS > Senior Network Engineer > > Technology Services, eSolutions > Monash University > 738 Blackburn Road > Clayton 3168 > Australia > > T: +61 3 9902 9092 > M: +61 (0)403 224 484 > E: tristan.gul...@monash.edu <mailto:tristan.gul...@monash.edu> > monash.edu <http://monash.edu/> > > On 11 Apr 2018, at 10:25 pm, Lee H Badman <mailto:lhbad...@syr.edu>> wrote: > > Any thoughts of rolling back to older code, rather than living with the issue? > > Lee Badman | Network Architect > > Certified Wireless Network Expert (#200) > Information Technology Services > 206 Machinery Hall > 120 Smith Drive > Syracuse, New York 13244 > > t 315.443.3003 f 315.443.4325 e lhbad...@syr.edu > <mailto:lhbad...@syr.edu> w its.syr.edu <http://its.syr.edu/> > SYRACUSE UNIVERSITY > syr.edu <http://syr.edu/> > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Tristan Gulyas > Sent: Wednesday, April 11, 2018 12:38 AM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > Subject: Re: [WIRELESS-LAN] More client weirdness > > Hi all, > > We have two TAC cases, one for the Dell 1535 and the other for the general > poor connectivity issues. > > We rebooted one AP yesterday and the customer tells us that their > connectivity improved. In
RE: [WIRELESS-LAN] More client weirdness
Here's the results of last night's run. Allegedly many issues fixed. Summary Run 1 Total APs : 2207 Processed APs : 2207 Failed APs : 1 Errors AP FSCK recover : 101 AP MD5 checksum mismatch: 100 AP MD5 zero bytes : 17 FSCK errors : 7 Recovered FSCK errors : 5 Flash busy : 2 AP connection error: timed out : 1 MD5 check - Failure determining active IOS image: 1 Summary Run 2 Total APs : 2207 Processed APs : 2207 Failed APs : 1 Errors AP FSCK recover : 3 FSCK errors : 2 Flash busy : 2 AP MD5 checksum mismatch: 1 AP connection error: timed out : 1 -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv On Behalf Of Jason Cook Sent: Friday, 13 April 2018 10:01 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness That would be easier than typing it out 😊 -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv On Behalf Of Joachim Tingvold Sent: Thursday, 12 April 2018 10:52 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness On 12 Apr 2018, at 9:17, Jason Cook wrote: > If you want to cut straight to flash issues (and a download link for > the poller) > 54:50 Or just go to page 59 on the PDF/PowerPoint-slides (-: -- Joachim ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
RE: [WIRELESS-LAN] More client weirdness
It’s certainly less than ideal.. Has anyone played with DNA-C in the wireless world? -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: The EDUCAUSE Wireless Issues Constituent Group Listserv On Behalf Of Lee H Badman Sent: Friday, 13 April 2018 4:22 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness It bothers me greatly that this OS and these controllers are supposed to also figure into the fabric/DNA story. Compounding current problems- which I know I’ve been putting up with since 2006- with the whole automation thing just sounds like a less than stellar strategy. Lee Badman | Network Architect Certified Wireless Network Expert (#200) Information Technology Services 206 Machinery Hall 120 Smith Drive Syracuse, New York 13244 t 315.443.3003 f 315.443.4325 e lhbad...@syr.edu<mailto:lhbad...@syr.edu> w its.syr.edu SYRACUSE UNIVERSITY syr.edu From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Jason Cook Sent: Thursday, April 12, 2018 3:17 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness If you want to cut straight to flash issues (and a download link for the poller) 54:50 -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: Jason Cook Sent: Thursday, 12 April 2018 3:54 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: RE: [WIRELESS-LAN] More client weirdness That flash bug is annoying, the Cisco software engineers have a script for identifying and fixing some. It doesn’t fix all issues but can at least pre-identify and allow you to manually sort before it becomes an issue. I’ve only just started playing with it. We’ll see if we have any failures at upgrade. We’ve been having a few 2702i’s go down recently while faulty cables are replaced. It’s called wlanpoller, does plenty of other things but since we are doing an upgrade shortly I’ve just started with that. You can ask for it from TAC I got info about this while at Cisco Live Melbourne this year. https://www.ciscolive.com/global/on-demand-library/ Look for “Troubleshooting WLANs - Automating Log Collection and Analysis - BRKEWN-3671” -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Tristan Gulyas Sent: Thursday, 12 April 2018 2:35 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Hi Lee, This is a serious consideration at the moment
RE: [WIRELESS-LAN] More client weirdness
That would be easier than typing it out 😊 -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv On Behalf Of Joachim Tingvold Sent: Thursday, 12 April 2018 10:52 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness On 12 Apr 2018, at 9:17, Jason Cook wrote: > If you want to cut straight to flash issues (and a download link for > the poller) > 54:50 Or just go to page 59 on the PDF/PowerPoint-slides (-: -- Joachim ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
RE: [WIRELESS-LAN] More client weirdness
It bothers me greatly that this OS and these controllers are supposed to also figure into the fabric/DNA story. Compounding current problems- which I know I’ve been putting up with since 2006- with the whole automation thing just sounds like a less than stellar strategy. Lee Badman | Network Architect Certified Wireless Network Expert (#200) Information Technology Services 206 Machinery Hall 120 Smith Drive Syracuse, New York 13244 t 315.443.3003 f 315.443.4325 e lhbad...@syr.edu<mailto:lhbad...@syr.edu> w its.syr.edu SYRACUSE UNIVERSITY syr.edu From: The EDUCAUSE Wireless Issues Constituent Group Listserv On Behalf Of Jason Cook Sent: Thursday, April 12, 2018 3:17 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness If you want to cut straight to flash issues (and a download link for the poller) 54:50 -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: Jason Cook Sent: Thursday, 12 April 2018 3:54 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: RE: [WIRELESS-LAN] More client weirdness That flash bug is annoying, the Cisco software engineers have a script for identifying and fixing some. It doesn’t fix all issues but can at least pre-identify and allow you to manually sort before it becomes an issue. I’ve only just started playing with it. We’ll see if we have any failures at upgrade. We’ve been having a few 2702i’s go down recently while faulty cables are replaced. It’s called wlanpoller, does plenty of other things but since we are doing an upgrade shortly I’ve just started with that. You can ask for it from TAC I got info about this while at Cisco Live Melbourne this year. https://www.ciscolive.com/global/on-demand-library/ Look for “Troubleshooting WLANs - Automating Log Collection and Analysis - BRKEWN-3671” -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Tristan Gulyas Sent: Thursday, 12 April 2018 2:35 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Hi Lee, This is a serious consideration at the moment and would be doing so if we weren't hit by a significant flash corruption bug, which would result in a number of APs failing due to the software change, requiring thousands (and possibly tens of thousands) of contractor dollars to have them replaced since we don't run console cables into our APs, due to the reboot. We'd prefer to only do this once more if we can (i.e. to get away from the flash corruption bug). Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu<mailto:tristan.gul...@monash.edu> monash.edu<http://monash.edu/> On 11 Apr 2018, at 10:25 pm, Lee H Badman mailto:lhbad...@syr.edu>> wrote: Any thoughts of rolling back to older code, rather than living with the issue? Lee Badman | Network Architect Certified Wireless Network Expert (#200) Information Technology Services 206 Machinery Hall 120 Smith Drive Syracuse, New York 13244 t 315.443.3003 f 315.443.4325 e lhbad...@syr.edu<mailto:lhbad...@syr.edu> w its.syr.edu<http://its.syr.edu/> SYRACUSE UN
Re: [WIRELESS-LAN] More client weirdness
On 12 Apr 2018, at 9:17, Jason Cook wrote: If you want to cut straight to flash issues (and a download link for the poller) 54:50 Or just go to page 59 on the PDF/PowerPoint-slides (-: -- Joachim ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
RE: [WIRELESS-LAN] More client weirdness
If you want to cut straight to flash issues (and a download link for the poller) 54:50 -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: Jason Cook Sent: Thursday, 12 April 2018 3:54 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: RE: [WIRELESS-LAN] More client weirdness That flash bug is annoying, the Cisco software engineers have a script for identifying and fixing some. It doesn’t fix all issues but can at least pre-identify and allow you to manually sort before it becomes an issue. I’ve only just started playing with it. We’ll see if we have any failures at upgrade. We’ve been having a few 2702i’s go down recently while faulty cables are replaced. It’s called wlanpoller, does plenty of other things but since we are doing an upgrade shortly I’ve just started with that. You can ask for it from TAC I got info about this while at Cisco Live Melbourne this year. https://www.ciscolive.com/global/on-demand-library/ Look for “Troubleshooting WLANs - Automating Log Collection and Analysis - BRKEWN-3671” -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Tristan Gulyas Sent: Thursday, 12 April 2018 2:35 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Hi Lee, This is a serious consideration at the moment and would be doing so if we weren't hit by a significant flash corruption bug, which would result in a number of APs failing due to the software change, requiring thousands (and possibly tens of thousands) of contractor dollars to have them replaced since we don't run console cables into our APs, due to the reboot. We'd prefer to only do this once more if we can (i.e. to get away from the flash corruption bug). Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu<mailto:tristan.gul...@monash.edu> monash.edu<http://monash.edu/> On 11 Apr 2018, at 10:25 pm, Lee H Badman mailto:lhbad...@syr.edu>> wrote: Any thoughts of rolling back to older code, rather than living with the issue? Lee Badman | Network Architect Certified Wireless Network Expert (#200) Information Technology Services 206 Machinery Hall 120 Smith Drive Syracuse, New York 13244 t 315.443.3003 f 315.443.4325 e lhbad...@syr.edu<mailto:lhbad...@syr.edu> w its.syr.edu<http://its.syr.edu/> SYRACUSE UNIVERSITY syr.edu<http://syr.edu/> From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Tristan Gulyas Sent: Wednesday, April 11, 2018 12:38 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Hi all, We have two TAC cases, one for the Dell 1535 and the other for the general poor connectivity issues. We rebooted one AP yesterday and the customer tells us that their connectivity improved. In another instance, we rebooted an AP and the situation did not improve (in fact, we replaced it - still to no avail). We have over 1800 of these deployed so the impact is widespread. All in local mode. I would be very keen to hear if anyone else would be willin
RE: [WIRELESS-LAN] More client weirdness
That flash bug is annoying, the Cisco software engineers have a script for identifying and fixing some. It doesn’t fix all issues but can at least pre-identify and allow you to manually sort before it becomes an issue. I’ve only just started playing with it. We’ll see if we have any failures at upgrade. We’ve been having a few 2702i’s go down recently while faulty cables are replaced. It’s called wlanpoller, does plenty of other things but since we are doing an upgrade shortly I’ve just started with that. You can ask for it from TAC I got info about this while at Cisco Live Melbourne this year. https://www.ciscolive.com/global/on-demand-library/ Look for “Troubleshooting WLANs - Automating Log Collection and Analysis - BRKEWN-3671” -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: The EDUCAUSE Wireless Issues Constituent Group Listserv On Behalf Of Tristan Gulyas Sent: Thursday, 12 April 2018 2:35 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness Hi Lee, This is a serious consideration at the moment and would be doing so if we weren't hit by a significant flash corruption bug, which would result in a number of APs failing due to the software change, requiring thousands (and possibly tens of thousands) of contractor dollars to have them replaced since we don't run console cables into our APs, due to the reboot. We'd prefer to only do this once more if we can (i.e. to get away from the flash corruption bug). Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu<mailto:tristan.gul...@monash.edu> monash.edu<http://monash.edu/> On 11 Apr 2018, at 10:25 pm, Lee H Badman mailto:lhbad...@syr.edu>> wrote: Any thoughts of rolling back to older code, rather than living with the issue? Lee Badman | Network Architect Certified Wireless Network Expert (#200) Information Technology Services 206 Machinery Hall 120 Smith Drive Syracuse, New York 13244 t 315.443.3003 f 315.443.4325 e lhbad...@syr.edu<mailto:lhbad...@syr.edu> w its.syr.edu<http://its.syr.edu/> SYRACUSE UNIVERSITY syr.edu<http://syr.edu/> From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Tristan Gulyas Sent: Wednesday, April 11, 2018 12:38 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Hi all, We have two TAC cases, one for the Dell 1535 and the other for the general poor connectivity issues. We rebooted one AP yesterday and the customer tells us that their connectivity improved. In another instance, we rebooted an AP and the situation did not improve (in fact, we replaced it - still to no avail). We have over 1800 of these deployed so the impact is widespread. All in local mode. I would be very keen to hear if anyone else would be willing to share TAC case details for any tickets logged to Cisco for this issue. Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu<mailto:tristan.gul...@monash.edu> monash.edu<http://monash.edu/> On 11 Apr 2018, at 9:57 am, Jason Cook mailto:jason.c...@adelaide.edu.au>> wrote: Ours are also local mode. Replication could be challenging, we have 27x 702w’s currently but I’ve only come across 1 confirmed repeat offender. Though some of those are in student accommodation, so I suspect a few of the complaints there could be related. However getting details to troubleshoot are somewhat more challenging there. Anyone worked with TAC or had a bug outside of what Stephen mentioned? I don’t recall seeing those logs when looking at this one. Haven’t been in contact with TAC due to low use/impact vs other work. -- Jason Cook Information Technology and Digital Services The University o
Re: [WIRELESS-LAN] More client weirdness
Hi Lee, This is a serious consideration at the moment and would be doing so if we weren't hit by a significant flash corruption bug, which would result in a number of APs failing due to the software change, requiring thousands (and possibly tens of thousands) of contractor dollars to have them replaced since we don't run console cables into our APs, due to the reboot. We'd prefer to only do this once more if we can (i.e. to get away from the flash corruption bug). Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu <mailto:tristan.gul...@monash.edu> monash.edu <http://monash.edu/> > On 11 Apr 2018, at 10:25 pm, Lee H Badman wrote: > > Any thoughts of rolling back to older code, rather than living with the issue? > > Lee Badman | Network Architect > > Certified Wireless Network Expert (#200) > Information Technology Services > 206 Machinery Hall > 120 Smith Drive > Syracuse, New York 13244 > > t 315.443.3003 f 315.443.4325 e lhbad...@syr.edu > <mailto:lhbad...@syr.edu> w its.syr.edu <http://its.syr.edu/> > SYRACUSE UNIVERSITY > syr.edu <http://syr.edu/> > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Tristan Gulyas > Sent: Wednesday, April 11, 2018 12:38 AM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > Subject: Re: [WIRELESS-LAN] More client weirdness > > Hi all, > > We have two TAC cases, one for the Dell 1535 and the other for the general > poor connectivity issues. > > We rebooted one AP yesterday and the customer tells us that their > connectivity improved. In another instance, we rebooted an AP and the > situation did not improve (in fact, we replaced it - still to no avail). > > We have over 1800 of these deployed so the impact is widespread. All in > local mode. > > I would be very keen to hear if anyone else would be willing to share TAC > case details for any tickets logged to Cisco for this issue. > > Cheers, > Tristan > -- > TRISTAN GULYAS > Senior Network Engineer > > Technology Services, eSolutions > Monash University > 738 Blackburn Road > Clayton 3168 > Australia > > T: +61 3 9902 9092 > M: +61 (0)403 224 484 > E: tristan.gul...@monash.edu <mailto:tristan.gul...@monash.edu> > monash.edu <http://monash.edu/> > > > On 11 Apr 2018, at 9:57 am, Jason Cook <mailto:jason.c...@adelaide.edu.au>> wrote: > > Ours are also local mode. > > Replication could be challenging, we have 27x 702w’s currently but I’ve only > come across 1 confirmed repeat offender. Though some of those are in student > accommodation, so I suspect a few of the complaints there could be related. > However getting details to troubleshoot are somewhat more challenging there. > > Anyone worked with TAC or had a bug outside of what Stephen mentioned? I > don’t recall seeing those logs when looking at this one. Haven’t been in > contact with TAC due to low use/impact vs other work. > > -- > Jason Cook > Information Technology and Digital Services > The University of Adelaide, AUSTRALIA 5005 > Ph: +61 8 8313 4800 > > CRICOS Provider Number 00123M > --- > This email message is intended only for the addressee(s) and contains > information which may be confidential and/or copyright. If you are not the > intended recipient please do not read, save, forward, disclose, or copy the > contents of this email. If this email has been sent to you in error, please > notify the sender by reply email and delete this email and any copies or > links to this email completely and immediately from your system. No > representation is made that this email is free of viruses. Virus scanning is > recommended and is the responsibility of the recipient. > > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Mike Atkins > Sent: Wednesday, 11 April 2018 1:09 AM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > Subject: Re: [WIRELESS-LAN] More client weirdness > > I see thanks. I do not think I’ll have time but if I can I’ll setup a 702W > and see if I can repeat. If I can I’ll try to do an over the air capture. > > > > > > Mike Atkins > Network Engineer > Office of Infor
Re: [WIRELESS-LAN] More client weirdness
Just saw a customer having issues with 702w and Mac clients. Hard to reproduce. Curious if there are active tickets open or if there is a bug ID in progress. Sent from my iPhone > On Apr 11, 2018, at 10:06 AM, Gray, Sean wrote: > > I think I would go down that path if it impacted more clients. The fact that > we are only hearing of this occurring on a very, very small number of clients > and only when they connect to a 702w AP on an 802.1x WLAN makes me unsure if > this is a code or client problem. > > > > Sean Gray | B.Sc (Hons) > Voice, Collaboration & Wireless Network Analyst > ITS, University of Lethbridge > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman > Sent: April-11-18 6:25 AM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: Re: [WIRELESS-LAN] More client weirdness > > Any thoughts of rolling back to older code, rather than living with the issue? > > Lee Badman | Network Architect > > Certified Wireless Network Expert (#200) > Information Technology Services > 206 Machinery Hall > 120 Smith Drive > Syracuse, New York 13244 > > t 315.443.3003 f 315.443.4325 e lhbad...@syr.edu w its.syr.edu > SYRACUSE UNIVERSITY > syr.edu > > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > On Behalf Of Tristan Gulyas > Sent: Wednesday, April 11, 2018 12:38 AM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: Re: [WIRELESS-LAN] More client weirdness > > Hi all, > > We have two TAC cases, one for the Dell 1535 and the other for the general > poor connectivity issues. > > We rebooted one AP yesterday and the customer tells us that their > connectivity improved. In another instance, we rebooted an AP and the > situation did not improve (in fact, we replaced it - still to no avail). > > We have over 1800 of these deployed so the impact is widespread. All in > local mode. > > I would be very keen to hear if anyone else would be willing to share TAC > case details for any tickets logged to Cisco for this issue. > > Cheers, > Tristan > -- > TRISTAN GULYAS > Senior Network Engineer > > Technology Services, eSolutions > Monash University > 738 Blackburn Road > Clayton 3168 > Australia > > T: +61 3 9902 9092 > M: +61 (0)403 224 484 > E: tristan.gul...@monash.edu > monash.edu > > > On 11 Apr 2018, at 9:57 am, Jason Cook wrote: > > Ours are also local mode. > > Replication could be challenging, we have 27x 702w’s currently but I’ve only > come across 1 confirmed repeat offender. Though some of those are in student > accommodation, so I suspect a few of the complaints there could be related. > However getting details to troubleshoot are somewhat more challenging there. > > Anyone worked with TAC or had a bug outside of what Stephen mentioned? I > don’t recall seeing those logs when looking at this one. Haven’t been in > contact with TAC due to low use/impact vs other work. > > -- > Jason Cook > Information Technology and Digital Services > The University of Adelaide, AUSTRALIA 5005 > Ph: +61 8 8313 4800 > > CRICOS Provider Number 00123M > --- > This email message is intended only for the addressee(s) and contains > information which may be confidential and/or copyright. If you are not the > intended recipient please do not read, save, forward, disclose, or copy the > contents of this email. If this email has been sent to you in error, please > notify the sender by reply email and delete this email and any copies or > links to this email completely and immediately from your system. No > representation is made that this email is free of viruses. Virus scanning is > recommended and is the responsibility of the recipient. > > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > On Behalf Of Mike Atkins > Sent: Wednesday, 11 April 2018 1:09 AM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: Re: [WIRELESS-LAN] More client weirdness > > I see thanks. I do not think I’ll have time but if I can I’ll setup a 702W > and see if I can repeat. If I can I’ll try to do an over the air capture. > > > > > > Mike Atkins > Network Engineer > Office of Information Technology > University of Notre Dame > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Gray, Sean > Sent: Tuesday, April 10, 2018 11:20 AM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: Re: [WIRELESS-LAN] More client
RE: [WIRELESS-LAN] More client weirdness
I think I would go down that path if it impacted more clients. The fact that we are only hearing of this occurring on a very, very small number of clients and only when they connect to a 702w AP on an 802.1x WLAN makes me unsure if this is a code or client problem. Sean Gray | B.Sc (Hons) Voice, Collaboration & Wireless Network Analyst ITS, University of Lethbridge From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman Sent: April-11-18 6:25 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness Any thoughts of rolling back to older code, rather than living with the issue? Lee Badman | Network Architect Certified Wireless Network Expert (#200) Information Technology Services 206 Machinery Hall 120 Smith Drive Syracuse, New York 13244 t 315.443.3003 f 315.443.4325 e lhbad...@syr.edu<mailto:lhbad...@syr.edu> w its.syr.edu SYRACUSE UNIVERSITY syr.edu From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Tristan Gulyas Sent: Wednesday, April 11, 2018 12:38 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Hi all, We have two TAC cases, one for the Dell 1535 and the other for the general poor connectivity issues. We rebooted one AP yesterday and the customer tells us that their connectivity improved. In another instance, we rebooted an AP and the situation did not improve (in fact, we replaced it - still to no avail). We have over 1800 of these deployed so the impact is widespread. All in local mode. I would be very keen to hear if anyone else would be willing to share TAC case details for any tickets logged to Cisco for this issue. Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu<mailto:tristan.gul...@monash.edu> monash.edu<http://monash.edu/> On 11 Apr 2018, at 9:57 am, Jason Cook mailto:jason.c...@adelaide.edu.au>> wrote: Ours are also local mode. Replication could be challenging, we have 27x 702w’s currently but I’ve only come across 1 confirmed repeat offender. Though some of those are in student accommodation, so I suspect a few of the complaints there could be related. However getting details to troubleshoot are somewhat more challenging there. Anyone worked with TAC or had a bug outside of what Stephen mentioned? I don’t recall seeing those logs when looking at this one. Haven’t been in contact with TAC due to low use/impact vs other work. -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Mike Atkins Sent: Wednesday, 11 April 2018 1:09 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness I see thanks. I do not think I’ll have time but if I can I’ll setup a 702W and see if I can repeat. If I can I’ll try to do an over the air capture. Mike Atkins Network Engineer Office of Information Technology University of Notre Dame From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of Gray, Sean Sent: Tuesday, April 10, 2018 11:20 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Nope, all of our 702w are in local mode. Sean Gray | B.Sc (Hons) Voice, Collaboration & Wireless Network Analyst ITS, University of Lethbridge From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Mike Atkins Sent: April-10-18 3:54 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness I was just curious,
RE: [WIRELESS-LAN] More client weirdness
Any thoughts of rolling back to older code, rather than living with the issue? Lee Badman | Network Architect Certified Wireless Network Expert (#200) Information Technology Services 206 Machinery Hall 120 Smith Drive Syracuse, New York 13244 t 315.443.3003 f 315.443.4325 e lhbad...@syr.edu<mailto:lhbad...@syr.edu> w its.syr.edu SYRACUSE UNIVERSITY syr.edu From: The EDUCAUSE Wireless Issues Constituent Group Listserv On Behalf Of Tristan Gulyas Sent: Wednesday, April 11, 2018 12:38 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness Hi all, We have two TAC cases, one for the Dell 1535 and the other for the general poor connectivity issues. We rebooted one AP yesterday and the customer tells us that their connectivity improved. In another instance, we rebooted an AP and the situation did not improve (in fact, we replaced it - still to no avail). We have over 1800 of these deployed so the impact is widespread. All in local mode. I would be very keen to hear if anyone else would be willing to share TAC case details for any tickets logged to Cisco for this issue. Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu<mailto:tristan.gul...@monash.edu> monash.edu<http://monash.edu/> On 11 Apr 2018, at 9:57 am, Jason Cook mailto:jason.c...@adelaide.edu.au>> wrote: Ours are also local mode. Replication could be challenging, we have 27x 702w’s currently but I’ve only come across 1 confirmed repeat offender. Though some of those are in student accommodation, so I suspect a few of the complaints there could be related. However getting details to troubleshoot are somewhat more challenging there. Anyone worked with TAC or had a bug outside of what Stephen mentioned? I don’t recall seeing those logs when looking at this one. Haven’t been in contact with TAC due to low use/impact vs other work. -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Mike Atkins Sent: Wednesday, 11 April 2018 1:09 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness I see thanks. I do not think I’ll have time but if I can I’ll setup a 702W and see if I can repeat. If I can I’ll try to do an over the air capture. Mike Atkins Network Engineer Office of Information Technology University of Notre Dame From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of Gray, Sean Sent: Tuesday, April 10, 2018 11:20 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Nope, all of our 702w are in local mode. Sean Gray | B.Sc (Hons) Voice, Collaboration & Wireless Network Analyst ITS, University of Lethbridge From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Mike Atkins Sent: April-10-18 3:54 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness I was just curious, are these 702w APs in flex connect mode? Mike Atkins Network Engineer Office of Information Technology University of Notre Dame . ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
Re: [WIRELESS-LAN] More client weirdness
Hi all, We have two TAC cases, one for the Dell 1535 and the other for the general poor connectivity issues. We rebooted one AP yesterday and the customer tells us that their connectivity improved. In another instance, we rebooted an AP and the situation did not improve (in fact, we replaced it - still to no avail). We have over 1800 of these deployed so the impact is widespread. All in local mode. I would be very keen to hear if anyone else would be willing to share TAC case details for any tickets logged to Cisco for this issue. Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu monash.edu <http://monash.edu/> > On 11 Apr 2018, at 9:57 am, Jason Cook wrote: > > Ours are also local mode. > > Replication could be challenging, we have 27x 702w’s currently but I’ve only > come across 1 confirmed repeat offender. Though some of those are in student > accommodation, so I suspect a few of the complaints there could be related. > However getting details to troubleshoot are somewhat more challenging there. > > Anyone worked with TAC or had a bug outside of what Stephen mentioned? I > don’t recall seeing those logs when looking at this one. Haven’t been in > contact with TAC due to low use/impact vs other work. > > -- > Jason Cook > Information Technology and Digital Services > The University of Adelaide, AUSTRALIA 5005 > Ph: +61 8 8313 4800 > > CRICOS Provider Number 00123M > --- > This email message is intended only for the addressee(s) and contains > information which may be confidential and/or copyright. If you are not the > intended recipient please do not read, save, forward, disclose, or copy the > contents of this email. If this email has been sent to you in error, please > notify the sender by reply email and delete this email and any copies or > links to this email completely and immediately from your system. No > representation is made that this email is free of viruses. Virus scanning is > recommended and is the responsibility of the recipient. > > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Mike Atkins > Sent: Wednesday, 11 April 2018 1:09 AM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > Subject: Re: [WIRELESS-LAN] More client weirdness > > I see thanks. I do not think I’ll have time but if I can I’ll setup a 702W > and see if I can repeat. If I can I’ll try to do an over the air capture. > > > > > > Mike Atkins > Network Engineer > Office of Information Technology > University of Notre Dame > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of Gray, Sean > Sent: Tuesday, April 10, 2018 11:20 AM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > Subject: Re: [WIRELESS-LAN] More client weirdness > > Nope, all of our 702w are in local mode. > > > Sean Gray | B.Sc (Hons) > Voice, Collaboration & Wireless Network Analyst > ITS, University of Lethbridge > > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of Mike Atkins > Sent: April-10-18 3:54 AM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > Subject: Re: [WIRELESS-LAN] More client weirdness > > I was just curious, are these 702w APs in flex connect mode? > > > > > Mike Atkins > Network Engineer > Office of Information Technology > University of Notre Dame > > . > ** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/discuss <http://www.educause.edu/discuss>. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
RE: [WIRELESS-LAN] More client weirdness
Ours are also local mode. Replication could be challenging, we have 27x 702w’s currently but I’ve only come across 1 confirmed repeat offender. Though some of those are in student accommodation, so I suspect a few of the complaints there could be related. However getting details to troubleshoot are somewhat more challenging there. Anyone worked with TAC or had a bug outside of what Stephen mentioned? I don’t recall seeing those logs when looking at this one. Haven’t been in contact with TAC due to low use/impact vs other work. -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: The EDUCAUSE Wireless Issues Constituent Group Listserv On Behalf Of Mike Atkins Sent: Wednesday, 11 April 2018 1:09 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness I see thanks. I do not think I’ll have time but if I can I’ll setup a 702W and see if I can repeat. If I can I’ll try to do an over the air capture. Mike Atkins Network Engineer Office of Information Technology University of Notre Dame From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of Gray, Sean Sent: Tuesday, April 10, 2018 11:20 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Nope, all of our 702w are in local mode. Sean Gray | B.Sc (Hons) Voice, Collaboration & Wireless Network Analyst ITS, University of Lethbridge From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Mike Atkins Sent: April-10-18 3:54 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness I was just curious, are these 702w APs in flex connect mode? Mike Atkins Network Engineer Office of Information Technology University of Notre Dame . ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
RE: [WIRELESS-LAN] More client weirdness
I see thanks. I do not think I’ll have time but if I can I’ll setup a 702W and see if I can repeat. If I can I’ll try to do an over the air capture. *Mike Atkins * Network Engineer Office of Information Technology University of Notre Dame *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Gray, Sean *Sent:* Tuesday, April 10, 2018 11:20 AM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] More client weirdness Nope, all of our 702w are in local mode. *Sean Gray* | B.Sc (Hons) Voice, Collaboration & Wireless Network Analyst ITS, University of Lethbridge *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [ mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU ] *On Behalf Of *Mike Atkins *Sent:* April-10-18 3:54 AM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] More client weirdness I was just curious, are these 702w APs in flex connect mode? *Mike Atkins * Network Engineer Office of Information Technology University of Notre Dame *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Jason Cook *Sent:* Monday, April 09, 2018 7:52 PM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] More client weirdness We also seen the same/similar issues on 702w, however it seems an iPad has been the biggest issue. The user moves down the hall to a 3602i and no worries, moves back to the 702w and it’s a problem. Other devices including her iPhone is fine. Strangely it seems to occur randomly (days or weeks apart), and always the same device. Rebooting the AP will resolve it, or just time! But waiting for resolution could be hours. On 8.2.164.0 -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv < WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Gray, Sean *Sent:* Tuesday, 10 April 2018 12:36 AM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] More client weirdness Hi Tristan, So the problem with the specific student I mentioned seemed to resolve itself. Our latest issue, that seems to again only impact the 702w involves a couple of MacBook Air users, running either Sierra or High Sierra. A debug shows that on occasion when trying to connect to a.1x network they make it as far as the DHCP required state and then never request an IP. They hit the timeout, the WLC deletes the client and the dance begins again. Thanks Sean *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [ mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU ] *On Behalf Of *Tristan Gulyas *Sent:* April-08-18 8:03 PM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] More client weirdness Hi all, We've hit this issue as well. Ever since moving from 8.3.112.7 to 8.3.135.2. What we see: * Devices with the Killer NIC 1535 authenticate but can't pass traffic. * Apple devices will connect, pass traffic for a while, then go dead. We believe we may have seen this on a 1532 series AP as well. Debugs don't seem to give us much. 3702i, 3802i appear to be unaffected. Cheers, Tristan -- *TRISTAN GULYAS* Senior Network Engineer *Technology Services, eSolutions* Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu monash.edu On 1 Feb 2018, at 8:40 am, Gray, Sean wrote: Yep, I noticed this too. Unfortunately we jumped onto 8.3.133.0 prior to the discovering of the catastrophic bug. Hopefully they publically release a fixed version soon. *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [ mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU ] *On Behalf Of *Kitri Waterman *Sent:* January-31-18 1:09 PM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] More client weirdness This sounds like a specific client issue but TAC does have warning out about any 8.3.13x code: https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-tac-rec
RE: [WIRELESS-LAN] More client weirdness
Nope, all of our 702w are in local mode. Sean Gray | B.Sc (Hons) Voice, Collaboration & Wireless Network Analyst ITS, University of Lethbridge From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Mike Atkins Sent: April-10-18 3:54 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness I was just curious, are these 702w APs in flex connect mode? Mike Atkins Network Engineer Office of Information Technology University of Notre Dame From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of Jason Cook Sent: Monday, April 09, 2018 7:52 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness We also seen the same/similar issues on 702w, however it seems an iPad has been the biggest issue. The user moves down the hall to a 3602i and no worries, moves back to the 702w and it’s a problem. Other devices including her iPhone is fine. Strangely it seems to occur randomly (days or weeks apart), and always the same device. Rebooting the AP will resolve it, or just time! But waiting for resolution could be hours. On 8.2.164.0 -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> On Behalf Of Gray, Sean Sent: Tuesday, 10 April 2018 12:36 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Hi Tristan, So the problem with the specific student I mentioned seemed to resolve itself. Our latest issue, that seems to again only impact the 702w involves a couple of MacBook Air users, running either Sierra or High Sierra. A debug shows that on occasion when trying to connect to a.1x network they make it as far as the DHCP required state and then never request an IP. They hit the timeout, the WLC deletes the client and the dance begins again. Thanks Sean From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tristan Gulyas Sent: April-08-18 8:03 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Hi all, We've hit this issue as well. Ever since moving from 8.3.112.7 to 8.3.135.2. What we see: * Devices with the Killer NIC 1535 authenticate but can't pass traffic. * Apple devices will connect, pass traffic for a while, then go dead. We believe we may have seen this on a 1532 series AP as well. Debugs don't seem to give us much. 3702i, 3802i appear to be unaffected. Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu<mailto:tristan.gul...@monash.edu> monash.edu<http://monash.edu/> On 1 Feb 2018, at 8:40 am, Gray, Sean mailto:sean.gr...@uleth.ca>> wrote: Yep, I noticed this too. Unfortunately we jumped onto 8.3.133.0 prior to the discovering of the catastrophic bug. Hopefully they publically release a fixed version soon. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Kitri Waterman Sent: January-31-18 1:09 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness This sounds like a specific client issue but TAC does have warning out about any 8.3.13x code: https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-tac-recommended-aireos.html#anc9 You can request the 8.3.133.10 escalation code and also sign up for the 8.3MR4 Interim code. Best of luck, Kitri Waterman Network Architect/Engineer Enterprise Infrastructure Services (Networks) Western Washington University 360.650.4027 kitri.water...@wwu.edu<mailto:ki
RE: [WIRELESS-LAN] More client weirdness
I was just curious, are these 702w APs in flex connect mode? *Mike Atkins * Network Engineer Office of Information Technology University of Notre Dame *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Jason Cook *Sent:* Monday, April 09, 2018 7:52 PM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] More client weirdness We also seen the same/similar issues on 702w, however it seems an iPad has been the biggest issue. The user moves down the hall to a 3602i and no worries, moves back to the 702w and it’s a problem. Other devices including her iPhone is fine. Strangely it seems to occur randomly (days or weeks apart), and always the same device. Rebooting the AP will resolve it, or just time! But waiting for resolution could be hours. On 8.2.164.0 -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv < WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Gray, Sean *Sent:* Tuesday, 10 April 2018 12:36 AM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] More client weirdness Hi Tristan, So the problem with the specific student I mentioned seemed to resolve itself. Our latest issue, that seems to again only impact the 702w involves a couple of MacBook Air users, running either Sierra or High Sierra. A debug shows that on occasion when trying to connect to a.1x network they make it as far as the DHCP required state and then never request an IP. They hit the timeout, the WLC deletes the client and the dance begins again. Thanks Sean *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [ mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU ] *On Behalf Of *Tristan Gulyas *Sent:* April-08-18 8:03 PM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] More client weirdness Hi all, We've hit this issue as well. Ever since moving from 8.3.112.7 to 8.3.135.2. What we see: * Devices with the Killer NIC 1535 authenticate but can't pass traffic. * Apple devices will connect, pass traffic for a while, then go dead. We believe we may have seen this on a 1532 series AP as well. Debugs don't seem to give us much. 3702i, 3802i appear to be unaffected. Cheers, Tristan -- *TRISTAN GULYAS* Senior Network Engineer *Technology Services, eSolutions* Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu monash.edu On 1 Feb 2018, at 8:40 am, Gray, Sean wrote: Yep, I noticed this too. Unfortunately we jumped onto 8.3.133.0 prior to the discovering of the catastrophic bug. Hopefully they publically release a fixed version soon. *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [ mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU ] *On Behalf Of *Kitri Waterman *Sent:* January-31-18 1:09 PM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] More client weirdness This sounds like a specific client issue but TAC does have warning out about any 8.3.13x code: https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-tac-recommended-aireos.html#anc9 You can request the 8.3.133.10 escalation code and also sign up for the 8.3MR4 Interim code. Best of luck, Kitri Waterman Network Architect/Engineer Enterprise Infrastructure Services (Networks) Western Washington University 360.650.4027 kitri.water...@wwu.edu *From: *The EDUCAUSE Wireless Issues Constituent Group Listserv < WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of "Gray, Sean" < sean.gr...@uleth.ca> *Reply-To: *The EDUCAUSE Wireless Issues Constituent Group Listserv < WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *Date: *Wednesday, January 31, 2018 at 10:34 AM *To: *"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" < WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *Subject: *Re: [WIRELESS-LAN] More client weirdness Hi Craig, Sorry I should have mentioned that, our WLC is a 5520 running 8.3.133.0 code Sean *From:* The EDUCAUSE Wireless Issues Constituent Group Lis
Re: [WIRELESS-LAN] More client weirdness
Hi all, Sounds like the same issue we're seeing. There seems to be an intermittent spread of devices. Anything from devices not receiving DHCP to devices remaining connected for 5-10 minutes and then ceasing to pass traffic any further. Today's request was from two users with iPhone X devices, but her MacBook Pro works fine on the same AP. I can confirm the Dell laptops with Killer 1535s are still an issue. I attempted a replacement of one 702W and the issue returned straight away, so we're confident it's not hardware. We use AAA-Override for interface-name but we don't do CoA after auth. Thanks all - this has been a *huge* help. Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu monash.edu <http://monash.edu/> > On 10 Apr 2018, at 9:52 am, Jason Cook wrote: > > We also seen the same/similar issues on 702w, however it seems an iPad has > been the biggest issue. The user moves down the hall to a 3602i and no > worries, moves back to the 702w and it’s a problem. Other devices including > her iPhone is fine. Strangely it seems to occur randomly (days or weeks > apart), and always the same device. Rebooting the AP will resolve it, or just > time! But waiting for resolution could be hours. > > On 8.2.164.0 > > -- > Jason Cook > Information Technology and Digital Services > The University of Adelaide, AUSTRALIA 5005 > Ph: +61 8 8313 4800 > > CRICOS Provider Number 00123M > --- > This email message is intended only for the addressee(s) and contains > information which may be confidential and/or copyright. If you are not the > intended recipient please do not read, save, forward, disclose, or copy the > contents of this email. If this email has been sent to you in error, please > notify the sender by reply email and delete this email and any copies or > links to this email completely and immediately from your system. No > representation is made that this email is free of viruses. Virus scanning is > recommended and is the responsibility of the recipient. > > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > On Behalf Of Gray, Sean > Sent: Tuesday, 10 April 2018 12:36 AM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: Re: [WIRELESS-LAN] More client weirdness > > Hi Tristan, > > So the problem with the specific student I mentioned seemed to resolve > itself. Our latest issue, that seems to again only impact the 702w involves > a couple of MacBook Air users, running either Sierra or High Sierra. A debug > shows that on occasion when trying to connect to a.1x network they make it as > far as the DHCP required state and then never request an IP. They hit the > timeout, the WLC deletes the client and the dance begins again. > > Thanks > > Sean > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of Tristan Gulyas > Sent: April-08-18 8:03 PM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > Subject: Re: [WIRELESS-LAN] More client weirdness > > Hi all, > > We've hit this issue as well. Ever since moving from 8.3.112.7 to 8.3.135.2. > > What we see: > > * Devices with the Killer NIC 1535 authenticate but can't pass traffic. > * Apple devices will connect, pass traffic for a while, then go dead. > > We believe we may have seen this on a 1532 series AP as well. > > Debugs don't seem to give us much. > > 3702i, 3802i appear to be unaffected. > > Cheers, > Tristan > -- > TRISTAN GULYAS > Senior Network Engineer > > Technology Services, eSolutions > Monash University > 738 Blackburn Road > Clayton 3168 > Australia > > T: +61 3 9902 9092 > M: +61 (0)403 224 484 > E: tristan.gul...@monash.edu <mailto:tristan.gul...@monash.edu> > monash.edu <http://monash.edu/> > > On 1 Feb 2018, at 8:40 am, Gray, Sean <mailto:sean.gr...@uleth.ca>> wrote: > > Yep, I noticed this too. Unfortunately we jumped onto 8.3.133.0 prior to the > discovering of the catastrophic bug. Hopefully they publically release a > fixed version soon. > > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of Kitri Waterman > Sent: January-31-18 1:09 PM &g
RE: [WIRELESS-LAN] More client weirdness
We also seen the same/similar issues on 702w, however it seems an iPad has been the biggest issue. The user moves down the hall to a 3602i and no worries, moves back to the 702w and it’s a problem. Other devices including her iPhone is fine. Strangely it seems to occur randomly (days or weeks apart), and always the same device. Rebooting the AP will resolve it, or just time! But waiting for resolution could be hours. On 8.2.164.0 -- Jason Cook Information Technology and Digital Services The University of Adelaide, AUSTRALIA 5005 Ph: +61 8 8313 4800 CRICOS Provider Number 00123M --- This email message is intended only for the addressee(s) and contains information which may be confidential and/or copyright. If you are not the intended recipient please do not read, save, forward, disclose, or copy the contents of this email. If this email has been sent to you in error, please notify the sender by reply email and delete this email and any copies or links to this email completely and immediately from your system. No representation is made that this email is free of viruses. Virus scanning is recommended and is the responsibility of the recipient. From: The EDUCAUSE Wireless Issues Constituent Group Listserv On Behalf Of Gray, Sean Sent: Tuesday, 10 April 2018 12:36 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness Hi Tristan, So the problem with the specific student I mentioned seemed to resolve itself. Our latest issue, that seems to again only impact the 702w involves a couple of MacBook Air users, running either Sierra or High Sierra. A debug shows that on occasion when trying to connect to a.1x network they make it as far as the DHCP required state and then never request an IP. They hit the timeout, the WLC deletes the client and the dance begins again. Thanks Sean From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tristan Gulyas Sent: April-08-18 8:03 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Hi all, We've hit this issue as well. Ever since moving from 8.3.112.7 to 8.3.135.2. What we see: * Devices with the Killer NIC 1535 authenticate but can't pass traffic. * Apple devices will connect, pass traffic for a while, then go dead. We believe we may have seen this on a 1532 series AP as well. Debugs don't seem to give us much. 3702i, 3802i appear to be unaffected. Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu<mailto:tristan.gul...@monash.edu> monash.edu<http://monash.edu/> On 1 Feb 2018, at 8:40 am, Gray, Sean mailto:sean.gr...@uleth.ca>> wrote: Yep, I noticed this too. Unfortunately we jumped onto 8.3.133.0 prior to the discovering of the catastrophic bug. Hopefully they publically release a fixed version soon. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Kitri Waterman Sent: January-31-18 1:09 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness This sounds like a specific client issue but TAC does have warning out about any 8.3.13x code: https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-tac-recommended-aireos.html#anc9 You can request the 8.3.133.10 escalation code and also sign up for the 8.3MR4 Interim code. Best of luck, Kitri Waterman Network Architect/Engineer Enterprise Infrastructure Services (Networks) Western Washington University 360.650.4027 kitri.water...@wwu.edu<mailto:kitri.water...@wwu.edu> From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> on behalf of "Gray, Sean" mailto:sean.gr...@uleth.ca>> Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> Date: Wednesday, January 31, 2018 at 10:34 AM To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> Subject: Re: [WIRELESS-LAN] More client weirdness Hi Craig, Sorry I should have mentioned that, our WLC is a 5520 running 8.3.133.0 code Sean From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Craig Eyre Sent: January-31-18 11:30 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Sean, What version of cont
RE: [WIRELESS-LAN] More client weirdness
Sounds like the code is just plain buggy. Let me know if the 702w swap fixes the issue. For reference, here is the specific bug we ran into: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvi84734/?rfs=iqvred *Apr 4 00:46:45.487: decrypt err vlan 1 num 1 key 989AECF64E247F028x dest vlan 0 cl 0 pakv 0 *Apr 4 00:46:45.487: Client: 3052.cbea.2be7 KT: 200 DE-0 D-180 S-112 aid 14 *Apr 4 00:46:45.487: decrypt err vlan 1 num 1 key 989AECF64E247F028x dest vlan 0 cl 0 pakv 0 *Apr 4 00:46:45.487: Client: 3052.cbea.2be7 KT: 200 DE-0 D-180 S-112 aid 14 *Apr 4 00:46:45.671: decrypt err vlan 1 num 1 key 989AECF64E247F028x dest vlan 0 cl 0 pakv 0 *Apr 4 00:46:45.671: Client: 3052.cbea.2be7 KT: 200 DE-0 D-180 S-66 aid 14 Steve / Stephen Belcher Assistant Director of Network Operations WVU Information Technology Services (681) 214-3389 mobile From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Gray, Sean Sent: Monday, April 9, 2018 11:14 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness Hi Stephen, I just replied to Tristan with the following – “So the problem with the specific student I mentioned seemed to resolve itself. Our latest issue, that seems to again only impact the 702w involves a couple of MacBook Air users, running either Sierra or High Sierra. A debug shows that on occasion when trying to connect to a.1x network they make it as far as the DHCP required state and then never request an IP. They hit the timeout, the WLC deletes the client and the dance begins again.” So unless the students aren’t complaining and choosing to use our Guest network in the limited areas where 702ws are installed, our issue is now isolated to MacBook Airs connecting to .1x networks via a 702w AP. On the plus side we don’t have “Allow AAA Override enabled” on our Student WLAN, so at least we know that isn’t part of the problem. As this seems to be a severely isolated issue our next move will be to swap out the 702w in the area reporting problems. Thanks Sean From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Stephen Belcher Sent: April-09-18 6:31 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness We hit the same bug on 8.3.133.0 code. After running a debug code on the 702w (and with the help of a very nice student), Cisco determined it was change of auth that was causing the issue. We disabled “Allow AAA Override” on the WLAN which seems to have mitigated the issue. Fortunately, we aren’t using the AAA Override at this time. Cisco hasn’t sent us a bug number and it’s not showing in the open Caveats yet. If I get more info from Cisco I will send it to the group. Let me know if you have any questions. Steve / Stephen Belcher Assistant Director of Network Operations WVU Information Technology Services (681) 214-3389 mobile From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tristan Gulyas Sent: Sunday, April 8, 2018 10:03 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Hi all, We've hit this issue as well. Ever since moving from 8.3.112.7 to 8.3.135.2. What we see: * Devices with the Killer NIC 1535 authenticate but can't pass traffic. * Apple devices will connect, pass traffic for a while, then go dead. We believe we may have seen this on a 1532 series AP as well. Debugs don't seem to give us much. 3702i, 3802i appear to be unaffected. Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu<mailto:tristan.gul...@monash.edu> monash.edu<http://monash.edu/> On 1 Feb 2018, at 8:40 am, Gray, Sean mailto:sean.gr...@uleth.ca>> wrote: Yep, I noticed this too. Unfortunately we jumped onto 8.3.133.0 prior to the discovering of the catastrophic bug. Hopefully they publically release a fixed version soon. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Kitri Waterman Sent: January-31-18 1:09 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness This sounds like a specific client issue but TAC does have warning out about any 8.3.13x code: https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-tac-recommended-aireos.html#anc9 You can request the 8.3.133.10 escalation code and also sign up for the 8.3MR4 Interim code. Best of luck, Kitri Waterman Network Architect/En
RE: [WIRELESS-LAN] More client weirdness
Hi Stephen, I just replied to Tristan with the following – “So the problem with the specific student I mentioned seemed to resolve itself. Our latest issue, that seems to again only impact the 702w involves a couple of MacBook Air users, running either Sierra or High Sierra. A debug shows that on occasion when trying to connect to a.1x network they make it as far as the DHCP required state and then never request an IP. They hit the timeout, the WLC deletes the client and the dance begins again.” So unless the students aren’t complaining and choosing to use our Guest network in the limited areas where 702ws are installed, our issue is now isolated to MacBook Airs connecting to .1x networks via a 702w AP. On the plus side we don’t have “Allow AAA Override enabled” on our Student WLAN, so at least we know that isn’t part of the problem. As this seems to be a severely isolated issue our next move will be to swap out the 702w in the area reporting problems. Thanks Sean From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Stephen Belcher Sent: April-09-18 6:31 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness We hit the same bug on 8.3.133.0 code. After running a debug code on the 702w (and with the help of a very nice student), Cisco determined it was change of auth that was causing the issue. We disabled “Allow AAA Override” on the WLAN which seems to have mitigated the issue. Fortunately, we aren’t using the AAA Override at this time. Cisco hasn’t sent us a bug number and it’s not showing in the open Caveats yet. If I get more info from Cisco I will send it to the group. Let me know if you have any questions. Steve / Stephen Belcher Assistant Director of Network Operations WVU Information Technology Services (681) 214-3389 mobile From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tristan Gulyas Sent: Sunday, April 8, 2018 10:03 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Hi all, We've hit this issue as well. Ever since moving from 8.3.112.7 to 8.3.135.2. What we see: * Devices with the Killer NIC 1535 authenticate but can't pass traffic. * Apple devices will connect, pass traffic for a while, then go dead. We believe we may have seen this on a 1532 series AP as well. Debugs don't seem to give us much. 3702i, 3802i appear to be unaffected. Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu<mailto:tristan.gul...@monash.edu> monash.edu<http://monash.edu/> On 1 Feb 2018, at 8:40 am, Gray, Sean mailto:sean.gr...@uleth.ca>> wrote: Yep, I noticed this too. Unfortunately we jumped onto 8.3.133.0 prior to the discovering of the catastrophic bug. Hopefully they publically release a fixed version soon. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Kitri Waterman Sent: January-31-18 1:09 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness This sounds like a specific client issue but TAC does have warning out about any 8.3.13x code: https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-tac-recommended-aireos.html#anc9 You can request the 8.3.133.10 escalation code and also sign up for the 8.3MR4 Interim code. Best of luck, Kitri Waterman Network Architect/Engineer Enterprise Infrastructure Services (Networks) Western Washington University 360.650.4027 kitri.water...@wwu.edu<mailto:kitri.water...@wwu.edu> From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> on behalf of "Gray, Sean" mailto:sean.gr...@uleth.ca>> Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> Date: Wednesday, January 31, 2018 at 10:34 AM To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> Subject: Re: [WIRELESS-LAN] More client weirdness Hi Craig, Sorry I should have mentioned that, our WLC is a 5520 running 8.3.133.0 code Sean From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Craig Eyre Sent: January-31-18 11:30 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Sean, What version of controller software are you running?
RE: [WIRELESS-LAN] More client weirdness
Hi Tristan, So the problem with the specific student I mentioned seemed to resolve itself. Our latest issue, that seems to again only impact the 702w involves a couple of MacBook Air users, running either Sierra or High Sierra. A debug shows that on occasion when trying to connect to a.1x network they make it as far as the DHCP required state and then never request an IP. They hit the timeout, the WLC deletes the client and the dance begins again. Thanks Sean From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tristan Gulyas Sent: April-08-18 8:03 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness Hi all, We've hit this issue as well. Ever since moving from 8.3.112.7 to 8.3.135.2. What we see: * Devices with the Killer NIC 1535 authenticate but can't pass traffic. * Apple devices will connect, pass traffic for a while, then go dead. We believe we may have seen this on a 1532 series AP as well. Debugs don't seem to give us much. 3702i, 3802i appear to be unaffected. Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu<mailto:tristan.gul...@monash.edu> monash.edu<http://monash.edu/> On 1 Feb 2018, at 8:40 am, Gray, Sean mailto:sean.gr...@uleth.ca>> wrote: Yep, I noticed this too. Unfortunately we jumped onto 8.3.133.0 prior to the discovering of the catastrophic bug. Hopefully they publically release a fixed version soon. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Kitri Waterman Sent: January-31-18 1:09 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness This sounds like a specific client issue but TAC does have warning out about any 8.3.13x code: https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-tac-recommended-aireos.html#anc9 You can request the 8.3.133.10 escalation code and also sign up for the 8.3MR4 Interim code. Best of luck, Kitri Waterman Network Architect/Engineer Enterprise Infrastructure Services (Networks) Western Washington University 360.650.4027 kitri.water...@wwu.edu<mailto:kitri.water...@wwu.edu> From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> on behalf of "Gray, Sean" mailto:sean.gr...@uleth.ca>> Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> Date: Wednesday, January 31, 2018 at 10:34 AM To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> Subject: Re: [WIRELESS-LAN] More client weirdness Hi Craig, Sorry I should have mentioned that, our WLC is a 5520 running 8.3.133.0 code Sean From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Craig Eyre Sent: January-31-18 11:30 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Sean, What version of controller software are you running? Craig Eyre On Wed, Jan 31, 2018 at 11:17 AM, Gray, Sean mailto:sean.gr...@uleth.ca>> wrote: Hi Everyone, I just wanted to throw this weirdness out to the group to see if anyone has experienced the same issue and has found a solution or work around. We have a student on campus who intermittently cannot connect to our 802.1x Student WLAN when trying to connect to a Cisco 702w access point installed nearby. They can connect to our open Guest WLAN. I should say that they are fail to connect to Student more times than they succeed when in their Student Residence. On campus they are able to connect to Student. I recently brought them down to my office to have them try and connect to a 702w that I had set up specially for the purpose of this test. Client Details: • Acer Aspire F5-571T Laptop • NIC: Qualcomm Atheros QCA9377 • Driver Version 12.0.0.309 • O/S: Windows 10 Home Client has Symantec Anti-virus installed Windows updates and driver versions were all validated. During testing I noticed that the client completes the AUTH phase and enters RUN state. At this point it frequently seems to stall and doesn’t make it into the DHCP Socket Task portion of the client/WLC/DHCP exchange. The only thing that the testing proved to me is that the client doesn’t like Cisco 702w APs, as I saw the same results in my office as I saw from them in Student Residence. Of note is that the problem seems to become partic
RE: [WIRELESS-LAN] More client weirdness
We hit the same bug on 8.3.133.0 code. After running a debug code on the 702w (and with the help of a very nice student), Cisco determined it was change of auth that was causing the issue. We disabled “Allow AAA Override” on the WLAN which seems to have mitigated the issue. Fortunately, we aren’t using the AAA Override at this time. Cisco hasn’t sent us a bug number and it’s not showing in the open Caveats yet. If I get more info from Cisco I will send it to the group. Let me know if you have any questions. Steve / Stephen Belcher Assistant Director of Network Operations WVU Information Technology Services (681) 214-3389 mobile From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tristan Gulyas Sent: Sunday, April 8, 2018 10:03 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness Hi all, We've hit this issue as well. Ever since moving from 8.3.112.7 to 8.3.135.2. What we see: * Devices with the Killer NIC 1535 authenticate but can't pass traffic. * Apple devices will connect, pass traffic for a while, then go dead. We believe we may have seen this on a 1532 series AP as well. Debugs don't seem to give us much. 3702i, 3802i appear to be unaffected. Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu<mailto:tristan.gul...@monash.edu> monash.edu<http://monash.edu/> On 1 Feb 2018, at 8:40 am, Gray, Sean mailto:sean.gr...@uleth.ca>> wrote: Yep, I noticed this too. Unfortunately we jumped onto 8.3.133.0 prior to the discovering of the catastrophic bug. Hopefully they publically release a fixed version soon. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Kitri Waterman Sent: January-31-18 1:09 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness This sounds like a specific client issue but TAC does have warning out about any 8.3.13x code: https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-tac-recommended-aireos.html#anc9 You can request the 8.3.133.10 escalation code and also sign up for the 8.3MR4 Interim code. Best of luck, Kitri Waterman Network Architect/Engineer Enterprise Infrastructure Services (Networks) Western Washington University 360.650.4027 kitri.water...@wwu.edu<mailto:kitri.water...@wwu.edu> From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> on behalf of "Gray, Sean" mailto:sean.gr...@uleth.ca>> Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> Date: Wednesday, January 31, 2018 at 10:34 AM To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> Subject: Re: [WIRELESS-LAN] More client weirdness Hi Craig, Sorry I should have mentioned that, our WLC is a 5520 running 8.3.133.0 code Sean From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Craig Eyre Sent: January-31-18 11:30 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Sean, What version of controller software are you running? Craig Eyre On Wed, Jan 31, 2018 at 11:17 AM, Gray, Sean mailto:sean.gr...@uleth.ca>> wrote: Hi Everyone, I just wanted to throw this weirdness out to the group to see if anyone has experienced the same issue and has found a solution or work around. We have a student on campus who intermittently cannot connect to our 802.1x Student WLAN when trying to connect to a Cisco 702w access point installed nearby. They can connect to our open Guest WLAN. I should say that they are fail to connect to Student more times than they succeed when in their Student Residence. On campus they are able to connect to Student. I recently brought them down to my office to have them try and connect to a 702w that I had set up specially for the purpose of this test. Client Details: • Acer Aspire F5-571T Laptop • NIC: Qualcomm Atheros QCA9377 • Driver Version 12.0.0.309 • O/S: Windows 10 Home Client has Symantec Anti-virus installed Windows updates and driver versions were all validated. During testing I noticed that the client completes the AUTH phase and enters RUN state. At this point it frequently seems to stall and doesn’t make it into the DHCP Socket Task portion of the client/WLC/DHCP exchange. The only thing that the testing proved
Re: [WIRELESS-LAN] More client weirdness
Hi all, We've hit this issue as well. Ever since moving from 8.3.112.7 to 8.3.135.2. What we see: * Devices with the Killer NIC 1535 authenticate but can't pass traffic. * Apple devices will connect, pass traffic for a while, then go dead. We believe we may have seen this on a 1532 series AP as well. Debugs don't seem to give us much. 3702i, 3802i appear to be unaffected. Cheers, Tristan -- TRISTAN GULYAS Senior Network Engineer Technology Services, eSolutions Monash University 738 Blackburn Road Clayton 3168 Australia T: +61 3 9902 9092 M: +61 (0)403 224 484 E: tristan.gul...@monash.edu <mailto:tristan.gul...@monash.edu> monash.edu <http://monash.edu/> > On 1 Feb 2018, at 8:40 am, Gray, Sean wrote: > > Yep, I noticed this too. Unfortunately we jumped onto 8.3.133.0 prior to the > discovering of the catastrophic bug. Hopefully they publically release a > fixed version soon. > > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of Kitri Waterman > Sent: January-31-18 1:09 PM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > Subject: Re: [WIRELESS-LAN] More client weirdness > > This sounds like a specific client issue but TAC does have warning out about > any 8.3.13x code: > https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-tac-recommended-aireos.html#anc9 > > <https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-tac-recommended-aireos.html#anc9> > > You can request the 8.3.133.10 escalation code and also sign up for the > 8.3MR4 Interim code. > > Best of luck, > > Kitri Waterman > Network Architect/Engineer > Enterprise Infrastructure Services (Networks) > Western Washington University > 360.650.4027 > kitri.water...@wwu.edu <mailto:kitri.water...@wwu.edu> > > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> on behalf of "Gray, Sean" > mailto:sean.gr...@uleth.ca>> > Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> > Date: Wednesday, January 31, 2018 at 10:34 AM > To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> > Subject: Re: [WIRELESS-LAN] More client weirdness > > Hi Craig, <> > > Sorry I should have mentioned that, our WLC is a 5520 running 8.3.133.0 code > > Sean > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of Craig Eyre > Sent: January-31-18 11:30 AM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > Subject: Re: [WIRELESS-LAN] More client weirdness > > Sean, > > > What version of controller software are you running? > > > Craig Eyre > > On Wed, Jan 31, 2018 at 11:17 AM, Gray, Sean <mailto:sean.gr...@uleth.ca>> wrote: > Hi Everyone, > > I just wanted to throw this weirdness out to the group to see if anyone has > experienced the same issue and has found a solution or work around. > > We have a student on campus who intermittently cannot connect to our 802.1x > Student WLAN when trying to connect to a Cisco 702w access point installed > nearby. They can connect to our open Guest WLAN. I should say that they are > fail to connect to Student more times than they succeed when in their Student > Residence. On campus they are able to connect to Student. > > I recently brought them down to my office to have them try and connect to a > 702w that I had set up specially for the purpose of this test. > > Client Details: > > · Acer Aspire F5-571T Laptop > > · NIC: Qualcomm Atheros QCA9377 > > · Driver Version 12.0.0.309 > > · O/S: Windows 10 Home > > > Client has Symantec Anti-virus installed > > Windows updates and driver versions were all validated. > > > During testing I noticed that the client completes the AUTH phase and enters > RUN state. At this point it frequently seems to stall and doesn’t make it > into the DHCP Socket Task portion of the client/WLC/DHCP exchange. > > The only thing that the testing proved to me is that the client doesn’t like > Cisco 702w APs, as I saw the same results in my offic
RE: [WIRELESS-LAN] More client weirdness
Yep, I noticed this too. Unfortunately we jumped onto 8.3.133.0 prior to the discovering of the catastrophic bug. Hopefully they publically release a fixed version soon. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Kitri Waterman Sent: January-31-18 1:09 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness This sounds like a specific client issue but TAC does have warning out about any 8.3.13x code: https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-tac-recommended-aireos.html#anc9 You can request the 8.3.133.10 escalation code and also sign up for the 8.3MR4 Interim code. Best of luck, Kitri Waterman Network Architect/Engineer Enterprise Infrastructure Services (Networks) Western Washington University 360.650.4027 kitri.water...@wwu.edu<mailto:kitri.water...@wwu.edu> From: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> on behalf of "Gray, Sean" mailto:sean.gr...@uleth.ca>> Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> Date: Wednesday, January 31, 2018 at 10:34 AM To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> Subject: Re: [WIRELESS-LAN] More client weirdness Hi Craig, Sorry I should have mentioned that, our WLC is a 5520 running 8.3.133.0 code Sean From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Craig Eyre Sent: January-31-18 11:30 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Sean, What version of controller software are you running? Craig Eyre On Wed, Jan 31, 2018 at 11:17 AM, Gray, Sean mailto:sean.gr...@uleth.ca>> wrote: Hi Everyone, I just wanted to throw this weirdness out to the group to see if anyone has experienced the same issue and has found a solution or work around. We have a student on campus who intermittently cannot connect to our 802.1x Student WLAN when trying to connect to a Cisco 702w access point installed nearby. They can connect to our open Guest WLAN. I should say that they are fail to connect to Student more times than they succeed when in their Student Residence. On campus they are able to connect to Student. I recently brought them down to my office to have them try and connect to a 702w that I had set up specially for the purpose of this test. Client Details: • Acer Aspire F5-571T Laptop • NIC: Qualcomm Atheros QCA9377 • Driver Version 12.0.0.309 • O/S: Windows 10 Home Client has Symantec Anti-virus installed Windows updates and driver versions were all validated. During testing I noticed that the client completes the AUTH phase and enters RUN state. At this point it frequently seems to stall and doesn’t make it into the DHCP Socket Task portion of the client/WLC/DHCP exchange. The only thing that the testing proved to me is that the client doesn’t like Cisco 702w APs, as I saw the same results in my office as I saw from them in Student Residence. Of note is that the problem seems to become particular pronounce when they roam from Guest to Student or vice versa. Disabling the Symantec firewall seemed to improve, but not fully resolve the issue. I should also point out that due to the unique way that our Residence townhomes were constructed wall mount APs are our only option. So this one has me beat! Thanks Sean ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. -- Craig Eyre Network Analyst IT Services Department Mount Royal University 4825 Mount Royal Gate SW Calgary AB T2P 3T5 P. 403.440.5199 E. ce...@mtroyal.ca<mailto:ce...@mtroyal.ca> "The difference between a successful person and others is not a lack of strength, not a lack of knowledge, but rather in a lack of will." Vincent T. Lombardi" MRU IT Services will NEVER ask you for your password or to update or verify your email account through an email. DO NOT click any links in an email asking you to update or verify your email account. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ** Participation
RE: [WIRELESS-LAN] More client weirdness
Hi Brahim, This is a great resource and something that I already use to help me translate the debugs when troubleshooting issues like this. Thanks Sean From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brahim Bouchaiba Sent: January-31-18 11:41 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness Hi, Can you run debug client < mac address> then parse it here: https://cway.cisco.com/tools/WirelessDebugAnalyzer/ On Wed, Jan 31, 2018 at 1:34 PM, Gray, Sean mailto:sean.gr...@uleth.ca>> wrote: Hi Craig, Sorry I should have mentioned that, our WLC is a 5520 running 8.3.133.0 code Sean From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of Craig Eyre Sent: January-31-18 11:30 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] More client weirdness Sean, What version of controller software are you running? Craig Eyre On Wed, Jan 31, 2018 at 11:17 AM, Gray, Sean mailto:sean.gr...@uleth.ca>> wrote: Hi Everyone, I just wanted to throw this weirdness out to the group to see if anyone has experienced the same issue and has found a solution or work around. We have a student on campus who intermittently cannot connect to our 802.1x Student WLAN when trying to connect to a Cisco 702w access point installed nearby. They can connect to our open Guest WLAN. I should say that they are fail to connect to Student more times than they succeed when in their Student Residence. On campus they are able to connect to Student. I recently brought them down to my office to have them try and connect to a 702w that I had set up specially for the purpose of this test. Client Details: • Acer Aspire F5-571T Laptop • NIC: Qualcomm Atheros QCA9377 • Driver Version 12.0.0.309 • O/S: Windows 10 Home Client has Symantec Anti-virus installed Windows updates and driver versions were all validated. During testing I noticed that the client completes the AUTH phase and enters RUN state. At this point it frequently seems to stall and doesn’t make it into the DHCP Socket Task portion of the client/WLC/DHCP exchange. The only thing that the testing proved to me is that the client doesn’t like Cisco 702w APs, as I saw the same results in my office as I saw from them in Student Residence. Of note is that the problem seems to become particular pronounce when they roam from Guest to Student or vice versa. Disabling the Symantec firewall seemed to improve, but not fully resolve the issue. I should also point out that due to the unique way that our Residence townhomes were constructed wall mount APs are our only option. So this one has me beat! Thanks Sean ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. -- Craig Eyre Network Analyst IT Services Department Mount Royal University 4825 Mount Royal Gate SW<https://maps.google.com/?q=4825+Mount+Royal+Gate+SW+%0D+Calgary+AB+T2P+3T5&entry=gmail&source=g> Calgary AB T2P 3T5 P. 403.440.5199 E. ce...@mtroyal.ca<mailto:ce...@mtroyal.ca> "The difference between a successful person and others is not a lack of strength, not a lack of knowledge, but rather in a lack of will." Vincent T. Lombardi" MRU IT Services will NEVER ask you for your password or to update or verify your email account through an email. DO NOT click any links in an email asking you to update or verify your email account. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
Re: [WIRELESS-LAN] More client weirdness
This sounds like a specific client issue but TAC does have warning out about any 8.3.13x code: https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-tac-recommended-aireos.html#anc9 You can request the 8.3.133.10 escalation code and also sign up for the 8.3MR4 Interim code. Best of luck, Kitri Waterman Network Architect/Engineer Enterprise Infrastructure Services (Networks) Western Washington University 360.650.4027 kitri.water...@wwu.edu From: The EDUCAUSE Wireless Issues Constituent Group Listserv on behalf of "Gray, Sean" Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv Date: Wednesday, January 31, 2018 at 10:34 AM To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" Subject: Re: [WIRELESS-LAN] More client weirdness Hi Craig, Sorry I should have mentioned that, our WLC is a 5520 running 8.3.133.0 code Sean From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Craig Eyre Sent: January-31-18 11:30 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness Sean, What version of controller software are you running? Craig Eyre On Wed, Jan 31, 2018 at 11:17 AM, Gray, Sean mailto:sean.gr...@uleth.ca>> wrote: Hi Everyone, I just wanted to throw this weirdness out to the group to see if anyone has experienced the same issue and has found a solution or work around. We have a student on campus who intermittently cannot connect to our 802.1x Student WLAN when trying to connect to a Cisco 702w access point installed nearby. They can connect to our open Guest WLAN. I should say that they are fail to connect to Student more times than they succeed when in their Student Residence. On campus they are able to connect to Student. I recently brought them down to my office to have them try and connect to a 702w that I had set up specially for the purpose of this test. Client Details: • Acer Aspire F5-571T Laptop • NIC: Qualcomm Atheros QCA9377 • Driver Version 12.0.0.309 • O/S: Windows 10 Home Client has Symantec Anti-virus installed Windows updates and driver versions were all validated. During testing I noticed that the client completes the AUTH phase and enters RUN state. At this point it frequently seems to stall and doesn’t make it into the DHCP Socket Task portion of the client/WLC/DHCP exchange. The only thing that the testing proved to me is that the client doesn’t like Cisco 702w APs, as I saw the same results in my office as I saw from them in Student Residence. Of note is that the problem seems to become particular pronounce when they roam from Guest to Student or vice versa. Disabling the Symantec firewall seemed to improve, but not fully resolve the issue. I should also point out that due to the unique way that our Residence townhomes were constructed wall mount APs are our only option. So this one has me beat! Thanks Sean ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. -- Craig Eyre Network Analyst IT Services Department Mount Royal University 4825 Mount Royal Gate SW Calgary AB T2P 3T5 P. 403.440.5199 E. ce...@mtroyal.ca<mailto:ce...@mtroyal.ca> "The difference between a successful person and others is not a lack of strength, not a lack of knowledge, but rather in a lack of will." Vincent T. Lombardi" MRU IT Services will NEVER ask you for your password or to update or verify your email account through an email. DO NOT click any links in an email asking you to update or verify your email account. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
Re: [WIRELESS-LAN] More client weirdness
You may be running into the same Windows 10 "feature" that we did a few months ago. Here is the document we wrote up: https://www.ias.edu/wireless-resources RE: https://www.intel.com/content/www/us/en/support/network-and-i-o/wireless-networking/05544.html Good luck, Christina - Original Message - From: "Brahim Bouchaiba" To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Sent: Wednesday, January 31, 2018 1:41:15 PM Subject: Re: [WIRELESS-LAN] More client weirdness Hi, Can you run debug client < mac address> then parse it here: https://cway.cisco.com/tools/WirelessDebugAnalyzer/ On Wed, Jan 31, 2018 at 1:34 PM, Gray, Sean wrote: > Hi Craig, > > > > Sorry I should have mentioned that, our WLC is a 5520 running 8.3.133.0 > code > > > > Sean > > > > *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto: > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Craig Eyre > *Sent:* January-31-18 11:30 AM > *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > *Subject:* Re: [WIRELESS-LAN] More client weirdness > > > > Sean, > > > > > > What version of controller software are you running? > > > > > > Craig Eyre > > > > On Wed, Jan 31, 2018 at 11:17 AM, Gray, Sean wrote: > > Hi Everyone, > > > > I just wanted to throw this weirdness out to the group to see if anyone > has experienced the same issue and has found a solution or work around. > > > > We have a student on campus who intermittently cannot connect to our > 802.1x Student WLAN when trying to connect to a Cisco 702w access point > installed nearby. They can connect to our open Guest WLAN. I should say > that they are fail to connect to Student more times than they succeed when > in their Student Residence. On campus they are able to connect to Student. > > > > I recently brought them down to my office to have them try and connect to > a 702w that I had set up specially for the purpose of this test. > > > > *Client Details:* > > > > · Acer Aspire F5-571T Laptop > > · NIC: Qualcomm Atheros QCA9377 > > · Driver Version 12.0.0.309 > > · O/S: Windows 10 Home > > > > Client has Symantec Anti-virus installed > > > > Windows updates and driver versions were all validated. > > > > > > During testing I noticed that the client completes the AUTH phase and > enters RUN state. At this point it frequently seems to stall and doesn’t > make it into the DHCP Socket Task portion of the client/WLC/DHCP exchange. > > > > The only thing that the testing proved to me is that the client doesn’t > like Cisco 702w APs, as I saw the same results in my office as I saw from > them in Student Residence. Of note is that the problem seems to become > particular pronounce when they roam from Guest to Student or vice versa. > Disabling the Symantec firewall seemed to improve, but not fully resolve > the issue. > > > > I should also point out that due to the unique way that our Residence > townhomes were constructed wall mount APs are our only option. > > > > So this one has me beat! > > > > Thanks > > > > Sean > > > > ** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at http://www.educause.edu/ > discuss. > > > > > > -- > > Craig Eyre > Network Analyst > IT Services Department > Mount Royal University > 4825 Mount Royal Gate SW > <https://maps.google.com/?q=4825+Mount+Royal+Gate+SW+%0D+Calgary+AB+T2P+3T5&entry=gmail&source=g> > Calgary AB T2P 3T5 > > P. 403.440.5199 <(403)%20440-5199> > E. ce...@mtroyal.ca > > "The difference between a successful person and others is not a lack of > strength, not a lack of knowledge, but rather in a lack of will." Vincent > T. Lombardi" > > > > *MRU IT Services will NEVER ask you for your password or to update or > verify your email account through an email. DO NOT click any links in an > email asking you to update or verify your email account.* > > ** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at http://www.educause.edu/ > discuss. > ** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at http://www.educause.edu/ > discuss. > > ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
Re: [WIRELESS-LAN] More client weirdness
Hi, Can you run debug client < mac address> then parse it here: https://cway.cisco.com/tools/WirelessDebugAnalyzer/ On Wed, Jan 31, 2018 at 1:34 PM, Gray, Sean wrote: > Hi Craig, > > > > Sorry I should have mentioned that, our WLC is a 5520 running 8.3.133.0 > code > > > > Sean > > > > *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto: > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Craig Eyre > *Sent:* January-31-18 11:30 AM > *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > *Subject:* Re: [WIRELESS-LAN] More client weirdness > > > > Sean, > > > > > > What version of controller software are you running? > > > > > > Craig Eyre > > > > On Wed, Jan 31, 2018 at 11:17 AM, Gray, Sean wrote: > > Hi Everyone, > > > > I just wanted to throw this weirdness out to the group to see if anyone > has experienced the same issue and has found a solution or work around. > > > > We have a student on campus who intermittently cannot connect to our > 802.1x Student WLAN when trying to connect to a Cisco 702w access point > installed nearby. They can connect to our open Guest WLAN. I should say > that they are fail to connect to Student more times than they succeed when > in their Student Residence. On campus they are able to connect to Student. > > > > I recently brought them down to my office to have them try and connect to > a 702w that I had set up specially for the purpose of this test. > > > > *Client Details:* > > > > · Acer Aspire F5-571T Laptop > > · NIC: Qualcomm Atheros QCA9377 > > · Driver Version 12.0.0.309 > > · O/S: Windows 10 Home > > > > Client has Symantec Anti-virus installed > > > > Windows updates and driver versions were all validated. > > > > > > During testing I noticed that the client completes the AUTH phase and > enters RUN state. At this point it frequently seems to stall and doesn’t > make it into the DHCP Socket Task portion of the client/WLC/DHCP exchange. > > > > The only thing that the testing proved to me is that the client doesn’t > like Cisco 702w APs, as I saw the same results in my office as I saw from > them in Student Residence. Of note is that the problem seems to become > particular pronounce when they roam from Guest to Student or vice versa. > Disabling the Symantec firewall seemed to improve, but not fully resolve > the issue. > > > > I should also point out that due to the unique way that our Residence > townhomes were constructed wall mount APs are our only option. > > > > So this one has me beat! > > > > Thanks > > > > Sean > > > > ** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at http://www.educause.edu/ > discuss. > > > > > > -- > > Craig Eyre > Network Analyst > IT Services Department > Mount Royal University > 4825 Mount Royal Gate SW > <https://maps.google.com/?q=4825+Mount+Royal+Gate+SW+%0D+Calgary+AB+T2P+3T5&entry=gmail&source=g> > Calgary AB T2P 3T5 > > P. 403.440.5199 <(403)%20440-5199> > E. ce...@mtroyal.ca > > "The difference between a successful person and others is not a lack of > strength, not a lack of knowledge, but rather in a lack of will." Vincent > T. Lombardi" > > > > *MRU IT Services will NEVER ask you for your password or to update or > verify your email account through an email. DO NOT click any links in an > email asking you to update or verify your email account.* > > ** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at http://www.educause.edu/ > discuss. > ** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at http://www.educause.edu/ > discuss. > > ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
RE: [WIRELESS-LAN] More client weirdness
Hi Craig, Sorry I should have mentioned that, our WLC is a 5520 running 8.3.133.0 code Sean From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Craig Eyre Sent: January-31-18 11:30 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] More client weirdness Sean, What version of controller software are you running? Craig Eyre On Wed, Jan 31, 2018 at 11:17 AM, Gray, Sean mailto:sean.gr...@uleth.ca>> wrote: Hi Everyone, I just wanted to throw this weirdness out to the group to see if anyone has experienced the same issue and has found a solution or work around. We have a student on campus who intermittently cannot connect to our 802.1x Student WLAN when trying to connect to a Cisco 702w access point installed nearby. They can connect to our open Guest WLAN. I should say that they are fail to connect to Student more times than they succeed when in their Student Residence. On campus they are able to connect to Student. I recently brought them down to my office to have them try and connect to a 702w that I had set up specially for the purpose of this test. Client Details: • Acer Aspire F5-571T Laptop • NIC: Qualcomm Atheros QCA9377 • Driver Version 12.0.0.309 • O/S: Windows 10 Home Client has Symantec Anti-virus installed Windows updates and driver versions were all validated. During testing I noticed that the client completes the AUTH phase and enters RUN state. At this point it frequently seems to stall and doesn’t make it into the DHCP Socket Task portion of the client/WLC/DHCP exchange. The only thing that the testing proved to me is that the client doesn’t like Cisco 702w APs, as I saw the same results in my office as I saw from them in Student Residence. Of note is that the problem seems to become particular pronounce when they roam from Guest to Student or vice versa. Disabling the Symantec firewall seemed to improve, but not fully resolve the issue. I should also point out that due to the unique way that our Residence townhomes were constructed wall mount APs are our only option. So this one has me beat! Thanks Sean ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. -- Craig Eyre Network Analyst IT Services Department Mount Royal University 4825 Mount Royal Gate SW Calgary AB T2P 3T5 P. 403.440.5199 E. ce...@mtroyal.ca<mailto:ce...@mtroyal.ca> "The difference between a successful person and others is not a lack of strength, not a lack of knowledge, but rather in a lack of will." Vincent T. Lombardi" MRU IT Services will NEVER ask you for your password or to update or verify your email account through an email. DO NOT click any links in an email asking you to update or verify your email account. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
Re: [WIRELESS-LAN] More client weirdness
Sean, I would fully uninstall the Symantec software, not just disable it. Symantec even makes a software uninstaller for their products for their extra stubborn apps: https://support.symantec.com/en_US/article.HOWTO74877.html Honestly, whenever their is network weirdness with these types of supplicants, I have many, many times gotten rid of the Symantec products (firewalls/antivirus/Internet Protection Suite/etc) with much success. Thanks!--JW Jess Walczak Senior Network Analyst Information Technology Services jwwalc...@stthomas.edu University of St. Thomas | stthomas.edu On Wed, Jan 31, 2018 at 12:17 PM, Gray, Sean wrote: > Hi Everyone, > > > > I just wanted to throw this weirdness out to the group to see if anyone > has experienced the same issue and has found a solution or work around. > > > > We have a student on campus who intermittently cannot connect to our > 802.1x Student WLAN when trying to connect to a Cisco 702w access point > installed nearby. They can connect to our open Guest WLAN. I should say > that they are fail to connect to Student more times than they succeed when > in their Student Residence. On campus they are able to connect to Student. > > > > I recently brought them down to my office to have them try and connect to > a 702w that I had set up specially for the purpose of this test. > > > > *Client Details:* > > > > · Acer Aspire F5-571T Laptop > > · NIC: Qualcomm Atheros QCA9377 > > · Driver Version 12.0.0.309 > > · O/S: Windows 10 Home > > > > Client has Symantec Anti-virus installed > > > > Windows updates and driver versions were all validated. > > > > > > During testing I noticed that the client completes the AUTH phase and > enters RUN state. At this point it frequently seems to stall and doesn’t > make it into the DHCP Socket Task portion of the client/WLC/DHCP exchange. > > > > The only thing that the testing proved to me is that the client doesn’t > like Cisco 702w APs, as I saw the same results in my office as I saw from > them in Student Residence. Of note is that the problem seems to become > particular pronounce when they roam from Guest to Student or vice versa. > Disabling the Symantec firewall seemed to improve, but not fully resolve > the issue. > > > > I should also point out that due to the unique way that our Residence > townhomes were constructed wall mount APs are our only option. > > > > So this one has me beat! > > > > Thanks > > > > Sean > > > ** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at http://www.educause.edu/ > discuss. > > ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
Re: [WIRELESS-LAN] More client weirdness
Sean, What version of controller software are you running? Craig Eyre On Wed, Jan 31, 2018 at 11:17 AM, Gray, Sean wrote: > Hi Everyone, > > > > I just wanted to throw this weirdness out to the group to see if anyone > has experienced the same issue and has found a solution or work around. > > > > We have a student on campus who intermittently cannot connect to our > 802.1x Student WLAN when trying to connect to a Cisco 702w access point > installed nearby. They can connect to our open Guest WLAN. I should say > that they are fail to connect to Student more times than they succeed when > in their Student Residence. On campus they are able to connect to Student. > > > > I recently brought them down to my office to have them try and connect to > a 702w that I had set up specially for the purpose of this test. > > > > *Client Details:* > > > > · Acer Aspire F5-571T Laptop > > · NIC: Qualcomm Atheros QCA9377 > > · Driver Version 12.0.0.309 > > · O/S: Windows 10 Home > > > > Client has Symantec Anti-virus installed > > > > Windows updates and driver versions were all validated. > > > > > > During testing I noticed that the client completes the AUTH phase and > enters RUN state. At this point it frequently seems to stall and doesn’t > make it into the DHCP Socket Task portion of the client/WLC/DHCP exchange. > > > > The only thing that the testing proved to me is that the client doesn’t > like Cisco 702w APs, as I saw the same results in my office as I saw from > them in Student Residence. Of note is that the problem seems to become > particular pronounce when they roam from Guest to Student or vice versa. > Disabling the Symantec firewall seemed to improve, but not fully resolve > the issue. > > > > I should also point out that due to the unique way that our Residence > townhomes were constructed wall mount APs are our only option. > > > > So this one has me beat! > > > > Thanks > > > > Sean > > > ** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at http://www.educause.edu/ > discuss. > > -- Craig Eyre Network Analyst IT Services Department Mount Royal University 4825 Mount Royal Gate SW Calgary AB T2P 3T5 P. 403.440.5199 E. ce...@mtroyal.ca "The difference between a successful person and others is not a lack of strength, not a lack of knowledge, but rather in a lack of will." Vincent T. Lombardi" MRU IT Services will NEVER ask you for your password or to update or verify your email account through an email. DO NOT click any links in an email asking you to update or verify your email account. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
