NCS Prime 1.2.0.103 dashboard
Perhaps it's because it's Friday, but just getting PI 1.2.0.103 up running and I see that when within the GENERAL dashboard, I cannot scroll all the way to the right to see the edge of the dashlets on that side. I thought it might be quickest to just ask this group. Anyone else seeing this? or is this just a user error as I get accustomed to the new interface ;-) If I minimize all dashlets on the left, then I can see a bit more of it. I'm seeing no difference between IE/Chrome (most current revs). If I drag/drop the right-side dashlets to the left , then I can see the entire thing - I suppose I can move them all to the left hand side. Secondly, can one create a user-defined dashboard (to be used by a number of users) and then lock the layout down? TIA, ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
RE: [WIRELESS-LAN] Apple Petition
...@listserv.educause.edu WIRELESS- l...@listserv.educause.edumailto:WIRELESS- l...@listserv.educause.edu Subject: Re: [WIRELESS-LAN] Apple Petition If those entries work, and are all that is needed, then we're not far from full support. It seems like we could get a tool or set of scripts to automate creating/modifying the needed records. Sent from my iPad On Jul 10, 2012, at 7:11 PM, Johnson, Neil M neil- john...@uiowa.edumailto:neil-john...@uiowa.edu wrote: We looked into DNS-SD, but with entries like this (example taken from an earlier e-mail from Oscar Silva at the Univ. or Texas , and confirmed by our own testing): _airplay._tcp PTR utnet-appletv._airplay._tcp utnet-appletv._airplay._tcp SRV 0 0 7000 utnet- appletv.bonjour.utexas.eduhttp://utnet-appletv.bonjour.utexas.edu. ; Replace with unicast FQDN of target host utnet-appletv._airplay._tcp TXT deviceid=28:E7:CF:DB:6E:E0 features=0x39f7 model=AppleTV2,1 pw=1 srcvers=120.2 _raop._tcpPTR 28E7CFDB6EE0@utnet- appletv._raop._tcpmailto:28E7CFDB6EE0@utnet-appletv._raop._tcp 28E7CFDB6EE0@utnet-appletv._raop._tcpmailto:28E7CFDB6EE0@utnet- appletv._raop._tcp SRV 0 0 49152 utnet- appletv.bonjour.utexas.eduhttp://utnet-appletv.bonjour.utexas.edu. ; Replace with unicast FQDN of target host 28E7CFDB6EE0@utnet-appletv._raop._tcpmailto:28E7CFDB6EE0@utnet- appletv._raop._tcp TXT txtvers=1 ch=2 cn=0,1,2,3 da=true et=0,3 md=0,1,2 pw=true sv=false sr=44100 ss=16 tp=UDP vn=65537 vs=120.2 am=AppleTV2,1 sf=0x4 _appletv-v2._tcp PTR 35CF2488F02660B1._appletv-v2._tcp 35CF2488F02660B1._appletv-v2._tcp SRV 0 0 3689 utnet- appletv.bonjour.utexas.eduhttp://appletv.bonjour.utexas.edu. ; Replace with unicast FQDN of target host 35CF2488F02660B1._appletv-v2._tcp TXT txtvers=1 hG=-06f6- 4f5d-0171-0bcc51d34d14 MniT=167845888 fs=2 Name=utnet-appletv PrVs=65538 DFID=2 EiTS=1 MiTPV=196611 _sleep-proxy._udp PTR 70-35-60-63\032utnet-appletv._sleep- proxy._udp 70-35-60-63\032utnet-appletv._sleep-proxy._udp SRV 0 0 55597 utnet- appletv.bonjour.utexas.eduhttp://utnet-appletv.bonjour.utexas.edu. ; Replace with unicast FQDN of target host 70-35-60-63\032utnet-appletv._sleep-proxy._udp TXT required for every Apple TV (and no direction from Apple on what entries/fields are actually required) our DNS admins were ready with pitch forks and torches if we attempted saddle them with the the responsibility of trying to maintain records for 100's such devices (not to mention printers, etc.). -Neil -- Neil Johnson Network Engineer The University of Iowa Phone: 319 384-0938 Fax: 319 335-2951 Mobile: 319 540-2081 E-Mail: neil-john...@uiowa.edumailto:neil-john...@uiowa.edu From: Garry Peirce pei...@maine.edumailto:pei...@maine.edu Reply-To: pei...@maine.edumailto:pei...@maine.edu pei...@maine.edumailto:pei...@maine.edu Date: Tuesday, July 10, 2012 10:15 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDUmailto:WIRELESS- l...@listserv.educause.edu WIRELESS- l...@listserv.educause.edumailto:WIRELESS- l...@listserv.educause.edu Subject: Re: [WIRELESS-LAN] Apple Petition I'm in support of the collective request to help enable further operational flexibility, although also not sure Apple will feel enough pressure to assist. To the first item: 'That Apple establish a way for Apple TV's (and other Bonjour/Airplay enabled devices) be accessible across multiple IPv4 and IPv6 sub-nets. Isn't this item solved to a degree by wide area DNS-SD? If not, I assume this is left open to solve by either making it use a routable mcast addr or by creating some non-standard solution. Controls will be needed to make sense of all the advertised services and possibly for security/privacy reasons. I would think navigating a large Bonjour enabled subnet for a production service must be an ugly exercise - nevermind if enabled to pass L2 boundaries. Who remembers those IPX service filtering ACLs? Request #2 might soon follow to network vendors to be able to support Bonjour service filtering. For production services, wide area DNS-SD seems a better tool to me, as opposed to using the wild west of zeroconf end device advertisements or some special hardware solution. We've trialed it (static entries) for printing and it seems to work well. This leverages our existing DNS infrastructure, allows for control of the advertised entries, and a uniform naming convention making it easier to identify the service. One could also opt to block 224.0.0.251 altogether, if there is concern about unnecessary device traffic. So in tandem to supporting this request, I'd also be interested in anyone's recap of their wide area DNS-SD (WAB) environment, the services being advertised , how it is scaling, and any major stumbling blocks. From: The EDUCAUSE Wireless Issues
RE: [WIRELESS-LAN] Apple Petition- Mid-Week Sanity Check
Hearing that some do not use FB that wish to sign, perhaps moving it to a site like http://www.change.org/ http://www.change.org is a possibility, or perhaps a page could be hosted on the Educause website itself? The petition's main statement reads: We the undersigned academic and research institutions request that Apple provide support for Bonjour/Airplay technology in enterprise networks. Might I suggest a possible refinement to: We the undersigned academic and research institutions request that Apple collaborate with us to improve Bonjour/Airplay technologies in enterprise networks. For me, if DNS-SD worked for Airplay (as it does for printing) , my current hurdle would largely be solved. That would also require the AppleTV concession made to content-providers relaxed or removed. Perhaps they could make an alternative AppleTV image that allows DNS-SD to work, but removes the content-provider features (?). If one needs both the content services and Airplay across subnets, that seems the immediate problem we'd like Apple to help solve in lieu of other proprietary solutions. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jesse Rink Sent: Wednesday, July 11, 2012 7:34 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Apple Petition- Mid-Week Sanity Check So for those of us without Facebook, no way of signing it? From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman Sent: Wednesday, July 11, 2012 8:14 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Apple Petition- Mid-Week Sanity Check Folks, Those interested seem to agree that we'd discuss specific pain points regarding those other Apple devices like AppleTv and any AirPlay/Bonjour-dependent gadgets until Friday, at which point we'd firm up the petition and find a place to host it. Then would come signatures, and ultimately presenting it to Apple, possibly via each of our Apple reps. Neil Johnson has started the companion Facebook group, and has drafted the early version of what everyone appears to want from Apple development in petition form at https://www.facebook.com/groups/enterpriseairplay with 72 members joining thus far. (Thanks, Neil) We have at least one CIO interested, and interested in sharing it with other CIOs via Educause if petition is done in a constructive, fact-based way. We also have a bit of media coverage coming soon on the process, with potentially more to follow. A lot of excellent technical discussion has been spawned during all of this, and as usual, the interaction has been great between list members. All of that being said, it is worth asking: . Is the group still feeling good about the direction this initiative is going in? . Does anyone have any problems with the wording and points in the doc so far? . Is everyone interested able to sign on behalf of their institution/organization? If not, can you get empowered or find someone who can sign? . Has anyone else approached senior IT management and found interest? Any other CIOs game at this point? . Any other mid-week thoughts, concerns, comments on the topic? Regards- Lee Badman ** 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/.
RE: [WIRELESS-LAN] Apple Petition
I’m in support of the collective request to help enable further operational flexibility, although also not sure Apple will feel enough pressure to assist. To the first item: ‘That Apple establish a way for Apple TV's (and other Bonjour/Airplay enabled devices) be accessible across multiple IPv4 and IPv6 sub-nets.” Isn’t this item solved to a degree by wide area DNS-SD? If not, I assume this is left open to solve by either making it use a routable mcast addr or by creating some non-standard solution. Controls will be needed to make sense of all the advertised services and possibly for security/privacy reasons. I would think navigating a large Bonjour enabled subnet for a production service must be an ugly exercise - nevermind if enabled to pass L2 boundaries. Who remembers those IPX service filtering ACLs? Request #2 might soon follow to network vendors to be able to support Bonjour service filtering. For production services, wide area DNS-SD seems a better tool to me, as opposed to using the wild west of zeroconf end device advertisements or some special hardware solution. We’ve trialed it (static entries) for printing and it seems to work well. This leverages our existing DNS infrastructure, allows for control of the advertised entries, and a uniform naming convention making it easier to identify the service. One could also opt to block 224.0.0.251 altogether, if there is concern about unnecessary device traffic. So in tandem to supporting this request, I’d also be interested in anyone’s recap of their wide area DNS-SD (WAB) environment, the services being advertised , how it is scaling, and any major stumbling blocks. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman Sent: Monday, July 09, 2012 4:00 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Apple Petition Please consider this- as we get to the point where we have an agreed on document, say by this Friday, and we find an online petition site to use where individuals can sign on in whatever form that takes before we close the signing window and present it to Apple- are each one of us able to do so on behalf of our institutions or organizations? If you need to seek permission, now is the time. If a CIO or Director is the only one allowed to make such public-facing declarations on behalf of your school/or org, it would be good to start working the notion. Ideally, no one would overstep their position by jumping on this worthy endeavor. Lee H. Badman Wireless Architect/Network Engineer Information Technology and Services Adjunct Instructor, iSchool Syracuse University 315 443-3003 From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Andy Voelker Sent: Monday, July 09, 2012 12:44 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Apple Petition That confuses me as well. It is obviously built in to many other iOS devices (iPod Touch, iPad) and has been for some time. Why the change? I suspect it just due to the GUI difference. If so, that’s easily fixable. -- Andy Voelker Manager of Student Computing in the Technology Commons WCU Staff Senator Western Carolina University Check the status of your IT requests at any time at http://help.wcu.edu/ ! From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Voll, Toivo Sent: Friday, July 06, 2012 1:28 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Apple Petition Also, for me, the lack of support for WPA2-Enterprise is a head-scratcher. If they go through the trouble of supporting the rest of the encryption schemes, and obviously support it on a bunch of their other products, why randomly leave it out of some products? I’d prioritize that a bit more, personally. -- Toivo Voll Network Engineer Information Technology Communications University of South Florida ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Re: [WIRELESS-LAN] You knew it was coming...Airplay/Apple TV support for instructors.
I apologize for duplicate posting, but it was suggested I rename the subject of my note below so that it fall under this related subject thread. Re: Cisco vlan select method – I note to be discovered by clients, “This means the Apple TV should be forced to announce itself by being put to sleep, and then woken up.”Is this one time occurrence or would a user have to have mgt access to the AppleTV in order to put it to sleep/wake up to be able to discover it? If it’s the advertisement needs this frequent kick, I unfortunately suspect it might be easier to simply power-cycle it. Also, Eric, do you know if the Avahi reflector allows for any level of Bonjour service level filtering? = I’m in support of the collective request to help enable further operational flexibility, although also not sure Apple will feel enough pressure to assist. To the first item: ‘That Apple establish a way for Apple TV's (and other Bonjour/Airplay enabled devices) be accessible across multiple IPv4 and IPv6 sub-nets.” Isn’t this item solved to a degree by wide area DNS-SD? If not, I assume this is left open to solve by either making it use a routable mcast addr or by creating some non-standard solution. Controls will be needed to make sense of all the advertised services and possibly for security/privacy reasons. I would think navigating a large Bonjour enabled subnet for a production service must be an ugly exercise - nevermind if enabled to pass L2 boundaries. Who remembers those IPX service filtering ACLs? Request #2 might soon follow to network vendors to be able to support Bonjour service filtering. For production services, wide area DNS-SD seems a better tool to me, as opposed to using the wild west of zeroconf end device advertisements or some special hardware solution. We’ve trialed it (static entries) for printing and it seems to work well. This leverages our existing DNS infrastructure, allows for control of the advertised entries, and a uniform naming convention making it easier to identify the service. One could also opt to block 224.0.0.251 altogether, if there is concern about unnecessary device traffic. So in tandem to supporting this request, I’d also be interested in anyone’s recap of their wide area DNS-SD (WAB) environment, the services being advertised , how it is scaling, and any major stumbling blocks. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman Sent: Monday, July 09, 2012 4:00 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Apple Petition Please consider this- as we get to the point where we have an agreed on document, say by this Friday, and we find an online petition site to use where individuals can sign on in whatever form that takes before we close the signing window and present it to Apple- are each one of us able to do so on behalf of our institutions or organizations? If you need to seek permission, now is the time. If a CIO or Director is the only one allowed to make such public-facing declarations on behalf of your school/or org, it would be good to start working the notion. Ideally, no one would overstep their position by jumping on this worthy endeavor. Lee H. Badman Wireless Architect/Network Engineer Information Technology and Services Adjunct Instructor, iSchool Syracuse University 315 443-3003 From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Andy Voelker Sent: Monday, July 09, 2012 12:44 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Apple Petition That confuses me as well. It is obviously built in to many other iOS devices (iPod Touch, iPad) and has been for some time. Why the change? I suspect it just due to the GUI difference. If so, that’s easily fixable. -- Andy Voelker Manager of Student Computing in the Technology Commons WCU Staff Senator Western Carolina University Check the status of your IT requests at any time at http://help.wcu.edu/ ! From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Voll, Toivo Sent: Friday, July 06, 2012 1:28 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Apple Petition Also, for me, the lack of support for WPA2-Enterprise is a head-scratcher. If they go through the trouble of supporting the rest of the encryption schemes, and obviously support it on a bunch of their other products, why randomly leave it out of some products? I’d prioritize that a bit more, personally. -- Toivo Voll Network Engineer Information Technology Communications University of South Florida ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at
RE: [WIRELESS-LAN] You knew it was coming...Airplay/Apple TV support for instructors.
I am currently not a fan of using ZeroConf service discovery (SD) protocols but I see two issues here. 1) multicast service across 802.11 infrastructure 2) ZeroConf-SD. Granted there are inherent obstacles for mcast over wireless, but I feel we first need better mcast functionality (specifically control) aiming to bring further access equality with respect to wired side. Beyond service discovery, there are certainly other services requiring mcast (ex. IPTV and IPv6). From what I'm able to do today in a Cisco v7.0.116 environment, I'm still hesitant to enable mcast on WLANs. My perceived concerns in enabling mcast are below - I'm interested in other's thoughts: 1) There's no control of clients sourcing mcast traffic [groups or rate] to wired/ wireless destinations within the WLAN subnet. Without such controls, it could put the infrastructure at risk (local AP air-time, BW, controller CPU?) potentially affecting other users. Wired subnets can suffer from the same, but controls could be implemented on the wired port or ultimately admin'd down. a. Including link-local or site-local relative scope groups ; Ex. I may want mcast to support v6 (along with RA source guard) but filter 224.0.0.251 between clients. i. Actually just found this Cisco wls IPv6 guide http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bae 506.shtml#sourcegrd for 7.2 - nice! Although no mention of ACLs. 2) If mcast were enabled using Cisco Videostream methods, I believe any WLAN requested mcast data would end up at every AP, whether to be sent (unicast) to clients or dropped. Ideally I'd rather not have it go to APs where it's not requested but also realize it may not be wise to have the controller replicating packets - tough nut to crack. With regard to Zeroconf protocols (mDNS, SSDP, SLP, and LLMNR) 1) In large environments, ZeroConf protocols could be chatty which may a. be a local air-time concern. b. finding resources in a sea of advertised services seen in a 'browser' could be daunting for users. 2) ZeroConf protocols would not work as expected by users where a single SSID represents many distinct subnets ; adding confusion and increased calls to the helpdesk. a. Thanks to JeffSessler for posting the Bonjour doc - although there seem some interesting caveats, the vlan pooling/multicast VLAN feature seem a method aiming to solve this. 3) Even once mcast hurdles are overcome, to me, SD still seems more sanely operated/managed using DNS-SD. Lastly, re: Airplay specifically, is/can the content stream be mcast'd from the source? Assume that if not today, it would eventually appear. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeffrey Sessler Sent: Thursday, February 23, 2012 2:48 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] You knew it was coming...Airplay/Apple TV support for instructors. Wanted to pass this on - it's not published yet on the Cisco site. It's an extensive Bonjour deployment guide for their controllers. Jeff On Thursday, February 23, 2012 at 10:37 AM, in message 23292fa80ecbbd4093a589cbe06e403311b85...@emaildbprod2.babson.edu, Thompson, William wthomp...@babson.edu wrote: I would request a point of clarification: 20 students? Or 20 devices? As others have observed, everyone is carrying more AP-interested gear, thus 20 students could actually correspond to 40-60 devices. No longer a one-student-one-device world. Would it be correct to infer 20 devices? -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Osborne, Bruce W Sent: Thursday, February 23, 2012 12:14 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] You knew it was coming...Airplay/Apple TV support for instructors. Where did you get that 12 client number?? At Liberty University, we have successfully had 20 students per AP with 5Mbit streams. In a Lab test situation, we had 30 clients all streaming on one AP-125 access point. Multicast on 802.11 uses the lowest rate which is 6Mbit for 5GHz networks. That is why Aruba developed their multicast technology. We have been using it since it was introduced. Bruce Osborne Network Engineer IT Network Services (434) 592-4229 LIBERTY UNIVERSITY 40 Years of Training Champions for Christ: 1971-2011 -Original Message- From: Brooks, Stan [mailto:stan.bro...@emory.edu] Sent: Wednesday, February 22, 2012 12:49 PM Subject: Re: You knew it was coming...Airplay/Apple TV support for instructors. So it's not just about the bandwidth. B'cast M'cast use the lowest configured data rate of the AP - just like wireless management frames. This means that even for 300Mbps 802.11n network is reduced to 24Mbps or less. That
RE: [WIRELESS-LAN] Cisco APs losing CAPWAP session
I think you have some of us all getting curious! ;-) Could you put a historically stable admin AP onto the 5508 and vice-versa to see if behaviors change? Do we assume that all switchports in the path are showing they're running clean? Any QoS config in place on the switches? -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Dan Brisson Sent: Wednesday, February 01, 2012 9:09 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Cisco APs losing CAPWAP session Good to know. The trunks are actually all 10Gig links, or 90% of them are, so utilization is most likely not the case, which I'm able to verify from Cacti graphs. The APs are connected to 3560Xs PoE switches that then uplink into either a 3560E-12D or directly into a 4900M where the 5508s are connected. Certainly can't rule out physical layer issue somewhere, although it's so wide spread across 2 different 5508s that we would need to have multiple issues. The other interesting thing for us is that the 500 or so APs on our admin side that do not lose their CAPWAP session, join to WiSMs, not 5508s. Thanks, -dan Dan Brisson Network Engineer University of Vermont (Ph) 802.656.8111 dbris...@uvm.edu On 1/31/2012 8:44 PM, Garry Peirce wrote: We have ~1400 (1240s-3502's) running 7.0.116 and have no such issues. I would guess at packet loss as well - some things you might look at: Are the trunks carrying user/AP traffic seem congested when the APs drop? Have you verified there are no duplex issues? It may exhibit itself more as traffic levels rise. ResHall switching significantly different than on the admin side? Probably need further topology, version, config info, but as you've a case open, the TAC will likely ask the same and help find the culprit(s) for you. -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Dan Brisson Sent: Tuesday, January 31, 2012 8:30 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Cisco APs losing CAPWAP session I'm curious if any Cisco users out there are experiencing or have experienced what we're seeing on our campus. This past summer we installed 3502i's in all of our residence halls - approximately 500 total. Ever since the students have moved in, we will get messages from WCS stating that AP XYZ is down and disassociated from the controller. When I check out the AP, the uptime is fine, but the CAPWAP join time is for like 30 seconds, or however long it took me to check. We've tracked this and it is totally random as to what AP will drop, which makes troubleshooting this very tough. The log on the AP isn't helpful. I'm working with TAC who suggests that keepalives are getting missed. I'm not sure why that would be the case since we have another 500 or so APs on the admin side that very rarely drop. Adding to that, when the students left for break, the AP drops stopped. They came back, and sure enough, the drops start up again. I will say that the AP always joins back immediately, but for the time that it does drop A) I'm sure connectivity is affected in that area and B) we get an email. Anyone experiencing this? Thanks, -dan -- Dan Brisson Network Engineer University of Vermont (Ph) 802.656.8111 dbris...@uvm.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/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
RE: [WIRELESS-LAN] Inter-Campus Wifi GPS Tracking
Dale beat me to it, as I was thinking of the exact same thing. With perhaps the downside being adding support complexity should it have an issue. -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Dale W. Carder Sent: Wednesday, February 01, 2012 11:56 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Inter-Campus Wifi GPS Tracking Thus spake Zachary McGibbon, Mr (zachary.mcgib...@mcgill.ca) on Wed, Feb 01, 2012 at 04:27:37PM +: One of the next parts of the project we would like to do is to add GPS tracking to the bus so students would know how close the bus is (as it gets quite cold here in Montreal during the winter!). Since there is a second Ethernet port available on the AP70, we thought of using this for the GPS, however I can't find any Ethernet GPS'. Does anyone have any ideas of what we could use? I had thought about getting a Garmin OEM GPS with a serial port output connected to a Lantronix Serial to Ethernet box and sending back the NMEA strings to a server, however I wanted to find an all included Ethernet solution and not have to worry about powering and configuring two devices. This sounds like a perfect application for an Arduino connected to a Parallax GPS. http://arduino.cc/playground/Tutorials/GPS Maybe you could find some electrical engineering students to build it as a project :-) Otherwise, as you mention something based on APRS could work too. Dale ** 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] Cisco APs losing CAPWAP session
We have ~1400 (1240s-3502's) running 7.0.116 and have no such issues. I would guess at packet loss as well - some things you might look at: Are the trunks carrying user/AP traffic seem congested when the APs drop? Have you verified there are no duplex issues? It may exhibit itself more as traffic levels rise. ResHall switching significantly different than on the admin side? Probably need further topology, version, config info, but as you've a case open, the TAC will likely ask the same and help find the culprit(s) for you. -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Dan Brisson Sent: Tuesday, January 31, 2012 8:30 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Cisco APs losing CAPWAP session I'm curious if any Cisco users out there are experiencing or have experienced what we're seeing on our campus. This past summer we installed 3502i's in all of our residence halls - approximately 500 total. Ever since the students have moved in, we will get messages from WCS stating that AP XYZ is down and disassociated from the controller. When I check out the AP, the uptime is fine, but the CAPWAP join time is for like 30 seconds, or however long it took me to check. We've tracked this and it is totally random as to what AP will drop, which makes troubleshooting this very tough. The log on the AP isn't helpful. I'm working with TAC who suggests that keepalives are getting missed. I'm not sure why that would be the case since we have another 500 or so APs on the admin side that very rarely drop. Adding to that, when the students left for break, the AP drops stopped. They came back, and sure enough, the drops start up again. I will say that the AP always joins back immediately, but for the time that it does drop A) I'm sure connectivity is affected in that area and B) we get an email. Anyone experiencing this? Thanks, -dan -- Dan Brisson Network Engineer University of Vermont (Ph) 802.656.8111 dbris...@uvm.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] Wireless in dorms
2 cents from someone in a similar boat. Unfortunately, some of our campuses have been unable to support ubiquitous wireless in dorms due to cost. In some cases they have only common areas covered. That being the case , with wireless being the preferred access method along with a lack of local campus policy in this regard they've understandably connected SOHO wireless routers. Some our of ResHalls caused us significant problems on the wired side at the start of this semester. Although we enable L2 features (such as DHCP snooping/DAI/SG,MAC limits) we weren't able to corral an issue until implementing blocking of unknown unicast (cisco UUFB) on the ResHall subnets. This being a wireless forum, I'll omit the details but in a nutshell, the issues were ICMP redirect/ARP-amplification related and would intermittently peg the attaching campus router's CPU. I think efforts to searchfix offending devices or train students is entering a never ending battle. As cheaper devices will not have A radios (not that many clients will either..) co-channel interference is likely common. Add in interference , ex. assuming a fair # of microwave ovens, and I'd think their wireless experience is less than spectacular with no one to reach out to for insight/support. I feel such devices in ResHalls add an unmanaged infrastructure that not only underserves the users but may also have consequences for the managed infrastructure it connects to. I suppose by allowing them to use such devices, one can remove themselves from wireless infrastructure/client support, but I'd rather be in a position where we could supply the needed wireless service in a managed way and avoid their need to use them. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Ray DeJean Sent: Monday, September 19, 2011 11:04 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Wireless in dorms All, We don't currently provide wireless in our dorms, and our official policy is to not allow students to bring their own wireless devices. We don't actively enforce this policy though, and as long as the students' device isn't causing problems, they typically don't hear from us. (We do provide at least a 100mbps wired connection to each student). We are considering changing our policy to allow BYOD (bring your own device) in the dorms. I know lots of students already BYOD, but we're not policing it. We're considering the costs associated with deploying our Aruba system to all the dorms, and the fact that students are going to BYOD anyway. Rather than fight them, allow it. We'll secure our wired network obviously, but also have workshops and online instructions to show the students how to properly connect and secure their device. Of course we realize the interference issues that may arise in a crowded 2.4ghz space... The University of Wisconsin-Madison (http://www.housing.wisc.edu/resnet/gameConsoles.php) already has a policy like this in place. Just looking to hear from other universities who have or are considering a policy such as this. thanks, ray -- Ray DeJean Systems Engineer Southeastern Louisiana University email: r...@selu.edu http://r-a-y.org ** 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] GD code version for Cisco 4402 WLC
Had been running 7.0.98 for a year+, just recently migrated all controllers (13 w/~1.3K APs) to 7.0.116 - so far so good. Afterwards I'd heard that multiple Lion clients that had been having connectivity issues (while under 7.0.98) saw the problem vanish, but that's all suspect without details. I was hoping to see if any on this list mentioned Lion wls connectivity issues, but having seen none, I assumed there may have been something local going on. I did find a lengthy thread here, but as the issue apparently vanished here, I've not read through it all to separate details from the me toos. https://discussions.apple.com/message/15675496#15675496 . From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jamie Savage Sent: Friday, August 05, 2011 11:28 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] GD code version for Cisco 4402 WLC Hi all, We have a Cisco 4402 WLC that we've been running for a while with no major issues. The code we're running is 6.0.182.0 and figured perhaps it's time to upgrade prior to the school year. As nothing on the Cisco web-site is labelled GD, I was looking for recommendations for a stable version to move to. .thanks in advanceJ James Savage York University Senior Communications Tech. 108 Steacie Building jsav...@yorku.ca4700 Keele Street ph: 416-736-2100 ext. 22605Toronto, Ontario fax: 416-736-5830M3J 1P3, CANADA ** 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] iOS devices on wireless
I'd agree that the protocol should be 'fixed' here and not re-design the underlying network to support a particular service. (note that other service discovery protocols have the same issue - SSDP, WS-Discovery) To that end, I was curious if anyone had tried/is using DNS-SD (unicast) to support Bonjour on wireless - aka 'wide area' Bonjour , whether for static or dynamic services. -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman Sent: Friday, June 24, 2011 12:54 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] iOS devices on wireless Would be nice if Apple updated Bonjour or ditched it and got with the fact that enterprise networks are not built on Airports and single subnets... From: The EDUCAUSE Wireless Issues Constituent Group Listserv [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeffrey Sessler [j...@scrippscollege.edu] Sent: Thursday, June 23, 2011 2:53 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] iOS devices on wireless Bruce, I'm not sure I'm advocating large wireless networks at all... At the minimum, ensuring a given user's devices are all in the same L2 network doesn't change your desire to use smaller /23 subnets, it only requires additional back-end support to ensure those devices are placed together. Probably more work for IT staff, and potentially less efficient IP pool use, but I'd argue it will provide a better customer experience. Even the desire to group devices within a given residential hall together doesn't mandate a change in the size of your subnets, although I suspect that would depend more on the size of your housing units. Our residential halls are 80-100 beds, so an easy fit within smaller subnets. Jeff Osborne, Bruce W bosbo...@liberty.edu 6/23/2011 5:32 AM Jeff, Large wireless subnets increase airtime consumed by broadcast traffic. That is why we use a VLan pool of /23 subnets. The clients are distributed automatically based on a hash of the mac address the number of subnets in the pool, so we cannot easily control which subnet a user gets. Changing the number of subnets in the pool recalculates everybody's subnet too, so we make sure we have plenty of capacity. Bruce Osborne Wireless Network Engineer IT Network Services (434) 592-4229 LIBERTY UNIVERSITY 40 Years of Training Champions for Christ: 1971-2011 -Original Message- From: Jeffrey Sessler [mailto:j...@scrippscollege.edu] Sent: Wednesday, June 22, 2011 4:30 PM Subject: Re: iOS devices on wireless Bruce, You could, by any number of technical solutions, ensure that students within a given residential space were all on the same L2 network. That is to say, if a given residence hall is made up of 200 students, then it's not technically difficult to ensure all the residential wireless devices within that area are placed in the same VLAN. Or, at a minimum, to ensure that a user's device(s) will always be in the same L2 network so that they can see each other. If one can't do that, then I wouldn't consider the wireless solution to be very flexible, especially given the trend in devices wanting/needing to talk to each other. On my campus, students spend four years of their life in what we consider a residential setting, and it seems only logical to me that the experience should, to the extent possible, mimic home life. That is, it's reasonable to me to expect a student's wireless devices to see each other, and that they should be able to share/collaborate with the other users within their residential hall. I know that if I was back in college, I'd expect that level of functionality, and If it wasn't there, I'd probably make it happen using my own gear... exactly what you don't want happening. Jeff Osborne, Bruce W bosbo...@liberty.edu 6/22/2011 4:55 AM We here at Liberty University have about 8000 students in our residences, the vast majority using wireless. That would be a *huge* L2 network. Bruce Osborne Wireless Network Engineer IT Network Services (434) 592-4229 LIBERTY UNIVERSITY 40 Years of Training Champions for Christ: 1971-2011 -Original Message- From: Jeffrey Sessler [mailto:j...@scrippscollege.edu] Sent: Tuesday, June 21, 2011 3:05 PM Subject: Re: iOS devices on wireless Mike, I take it you are not able to reference housing data and then place all students/student devices from the same residential hall into the same VLAN? Jeff Michael Dickson mdick...@nic.umass.edu 6/21/2011 11:18 AM On Jun 21, 2011, at 2:04 PM, Jeffrey Sessler wrote: My belief is that a student should be able to have a similar experience when in a residential hall as they would at home. That requires supporting everything under the sun including Bonjour. Unfortunately our enterprise network is sufficiently different enough that the user cannot have a similar experience as they would at
RE: [WIRELESS-LAN] High client density WiFi?
I'm curious what info led you to see Cisco as lagging behind in this area? Although there may be differences within enterprise class wireless vendor's current hardware/feature sets, I think the success of a dense-client setup shifts an emphasis onto the constraints of the local environment and the support structure. We've successfully added to our Cisco infrastructure for such large one-time events. Your implementation sounds like it would be a permanent install. To me, the day in/day out support of a 500-1000 client space seems the larger hurdle compared to building it with today's technologies (given an appropriate budget). The hundreds of dynamic client radios/drivers are the more daunting aspect, and users will likely have more than one device. As one interfering source or misbehaving client can make it unsuccessful for many, I think overall success can become dependent on the ability to proactively support it. I assume there are others out there supporting such rooms day in/out today - any thoughts on that? Although we are a happy Cisco user, the Aruba VRD mentioned looks like a great resource - also nice to see it reinforce some things we've done. -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Palmer J.D.F. Sent: Tuesday, April 26, 2011 8:06 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] High client density WiFi? Hi, Apologies for the delay in replying the list, the long weekend break over Easter being the guilty party there. Thank you all so much for your replies, and some very interesting discussion too. The outlook for being able to achieve this is goal seems to be quite positive, it does appear that Cisco are behind the rest when it comes to providing this kind of service, which is a bit annoying as we've recently re-procured for .11n and the decision was to stay with Cisco. I expect there is the option that if Cisco not suitable to use an alternate vendor for these areas, though not ideal. Many thanks, Jezz. -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Palmer J.D.F. Sent: 21 April 2011 16:12 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] High client density WiFi? Hello, I've been posed a tricky question by someone on a planning committee for a new campus building. ...is it actually feasible for 500 simultaneous WiFi connections in a lecture room? I was hoping that there would be someone that might have experience of answering (or providing a solution to) such a question who could offer some input as to whether this is possible, or how close to the figure of 500 could we realistically achieve with the technology currently available? We are Cisco a site so ideally any solution would need to be one Cisco is capable of delivering, but if there are other vendors that are proven to be able to provide this kind of coverage to good effect, then I'd be glad to hear of your experiences. All the best, Jezz Palmer. - Jezz Palmer Library Information Services Swansea University Singleton Park Swansea SA2 8PP - ** 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/.
RE: [WIRELESS-LAN] High client density WiFi?
It's a tricky answer as I think every dense client situation is unique. From the start, if your client base supports it, using 802.11a will make it easier given more channels to make use of. 500 clients also includes 500 potential problems for everyone else. Although a special event, we do so every year as part of an conference event in a ~5000 sq ft concert hall. The event brings K12 students from around the state and culminates with an 'Uber' event in the concert hall where an online task is attempted. It has an advantage of having a nearly homogenous client base (Macbooks). To summarize quickly off the top of my head from what I remember: (I can look to dig up/send more info if desired) This is a one time event each year - we do not permanently mount the mentioned # of APs here as it's not needed otherwise. 2009: using 2.4 only (clients not 5G capable), I recall we achieved 650+ active users out of possible 800. ~20 Cisco 1240s (LWAPP) APs We tried to control using a combination of directional and omnis - conceded to just use omnis. Note: one bad client NIC caused some havoc due to a continuous high duty cycle which took a while to locate. 2010: Using 5G only significantly eased the process and we achieved ~850. Special SSID used campus wide - open along with web policy and a single local group account. ~23 APs in the concert hall - Cisco 1142s and a single 3502 and a single 1240 for any 2.4 only clients. These ran under 7.0.98.0 WLC code on a 4404. Most APs distributed under seats. Omni antennas only. 802.11N enabled. Included use of UNI-2e channels (clients were capable). Locked RRM DCA changes in the concert hall once stability perceived. Band-select enabled Client DHCP req'd (Cisco TeleP on a 30' screen was fun too.) 2011: For this year's event in May we'll duplicate much of what worked last year but using all 3502s. We'll aim to surpass last year's record and continue to improve proactive management. -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Palmer J.D.F. Sent: Thursday, April 21, 2011 11:12 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] High client density WiFi? Hello, I've been posed a tricky question by someone on a planning committee for a new campus building. ...is it actually feasible for 500 simultaneous WiFi connections in a lecture room? I was hoping that there would be someone that might have experience of answering (or providing a solution to) such a question who could offer some input as to whether this is possible, or how close to the figure of 500 could we realistically achieve with the technology currently available? We are Cisco a site so ideally any solution would need to be one Cisco is capable of delivering, but if there are other vendors that are proven to be able to provide this kind of coverage to good effect, then I'd be glad to hear of your experiences. All the best, Jezz Palmer. - Jezz Palmer Library Information Services Swansea University Singleton Park Swansea SA2 8PP - ** 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] Non-Java network speed test server?
There are both iperf and NDT mobile apps for android. NDT app would be nicer if one could define which NDT server to go against , so one could go against a local server. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman Sent: Monday, March 14, 2011 11:01 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Non-Java network speed test server? We are running Visual Ware and occasionally the I2 speed testing tools locally for giving users a way to measure their own network speeds within our network borders. These generally work fine, but am finding limits with iDevices and Android where Java support isn't available. Is anyone using a non-Java speedtest utility locally (not on the Internet) that they can recommend? I am aware of the Visualware app that works on iDevices- not a good fit for a couple of reasons. Ideally would be a simple URL-based utility for handhelds.' Thanks- Lee Badman Lee H. Badman Wireless/Network Engineer Information Technology and Services Adjunct Instructor, iSchool Syracuse University 315 443-3003 ** 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] Guest Wireless Questions
Hi Tom, As we are a public institution, we feel it's desirable to provide a level of public network access. We have been trialing such an (unfunded) service for while now using existing equipment/resources. A Cisco shop, campus controllers have the open SSID tied to a mobility tunnel configured to a central 'guest' controller where all traffic is passed through CIPA-compliant content filtering, some specific filtering, logging, and is bw-limited on a per-host basis. As the traffic does utilize university resources, the service is at our control to operate (filter/log/disable) as we feel necessary. Being open, it is simpler for the community/conference attendees/contractors to connect to which eliminates the need for maintaining special/one-off IDs and as importantly helps dissuade such clients from acquiring access by other means through local contacts. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Neiss, Tom Sent: Friday, July 02, 2010 8:02 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Guest Wireless Questions Are you providing free guest wireless access on your campus? How are you dealing with CALEA if you are? Do you use your edu address? Thanks, Thomas R. Neiss Director of ITS Telecommunications University at Albany 1400 Washington Ave Albany, NY 1 (518) 437-3803 ** 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] Hacking Cisco WLC - macfilters
Hi Randy - I'll send you the snippet of code off list. To answer your question for the list - yes, a last resort, but it can also depend on the issue. ex. Those identified as being compromised or those exhibiting malicious behaviors are immediately blocked. Notices are sent to local IT entities as part of the disabling process who have some users with the ability to free disabled hosts. The case you mention of replacing a device when quarantined is unfortunate, but local policies are posted and various methods of access to IT support is provided which you'd hope they would think to make use of before buying new hardware. (works everywhere but at school, but yet my friends do not have any trouble..hmmm.) From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Randall C Grimshaw Sent: Friday, April 16, 2010 9:06 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Hacking Cisco WLC - macfilters I would be interested in the code from a curiosity perspective, but I also wanted to ask how this is received from a user perspective. Is this a feature that you use as a last resort? We have always bent over backwards to attempt (as much as practical) to steer the user into a web page that tells them what the problem is. We have legacy stories of kids asking dad for a new computer because theirs was quarantined. Randy From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Garry Peirce Sent: Thursday, April 15, 2010 2:06 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Hacking Cisco WLC - macfilters Mike, I manage Cisco controller exclusions via SNMP. We have a homegrown IPAM system which includes a checkbox to be able to disable a machine. Doing so for a wireless host causes this to create an exclusion entry which is then distributed system-wide preventing the host from associating. When this box is unchecked, the entry gets removed (database change, cron process, script runs.) In a nutshell. I've scraped some parts of a script I wrote depicting the insert/removal operation. So as not to include here as an attachment, I'll send it to you directly - if other's would like it, just send me a note. As I scraped from different sections of the script, it may require some re-working to make it run. This might give you something to work with to create a script to purge your entries, but you'll need a way to determine the entries age. I actually include the date of the exclusion in the description field. Then you just have to run it once a month. Btw - you may want to increase the size of the WLC database should you have a large number of excluded addresses. 'config database size 512-2048' From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Schomer, Michael J. Sent: Thursday, April 15, 2010 10:45 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Hacking Cisco WLC - macfilters Although we encourage all wireless devices to connect via WPA/WPA2 802.1x, not all wireless devices support these standards. To accommodate consumer level wireless devices, such as game consoles, we created a separate WPA PSK network. We manually approve each request by adding a mac filter exclusion to that particular network. In the beginning we did all these requests manually, either by entering them directly into each WLC or by using templates in WCS. Eventually, the number of requests necessitated the need to semi-automate the process. We created a web form to gather the information; on the administrator side we could approve or deny each request. Approving the request would run a scripted telnet session to each WLC adding the macfilter. For security and stability reasons we didn't want to continue using scripted telnet sessions. We figured out how to script an https session on the controllers using HTTP GET. This solution is working much better; however we have not found a good way of removing macfilters from the controllers, using this method. (The way the web interface works for removing macfilters is pretty convoluted and would be difficult to script.) We want to run a script once a month that will remove all macfilters a year or more old. So, long story short, has anyone done anything like this? Any suggestions for removing old macfilters? Thanks. -Mike Schomer -ResNet Coordinator -St. Cloud State University ** 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
RE: [WIRELESS-LAN] Hacking Cisco WLC - macfilters
Mike, I manage Cisco controller exclusions via SNMP. We have a homegrown IPAM system which includes a checkbox to be able to disable a machine. Doing so for a wireless host causes this to create an exclusion entry which is then distributed system-wide preventing the host from associating. When this box is unchecked, the entry gets removed (database change, cron process, script runs.) In a nutshell. I've scraped some parts of a script I wrote depicting the insert/removal operation. So as not to include here as an attachment, I'll send it to you directly - if other's would like it, just send me a note. As I scraped from different sections of the script, it may require some re-working to make it run. This might give you something to work with to create a script to purge your entries, but you'll need a way to determine the entries age. I actually include the date of the exclusion in the description field. Then you just have to run it once a month. Btw - you may want to increase the size of the WLC database should you have a large number of excluded addresses. 'config database size 512-2048' From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Schomer, Michael J. Sent: Thursday, April 15, 2010 10:45 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Hacking Cisco WLC - macfilters Although we encourage all wireless devices to connect via WPA/WPA2 802.1x, not all wireless devices support these standards. To accommodate consumer level wireless devices, such as game consoles, we created a separate WPA PSK network. We manually approve each request by adding a mac filter exclusion to that particular network. In the beginning we did all these requests manually, either by entering them directly into each WLC or by using templates in WCS. Eventually, the number of requests necessitated the need to semi-automate the process. We created a web form to gather the information; on the administrator side we could approve or deny each request. Approving the request would run a scripted telnet session to each WLC adding the macfilter. For security and stability reasons we didn't want to continue using scripted telnet sessions. We figured out how to script an https session on the controllers using HTTP GET. This solution is working much better; however we have not found a good way of removing macfilters from the controllers, using this method. (The way the web interface works for removing macfilters is pretty convoluted and would be difficult to script.) We want to run a script once a month that will remove all macfilters a year or more old. So, long story short, has anyone done anything like this? Any suggestions for removing old macfilters? Thanks. -Mike Schomer -ResNet Coordinator -St. Cloud State University ** 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] Cisco WCS Issue
You might open a TAC case as all scenarios are different, perhaps especially when it comes to RRM. But as your issue sounds similar to one I had when upgrading my controllers this past October, you might check your DCA sensitivity. The threshold for channel changes was lowered at one point making channel changes significantly more frequent for me. I altered my settings back to 'low' which I had to do on each controller itself - I could not do so through WCS. On the controller: Wireless..802.11x...RRM..DCA...'DCA Channel sensitivity' My issues with this problem tend to revolve around a lack of rogue AP enforcement. Knowing about them is one thing - physically locating them can be much harder. You can change to less frequent automatic channel assignments (or manual periodic ones) instead of trying to be a nice neighbor, but it might just shift the problem to the clients where they will suffer and the problem will be less visible. -- -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Timothy Payne Sent: Monday, January 25, 2010 10:17 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Cisco WCS Issue Good morning! Last year, we were seeing a lot of APs flopping up and down as they changed channels or power levels (per the consultant) for no reason. At that time, we upgraded to 5.2.148.0 and the issues mostly went away, and the ones that remained we were able to work around and planned to replace those APs in our next budget cycle. Our consultant indicated that there are still some issues with this with the new code and old APs. Today, we ran a report of all the 'down/up' events for all the APs and we had around 350 over the last 12 hours. We have around 200 APs, so that average seems to be high. That leads to two questions: 1) Does anyone know of a way to make the report indicated WHY it went 'down/up'? 2) How many times do you see your APs changing channels? My thought is that dynamically they should be changing all the time as load and interference change, but I can't find any documentation to address that. Thanks! Tim Payne, CISSP, CISM, CCNA Network Administrator Macalester College ** 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/. attachment: Garry_Peirce.vcf
RE: [WIRELESS-LAN] MAC - Cisco DTPC
Thanks Jeff, Yes, disabling the 'remember networks' option, I now see it prefers the 2.4G signal. If you want the Macs to stick with 5G, then you'll need to create a different SSID from the 2.4G e.g. main-a, main-g so that it will always be on 5G. Actually I found out that Cisco has a feature that will selectively prefer probe requests from dual band clients to help persuade clients to one radio or the other. I've yet to test it but appears in 6.0.182 via CLI as 'config band-select' and can be enabled on a per-WLAN basis which I found also mentioned here: http://www.cisco.com/en/US/solutions/collateral/ns340/ns394/ns348/ns767/farp ointWLAN_strategies_wp.pdf -- -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Jeffrey Sessler Sent: Tuesday, November 03, 2009 2:48 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] MAC - Cisco DTPC Garry, It's world-mode (config 802.11a world-mode) and not DTPC (config 802.11a dtpc) that influenced the Mac client power bug on 5G, but the point is correct that the latest 5.2 (which has a controller setting now for world-mode) and 6.0 (does not have the setting) seem to have resolved the issue so the need to disable world-mode is no longer needed. The Mac initially prefers the 2.4G radio over 5G (given same SSID) unless the RSSI is compelling enough for it to do otherwise, and this is unlikely if the source of the two are from the same AP. I have however noticed that our Macs in the residential halls will transition from 2.4G to 5G if they've been stationary for a certain amount of time, and may suggest that there is some logic behind the scenes. That said, if remember networks is enabled, and say a Mac Laptop was last on a 5G radio when put to sleep, it does seem to attempt a connection to 5G when awaken. You can influence the Mac's behavior by modifying the pref's file, and removing all 2.4G references and including just 5G information. Unfortunately, once it connects to 5G and scans again, it will insert the 2.4G information it finds back into the prefs file. If you want the Macs to stick with 5G, then you'll need to create a different SSID from the 2.4G e.g. main-a, main-g so that it will always be on 5G. Jeff Garry Peirce pei...@maine.edu 11/2/2009 8:47 AM To follow up on a previous posting, I'd heard back from Cisco re: world-mode/DTPC. The SE had inquired with the system engineering group. They reported that they had not experienced any issues with MAC clients since they upgraded to the latest release of 5.2. They have therefore left DTPC at default. Which is how I have left it although I run 6.0.182. In that thread, there was also talk of an Apple/Broadcom driver bug. Reviewing that, it looks to me like there may still be an issue in selecting an available 5G radio. I have a Mac running 10.5.7 using a Broadcom based card w/driver 50.10.38.35. If I disable my 5G radio on a Cisco LW AP (1142 running 6.0.182), the client immediately re-associates to the 2.4G radio. When I re-enable the 5G radio, the Mac remains connected to the 2.4G service. I have to disable/re-enable the Mac's Airport card to regain connectivity to it where it will then immediately connect (bonding channels 64/63 and using the 800ns SGI). The plist file does appear to record the 2.4G channel used but not 5G channels. Does anyone know if this is an intended behavior or if the Mac should prefer the 5G over 2.4G radio? -- -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Garry Peirce Sent: Thursday, October 15, 2009 5:11 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Self-assigned IP on Macs Perhaps I was erroneous in equating the two through a Cisco doc referencing DTPC to world-mode. 'When you enable Dynamic Transmit Power Control (DTPC), access points add channel and transmit power information to beacons. (On access points that run Cisco IOS software, this feature is called world mode.)' DTPC does appear to be CCX related, so it is likely irrelevant with regard to the mentioned Apple/Broadcom bug. Running 6.0.182, 'config 802.11a world-mode' is not an available option. 'config 802.11a dtpc' is. 'show 802.11a' will show the status of DTPC. I'll inquire w/Cisco. -- -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Matt Grover Sent: Thursday, October 15, 2009 2:51 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Self-assigned IP on Macs It's under: show 802.11a(or b) -Matt Bob Richman wrote: So, how about the show command that displays
RE: [WIRELESS-LAN] MAC - Cisco DTPC
To follow up on a previous posting, I'd heard back from Cisco re: world-mode/DTPC. The SE had inquired with the system engineering group. They reported that they had not experienced any issues with MAC clients since they upgraded to the latest release of 5.2. They have therefore left DTPC at default. Which is how I have left it although I run 6.0.182. In that thread, there was also talk of an Apple/Broadcom driver bug. Reviewing that, it looks to me like there may still be an issue in selecting an available 5G radio. I have a Mac running 10.5.7 using a Broadcom based card w/driver 50.10.38.35. If I disable my 5G radio on a Cisco LW AP (1142 running 6.0.182), the client immediately re-associates to the 2.4G radio. When I re-enable the 5G radio, the Mac remains connected to the 2.4G service. I have to disable/re-enable the Mac's Airport card to regain connectivity to it where it will then immediately connect (bonding channels 64/63 and using the 800ns SGI). The plist file does appear to record the 2.4G channel used but not 5G channels. Does anyone know if this is an intended behavior or if the Mac should prefer the 5G over 2.4G radio? -- -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Garry Peirce Sent: Thursday, October 15, 2009 5:11 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Self-assigned IP on Macs Perhaps I was erroneous in equating the two through a Cisco doc referencing DTPC to world-mode. 'When you enable Dynamic Transmit Power Control (DTPC), access points add channel and transmit power information to beacons. (On access points that run Cisco IOS software, this feature is called world mode.)' DTPC does appear to be CCX related, so it is likely irrelevant with regard to the mentioned Apple/Broadcom bug. Running 6.0.182, 'config 802.11a world-mode' is not an available option. 'config 802.11a dtpc' is. 'show 802.11a' will show the status of DTPC. I'll inquire w/Cisco. -- -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Matt Grover Sent: Thursday, October 15, 2009 2:51 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Self-assigned IP on Macs It's under: show 802.11a(or b) -Matt Bob Richman wrote: So, how about the show command that displays the current setting? -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Matt Grover Sent: Thursday, October 15, 2009 1:21 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Self-assigned IP on Macs Actually, if you are talking about specifically world-mode it's under: CLI: config 802.11a world-mode orconfig 802.11b world-mode -Matt -- Matt Grover === University of Florida Sr. Network Engineer=== http://net-services.ufl.edu m...@ufl.edu=== Florida Lambda Rail (352)273-1061 === http://www.flrnet.org/ ** 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/. attachment: Garry_Peirce.vcf
RE: [WIRELESS-LAN] Self-assigned IP on Macs
Perhaps I was erroneous in equating the two through a Cisco doc referencing DTPC to world-mode. 'When you enable Dynamic Transmit Power Control (DTPC), access points add channel and transmit power information to beacons. (On access points that run Cisco IOS software, this feature is called world mode.)' DTPC does appear to be CCX related, so it is likely irrelevant with regard to the mentioned Apple/Broadcom bug. Running 6.0.182, 'config 802.11a world-mode' is not an available option. 'config 802.11a dtpc' is. 'show 802.11a' will show the status of DTPC. I'll inquire w/Cisco. -- -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Matt Grover Sent: Thursday, October 15, 2009 2:51 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Self-assigned IP on Macs It's under: show 802.11a(or b) -Matt Bob Richman wrote: So, how about the show command that displays the current setting? -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Matt Grover Sent: Thursday, October 15, 2009 1:21 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Self-assigned IP on Macs Actually, if you are talking about specifically world-mode it's under: CLI: config 802.11a world-mode orconfig 802.11b world-mode -Matt -- Matt Grover === University of Florida Sr. Network Engineer=== http://net-services.ufl.edu m...@ufl.edu=== Florida Lambda Rail (352)273-1061 === http://www.flrnet.org/ ** 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] WiSM 6.0.182.0
Might you have proxy-dhcp enabled (is by default) on the controllers? I ran into bug CSCsx96815 when I went to 5.2.157 in the past which caused clients to not receive an address (the virtual address was corrupted through an upgrade). -- Garry Peirce +1-207-561-3539 Network Analyst, ITS University of Maine System -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Lee H Badman Sent: Thursday, August 20, 2009 10:46 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] WiSM 6.0.182.0 Peter, Can you describe your bus implementation in more detail? -Lee -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Peter Arbouin Sent: Wednesday, August 19, 2009 11:14 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] WiSM 6.0.182.0 Hi, We also upgraded to 6.0 We have several aps on busses using HREAP. For some reason clients were not able to get a valid ip and we had to revert to the previous version of code. Anyone else seen this issue? Another issue is some random hosts have issues getting an ip address by DHCP in some locations, but work fine in other locations. The WCS interface is far better than previous versions. Peter. -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Procyk, Ian Sent: Thursday, 6 August 2009 5:11 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: 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/. ** 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] WiSM 6.0.182.0
More germane to the subject, I meant to add that we began to upgrade to 6.0.182 since released without issue. I've a handful of APs using HREAP on these controllers (traffic is locally switched) as well. -- Garry Peirce Network Analyst, ITS University of Maine System -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Garry Peirce Sent: Thursday, August 20, 2009 6:28 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] WiSM 6.0.182.0 Might you have proxy-dhcp enabled (is by default) on the controllers? I ran into bug CSCsx96815 when I went to 5.2.157 in the past which caused clients to not receive an address (the virtual address was corrupted through an upgrade). -- Garry Peirce +1-207-561-3539 Network Analyst, ITS University of Maine System -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Lee H Badman Sent: Thursday, August 20, 2009 10:46 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] WiSM 6.0.182.0 Peter, Can you describe your bus implementation in more detail? -Lee -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Peter Arbouin Sent: Wednesday, August 19, 2009 11:14 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] WiSM 6.0.182.0 Hi, We also upgraded to 6.0 We have several aps on busses using HREAP. For some reason clients were not able to get a valid ip and we had to revert to the previous version of code. Anyone else seen this issue? Another issue is some random hosts have issues getting an ip address by DHCP in some locations, but work fine in other locations. The WCS interface is far better than previous versions. Peter. -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:wireless-...@listserv.educause.edu] On Behalf Of Procyk, Ian Sent: Thursday, 6 August 2009 5:11 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: 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/. ** 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/.
