Re: [WIRELESS-LAN] WiSM 5.2.193
On Tue, Aug 04, 2009 at 09:13:29AM -0500, Hector J Rios wrote: Has anybody upgraded to 5.2.193? Can you provide any feedback? We have upgraded 31 WLCs from 4.2.130.0 to 5.2.193.0, with no operational issues seen and no problems reported for clients so far. We have approx 3,500 APs, and the client count is at its lowest level due to summer session with around 3,000 peak simultaneous clients. We are installing a number of 1142s, so we needed the new code to support them. We *did* encounter a weird AP join issue on some of the WLCs in one of our mobility groups when there were mixed versions of WLC code while upgrading WLCs in the same mobility group (some controllers on 4.2 and others on 5.2). The issue was a delayed join to the primary WLC for APs during the process of upgrading the controller and then waiting for APs to re-join the upgraded (primary) controller (we configure the primary/secondary/tertiary WLCs on the APs). We escalated the issue and Cisco has developed a fix that will presumably ship in newer code. Meanwhile, we noticed that if we upgraded the first controller in the mobililty group (the one with the lowest MAC address as seen in show mobility summary) to the new controller code first then that seemed to avoid the issue of having large numbers of delayed AP joins. Given that, we resumed our upgrades and have almost completed the entire set of WLCs. -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking c.spurg...@its.utexas.edu / 512.475.9265 ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
WiSM 6.0.182.0
Has anybody upgraded to WiSM 6.0.182.0? Any feedback? Thanks! Dennis Xu Network Analyst Computing and Communication Services University of Guelph 5198244120 x 56217 ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
FW: [WIRELESS-LAN] WiSM 5.2.193
Sorry, I meant to send this to the list. -jcw - John Watters UA: OIT 205-348-3992 -Original Message- From: Watters, John Sent: Wednesday, August 05, 2009 9:33 AM To: 'Charles Spurgeon' Subject: RE: [WIRELESS-LAN] WiSM 5.2.193 I upgraded 18 WiSM controllers yesterday last night that support ~2,000 APs. I also experienced the delayed joins. In addition, I had APs joining controllers in other mobility groups. After that it is very hard to get them to move back. (I had a little over 100 APs join controllers in other mobility groups - about 5%.) In addition, I am seeing a lot of looping: When the WiSM controller rebooted to do the code upgrade, all its APs joined another controller and downloaded the code from that controller even though the controller they came from was already running that version (in my case 5.2.178). Then they tried to move back to their primary controller (now upgraded to 5.2.193), downloaded the new 5.2.193 code and rebooted. They then went back to the controller they originally moved to while their primary controller was being upgraded. Since that code was at a different level (5.2.178) that the new code they had just loaded for the upgraded WiSM, they downloaded the 5.3.178 code again rebooted. They then tried to move back to their primary controller (now upgraded to 5.2.193), downloaded the new 5.2.193 code and rebooted, they then went back to the controller they originally moved to while their primary controller was being upgraded. Since that code was at a different level (5.2.178) that the new code they had just loaded for the upgraded WiSM, they downloaded the 5.3.178 code again rebooted. They then tried to move back to their primary controller do you see the loop here? This was finally resolved by just biting the bullet and upgrading all the WiSMs as fast as I could (including the suggested emergency boot image). That put all the APs into a real mess while it was happening, but really gave them no choice in the end except to join a controller running the 5.2.193 code which got them to stop downloading different code with every join. I opened a case with Cisco but got nothing useful back. I have had this same problem with other WiSM code upgrades. Surely there is a better way to handle this problem of APs moving around to places where they aren't wanted. If anyone has a workable solution to my problems, please send it along. -jcw John Watters The University of Alabama: OIT 205-348-3992 -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Charles Spurgeon Sent: Wednesday, August 05, 2009 9:12 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] WiSM 5.2.193 On Tue, Aug 04, 2009 at 09:13:29AM -0500, Hector J Rios wrote: Has anybody upgraded to 5.2.193? Can you provide any feedback? We have upgraded 31 WLCs from 4.2.130.0 to 5.2.193.0, with no operational issues seen and no problems reported for clients so far. We have approx 3,500 APs, and the client count is at its lowest level due to summer session with around 3,000 peak simultaneous clients. We are installing a number of 1142s, so we needed the new code to support them. We *did* encounter a weird AP join issue on some of the WLCs in one of our mobility groups when there were mixed versions of WLC code while upgrading WLCs in the same mobility group (some controllers on 4.2 and others on 5.2). The issue was a delayed join to the primary WLC for APs during the process of upgrading the controller and then waiting for APs to re-join the upgraded (primary) controller (we configure the primary/secondary/tertiary WLCs on the APs). We escalated the issue and Cisco has developed a fix that will presumably ship in newer code. Meanwhile, we noticed that if we upgraded the first controller in the mobililty group (the one with the lowest MAC address as seen in show mobility summary) to the new controller code first then that seemed to avoid the issue of having large numbers of delayed AP joins. Given that, we resumed our upgrades and have almost completed the entire set of WLCs. -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking c.spurg...@its.utexas.edu / 512.475.9265 ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Re: [WIRELESS-LAN] FW: [WIRELESS-LAN] WiSM 5.2.193
I have seen the APs jumping between WLCs running different code levels and downloading different codes during upgrade as well. Then I came out this upgrade procedure and it seems no more looping: 1. On WLCs management interface vlans, remove the ACL entries which permit APs to join the WLCs. 2. Download new codes to all WLCs from WCS at once. 3. Reboot all WLCs from WCS once. 4. Put the ACL entries back. Then you just watch the APs joining WLCs without looping. Cisco would suggest to shut down all wisms port channels during upgrade and do upgrade through service port. That is the same idea to prevent APs from joining WLCs before the upgrade finish. Dennis Xu Network Analyst Computing and Communication Services University of Guelph 5198244120 x 56217 - Original Message - From: John Watters john.watt...@ua.edu To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Sent: Wednesday, August 5, 2009 10:34:09 AM GMT -05:00 US/Canada Eastern Subject: [WIRELESS-LAN] FW: [WIRELESS-LAN] WiSM 5.2.193 Sorry, I meant to send this to the list. -jcw - John Watters UA: OIT 205-348-3992 -Original Message- From: Watters, John Sent: Wednesday, August 05, 2009 9:33 AM To: 'Charles Spurgeon' Subject: RE: [WIRELESS-LAN] WiSM 5.2.193 I upgraded 18 WiSM controllers yesterday last night that support ~2,000 APs. I also experienced the delayed joins. In addition, I had APs joining controllers in other mobility groups. After that it is very hard to get them to move back. (I had a little over 100 APs join controllers in other mobility groups - about 5%.) In addition, I am seeing a lot of looping: When the WiSM controller rebooted to do the code upgrade, all its APs joined another controller and downloaded the code from that controller even though the controller they came from was already running that version (in my case 5.2.178). Then they tried to move back to their primary controller (now upgraded to 5.2.193), downloaded the new 5.2.193 code and rebooted. They then went back to the controller they originally moved to while their primary controller was being upgraded. Since that code was at a different level (5.2.178) that the new code they had just loaded for the upgraded WiSM, they downloaded the 5.3.178 code again rebooted. They then tried to move back to their primary controller (now upgraded to 5.2.193), downloaded the new 5.2.193 code and rebooted, they then went back to the controller they originally moved to while their primary controller was being upgraded. Since that code was at a different level (5.2.178) that the new code they had just loaded for the upgraded WiSM, they downloaded the 5.3.178 code again rebooted. They then tried to move back to their primary controller do you see the loop here? This was finally resolved by just biting the bullet and upgrading all the WiSMs as fast as I could (including the suggested emergency boot image). That put all the APs into a real mess while it was happening, but really gave them no choice in the end except to join a controller running the 5.2.193 code which got them to stop downloading different code with every join. I opened a case with Cisco but got nothing useful back. I have had this same problem with other WiSM code upgrades. Surely there is a better way to handle this problem of APs moving around to places where they aren't wanted. If anyone has a workable solution to my problems, please send it along. -jcw John Watters The University of Alabama: OIT 205-348-3992 -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Charles Spurgeon Sent: Wednesday, August 05, 2009 9:12 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] WiSM 5.2.193 On Tue, Aug 04, 2009 at 09:13:29AM -0500, Hector J Rios wrote: Has anybody upgraded to 5.2.193? Can you provide any feedback? We have upgraded 31 WLCs from 4.2.130.0 to 5.2.193.0, with no operational issues seen and no problems reported for clients so far. We have approx 3,500 APs, and the client count is at its lowest level due to summer session with around 3,000 peak simultaneous clients. We are installing a number of 1142s, so we needed the new code to support them. We *did* encounter a weird AP join issue on some of the WLCs in one of our mobility groups when there were mixed versions of WLC code while upgrading WLCs in the same mobility group (some controllers on 4.2 and others on 5.2). The issue was a delayed join to the primary WLC for APs during the process of upgrading the controller and then waiting for APs to re-join the upgraded (primary) controller (we configure the primary/secondary/tertiary WLCs on the APs). We escalated the issue and Cisco has developed a fix that will presumably
Re: [WIRELESS-LAN] WiSM 6.0.182.0
Dennis, After the security vulnerability notice (http://www.cisco.com/warp/public/707/cisco-sa-20090727-wlc.shtml ) we looked at it, but our Cisco rep has advised us to move to 5.2.193.0 instead. We have 13 WiSMs and 6 4400's supporting 2800+ access points. James Nesbitt Wireless Engineer Duke University 919-668-6485 On Aug 5, 2009, at 10:15 AM, Dennis Xu wrote: Has anybody upgraded to WiSM 6.0.182.0? Any feedback? Thanks! Dennis Xu Network Analyst Computing and Communication Services University of Guelph 5198244120 x 56217 ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/ . ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
RE: [WIRELESS-LAN] FW: [WIRELESS-LAN] WiSM 5.2.193
You would think there should be a near-hitless upgrade process. Could be as simple as temporarily restricting APs from downgrading. And that doesn't even have to be done the AP side, that could be done via a setting on the WLC. Frank -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Dennis Xu Sent: Wednesday, August 05, 2009 9:49 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] FW: [WIRELESS-LAN] WiSM 5.2.193 I have seen the APs jumping between WLCs running different code levels and downloading different codes during upgrade as well. Then I came out this upgrade procedure and it seems no more looping: 1. On WLCs management interface vlans, remove the ACL entries which permit APs to join the WLCs. 2. Download new codes to all WLCs from WCS at once. 3. Reboot all WLCs from WCS once. 4. Put the ACL entries back. Then you just watch the APs joining WLCs without looping. Cisco would suggest to shut down all wisms port channels during upgrade and do upgrade through service port. That is the same idea to prevent APs from joining WLCs before the upgrade finish. Dennis Xu Network Analyst Computing and Communication Services University of Guelph 5198244120 x 56217 - Original Message - From: John Watters john.watt...@ua.edu To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Sent: Wednesday, August 5, 2009 10:34:09 AM GMT -05:00 US/Canada Eastern Subject: [WIRELESS-LAN] FW: [WIRELESS-LAN] WiSM 5.2.193 Sorry, I meant to send this to the list. -jcw - John WattersUA: OIT 205-348-3992 -Original Message- From: Watters, John Sent: Wednesday, August 05, 2009 9:33 AM To: 'Charles Spurgeon' Subject: RE: [WIRELESS-LAN] WiSM 5.2.193 I upgraded 18 WiSM controllers yesterday last night that support ~2,000 APs. I also experienced the delayed joins. In addition, I had APs joining controllers in other mobility groups. After that it is very hard to get them to move back. (I had a little over 100 APs join controllers in other mobility groups - about 5%.) In addition, I am seeing a lot of looping: When the WiSM controller rebooted to do the code upgrade, all its APs joined another controller and downloaded the code from that controller even though the controller they came from was already running that version (in my case 5.2.178). Then they tried to move back to their primary controller (now upgraded to 5.2.193), downloaded the new 5.2.193 code and rebooted. They then went back to the controller they originally moved to while their primary controller was being upgraded. Since that code was at a different level (5.2.178) that the new code they had just loaded for the upgraded WiSM, they downloaded the 5.3.178 code again rebooted. They then tried to move back to their primary controller (now upgraded to 5.2.193), downloaded the new 5.2.193 code and rebooted, they then went back to the controller they originally moved to while their primary controller was being upgraded. Since that code was at a different level (5.2.178) that the new code they had just loaded for the upgraded WiSM, they downloaded the 5.3.178 code again rebooted. They then tried to move back to their primary controller do you see the loop here? This was finally resolved by just biting the bullet and upgrading all the WiSMs as fast as I could (including the suggested emergency boot image). That put all the APs into a real mess while it was happening, but really gave them no choice in the end except to join a controller running the 5.2.193 code which got them to stop downloading different code with every join. I opened a case with Cisco but got nothing useful back. I have had this same problem with other WiSM code upgrades. Surely there is a better way to handle this problem of APs moving around to places where they aren't wanted. If anyone has a workable solution to my problems, please send it along. -jcw John WattersThe University of Alabama: OIT 205-348-3992 -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Charles Spurgeon Sent: Wednesday, August 05, 2009 9:12 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] WiSM 5.2.193 On Tue, Aug 04, 2009 at 09:13:29AM -0500, Hector J Rios wrote: Has anybody upgraded to 5.2.193? Can you provide any feedback? We have upgraded 31 WLCs from 4.2.130.0 to 5.2.193.0, with no operational issues seen and no problems reported for clients so far. We have approx 3,500 APs, and the client count is at its lowest level due to summer session with around 3,000 peak simultaneous clients. We are installing a number of 1142s, so we needed the new code to support them. We *did*
RE: [WIRELESS-LAN] WiSM 6.0.182.0
Hi Dennis, We have just completed upgrading to 6.0 . Will let you know how it goes. We have 4 Wisms and 460 aps. We upgraded WCS to 6.0 and the interface is much better then previous versions. Peter. -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Dennis Xu Sent: Thursday, 6 August 2009 12:15 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] WiSM 6.0.182.0 Has anybody upgraded to WiSM 6.0.182.0? Any feedback? Thanks! Dennis Xu Network Analyst Computing and Communication Services University of Guelph 5198244120 x 56217 ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
RE: [WIRELESS-LAN] WiSM 6.0.182.0
See below... Daniel Bennett IT Security Analyst Pennsylvania College of Technology One College Ave Williamsport PA, 17701 570.329.4989 -Original Message- From: Matt Haile Sent: Wednesday, August 05, 2009 12:30 PM To: Daniel Bennett Subject: RE: [WIRELESS-LAN] WiSM 6.0.182.0 Yes, we have been running it for about a month with minor problems. This is what I've seen so farWhen our Catalyst 6500 shut off without notice almost all of the APs we had powered by inline power injectors had to be manually rebooted. The other ones connected to an inline power needed to be powered cycled as well. We did not lose all of our APs on campus, but at least half of them had to be either manually power cycled or cycled through the command line. I never had this problem before up until the point of the new controller code. Another minor change with version 6.0.182.0 is the WLAN override option has changed. It is now configured under WLANs-Advanced-AP Groups. Other than that it seems to be pretty solid code and from what I heard it is a candidate for the assurewave program. Matt Haile Network Specialist (CCNA,IUWNE) Pennsylvania College of Technology One College Ave. Williamsport, PA 17701 TEL (570) 329-4995 * FAX (570)320-4430 -Original Message- From: Daniel Bennett Sent: Wednesday, August 05, 2009 10:19 AM To: Matt Haile Subject: FW: [WIRELESS-LAN] WiSM 6.0.182.0 ? Dan -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Dennis Xu Sent: Wednesday, August 05, 2009 10:15 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] WiSM 6.0.182.0 Has anybody upgraded to WiSM 6.0.182.0? Any feedback? Thanks! Dennis Xu Network Analyst Computing and Communication Services University of Guelph 5198244120 x 56217 ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Re: [WIRELESS-LAN] WiSM 6.0.182.0
Hi, We have problems with static assigned IP address APs, when they loose connection to the network. Some access points will go back to requesting dhcp leases, ignore their assigned static IP address. Only way to bring them back is to power off/on, or give them a dhcp IP address and then reboot them. Access Point will then go back to their assigned static IP address, do not have to code it again, just reboot it. It seems random on the time before they revert back to dhcp, Cisco TAC said it should be four hours, a feature but I have had them do it in less than an a hour. I was told Cisco has CSCsz53516 for this and no workaround yet. I saw this feature in 5.2.178, bug ID listed in release notes for 5.2.193 and 6.0.182.0 jim On 8/5/2009 12:32 PM, Daniel Bennett wrote: See below... Daniel Bennett IT Security Analyst Pennsylvania College of Technology One College Ave Williamsport PA, 17701 570.329.4989 -Original Message- From: Matt Haile Sent: Wednesday, August 05, 2009 12:30 PM To: Daniel Bennett Subject: RE: [WIRELESS-LAN] WiSM 6.0.182.0 Yes, we have been running it for about a month with minor problems. This is what I've seen so farWhen our Catalyst 6500 shut off without notice almost all of the APs we had powered by inline power injectors had to be manually rebooted. The other ones connected to an inline power needed to be powered cycled as well. We did not lose all of our APs on campus, but at least half of them had to be either manually power cycled or cycled through the command line. I never had this problem before up until the point of the new controller code. Another minor change with version 6.0.182.0 is the WLAN override option has changed. It is now configured under WLANs-Advanced-AP Groups. Other than that it seems to be pretty solid code and from what I heard it is a candidate for the assurewave program. Matt Haile Network Specialist (CCNA,IUWNE) Pennsylvania College of Technology One College Ave. Williamsport, PA 17701 TEL (570) 329-4995 * FAX (570)320-4430 -Original Message- From: Daniel Bennett Sent: Wednesday, August 05, 2009 10:19 AM To: Matt Haile Subject: FW: [WIRELESS-LAN] WiSM 6.0.182.0 ? Dan -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Dennis Xu Sent: Wednesday, August 05, 2009 10:15 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] WiSM 6.0.182.0 Has anybody upgraded to WiSM 6.0.182.0? Any feedback? Thanks! Dennis Xu Network Analyst Computing and Communication Services University of Guelph 5198244120 x 56217 ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Open-Free Access wireless
I've read some responses on how to handle guest access, but I'm being asked a slightly different question by my campus. We are considering providing free/open wireless access on campus. I can think of a myriad of issues, but I need to find out if anyone else has done this and any comments you might have. We've been registering our user base, and then they access the real network via a webvpn. Guests were handled via the web auth in the Cisco WLC. My biggest concerns are how to handle RIAA and Movie industry copyright notices, CALEA, as well as the unthinkable activity over our wireless network. If it is open, I don't know how I'll be able to identify who did what if at all. Any feedback will be appreciated. Scott Powell Network Manager Wittenberg University spow...@wittenberg.edumailto:spow...@wittenberg.edu 937-525-3821 937-327-7372 fax www.wittenberg.eduhttp://www.wittenberg.edu ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
RE: [WIRELESS-LAN] WiSM 6.0.182.0
UBC upgraded our campus (39 controllers consisting of 4402's 4404's WiSM's and 5508's) on July 18th to 6.0.182. -We had some AP's with Static IP's that needed attention. -We also noticed that the wired ACL in 6.0x doesn't work - we noticed this even during our 6.0 beta test. -AP's that were located at remote sites (via DSL/cable) that were directly connected to controllers, are now having difficulty connecting to controllers running 6.x The solution has been to put these AP's into office extend mode or HREAP mode, where the latency timers are longer. Thanks Ian Procyk UBC IT 604-827-5707 -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Dennis Xu Sent: Wednesday, August 05, 2009 7:15 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] WiSM 6.0.182.0 Has anybody upgraded to WiSM 6.0.182.0? Any feedback? Thanks! Dennis Xu Network Analyst Computing and Communication Services University of Guelph 5198244120 x 56217 ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
RE: [WIRELESS-LAN] Open-Free Access wireless
Scott, I think you answered your own question. We actually considered the idea at some point, strictly because we wanted to make it as easy as possible for everybody to connect to our wireless network. But in the end we decided that the cons were just too many. You've mentioned a few already. And the answer to your question as to how you identify who did what, is simply that you won't be able to. You might be able to map an IP to a MAC address, but then you will still have the tedious task of finding the physical device. I think the only advantage that a wide open network will give you is that you will be able to sniff the traffic. But so will the bad guys, and you won't know who they are. We've made it really easy for our guests to get on our wireless network by obtaining guest accounts that can be created by their hosts (a faculty or staff member) on a web application. We then authenticate them via Cisco's web auth. Responding to DMCA notices and the like still involves a little digging around, but you do everything from your computer. Hector Rios Louisiana State University From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Scott Powell Sent: Wednesday, August 05, 2009 1:33 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Open-Free Access wireless I've read some responses on how to handle guest access, but I'm being asked a slightly different question by my campus. We are considering providing free/open wireless access on campus. I can think of a myriad of issues, but I need to find out if anyone else has done this and any comments you might have. We've been registering our user base, and then they access the real network via a webvpn. Guests were handled via the web auth in the Cisco WLC. My biggest concerns are how to handle RIAA and Movie industry copyright notices, CALEA, as well as the unthinkable activity over our wireless network. If it is open, I don't know how I'll be able to identify who did what if at all. Any feedback will be appreciated. Scott Powell Network Manager Wittenberg University spow...@wittenberg.edu 937-525-3821 937-327-7372 fax www.wittenberg.edu ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Re: [WIRELESS-LAN] Open-Free Access wireless
We actually are going the other way. Our wireless has been 'open' since day one, but due to all the issues mentioned and the changes in the legal landscape (or possible changes) we are in the process of securing our wireless. We will be requiring daily users to use our Safe Connect platform which also has the ability for our help desk ( and in the future, other departments) to create guest accounts. We have had multiple RIAA notices with users on wireless with no way to track them down which was one factor in deciding to secure the wireless. Randy Ethridge Information Services Eastern Illinois University - Original Message - From: Hector J Rios hr...@lsu.edu To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Sent: Wednesday, August 5, 2009 8:11:58 PM GMT -06:00 US/Canada Central Subject: Re: [WIRELESS-LAN] Open-Free Access wireless Scott, I think you answered your own question. We actually considered the idea at some point, strictly because we wanted to make it as easy as possible for everybody to connect to our wireless network. But in the end we decided that the cons were just too many. You’ve mentioned a few already. And the answer to your question as to how you identify who did what, is simply that you won’t be able to. You might be able to map an IP to a MAC address, but then you will still have the tedious task of finding the physical device. I think the only advantage that a wide open network will give you is that you will be able to sniff the traffic. But so will the bad guys, and you won’t know who they are. We’ve made it really easy for our guests to get on our wireless network by obtaining guest accounts that can be created by their hosts (a faculty or staff member) on a web application. We then authenticate them via Cisco’s web auth. Responding to DMCA notices and the like still involves a little digging around, but you do everything from your computer. Hector Rios Louisiana State University From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Scott Powell Sent: Wednesday, August 05, 2009 1:33 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Open-Free Access wireless I’ve read some responses on how to handle guest access, but I’m being asked a slightly different question by my campus. We are considering providing “free”/”open” wireless access on campus. I can think of a myriad of issues, but I need to find out if anyone else has done this and any comments you might have. We’ve been registering our user base, and then they access the real network via a webvpn. Guests were handled via the web auth in the Cisco WLC. My biggest concerns are how to handle RIAA and Movie industry copyright notices, CALEA, as well as the “unthinkable” activity over our wireless network. If it is “open”, I don’t know how I’ll be able to identify who did what if at all. Any feedback will be appreciated. Scott Powell Network Manager Wittenberg University spow...@wittenberg.edu 937-525-3821 937-327-7372 fax www.wittenberg.edu ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
