Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root
Upon closer inspection, I believe that my fears were overblown. It seems that what ACTUALLY changed in the certificate was the friendly name, and the root CA is still the same. I only discovered this when I imported the 'new' root CA into our eduroam CAT config and saw that all of the properties appeared to be the same. When viewed with the Windows built-in certificate viewer, our certificate chain appears as: Sectigo (AAA) - CN = AAA Certificate Services |__ CN = USERTrust RSA Certification Authority |__CN = InCommon RSA Server CA |__connect.fandm.edu If I view the details on the Sectigo (AAA) certificate, it shows as issued to and by 'AAA Certificate Services,' which does match the 'old' root CA. The following screenshots are provided to highlight the source of my confusion: [image: image.png] [image: image.png] [image: image.png] All of the certificates in the chain have friendly names that match their CN's, except for the root. Nevertheless, since we've gone this far, we are going to issue a new certificate to both appliances so that they at least match. I expect that most clients will need to forget and re-add the network, but our existing eduroam CAT config will work. At the moment, our desktop support personnel are pushing back on moving to a private CA due to the difficulty with onboarding MacOS clients specifically, though they are also not super-thrilled with the process for iOS devices. We understand that this is due to how the client OS handles installing these profiles, and are hoping that using a different onboarding tool will make the process bearable for users and help desk staff when we do roll to a private CA, currently planned for next summer. We were able to stand up a PoC Private CA, thanks in very large part to the input that we received here. I greatly appreciate everyone's input in this thread, and the encouragement and information that is helping us to move to where we need to be. This has been, and continues to be, a valuable learning experience. Jonathan Miller Senior Network Analyst Franklin and Marshall College On Fri, Aug 13, 2021 at 2:37 PM Jonathan Waldrep wrote: > Going back to the original issue: > > On 2021-08-09 07:32:19-0400, Jonathan Miller wrote: > > [...] > > The certificate are issued through InCommon, and when I renewed our > > expiring certificate, I noticed that it is showing that is has a root > > of Sectigo, where it was previously Comodo. The certificate that is > > not expiring has a root CA of Comodo. > > [...] > > InCommon also issues our certificates†. Specifically, our certs are > signed by [this][1] certificate, with CN "InCommon RSA Server CA". This > intermediate cert is then signed by [this][2] certificate with CN > "USERTrust RSA Certification Authority", which is a root certificate. > > Not counting CAs hiding their name because of a bad reputation, I don't > see "Comodo" or "Secitgo" anywhere in the chain. This has been our chain > for a while. I've had some other certs issued this week with the same > chain. > > What are the subject and issuer CNs for the certs you are using? It > kinda sounds like they are just giving you an alternate chain, which can > be a real pain to sort out. > > †I know, I know. We should use an internal CA. We're working on it. > > [1]: http://crt.usertrust.com/InCommonRSAServerCA_2.crt > [2]: http://crt.usertrust.com/USERTrustRSAAddTrustCA.crt > > -- > Jonathan Waldrep > Network Engineer > Network Infrastructure and Services > Virginia Tech > > ** > Replies to EDUCAUSE Community Group emails are sent to the entire > community list. If you want to reply only to the person who sent the > message, copy and paste their email address and forward the email reply. > Additional participation and subscription information can be found at > https://www.educause.edu/community > ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community
Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New Root
Thank you all for the informative replies. As is probably obvious, when we initially rolled this out, we were completely unaware of the best practices, and are currently working to correct that and get our infrastructure where it should be. We do not have an in-house PKI expert, but we are not completely unfamiliar with OpenSSL. We do not currently have any internal CA as we've just used InCommon for all of our certificate needs. If we want to do this right, my understanding is that the process is to: 1. Create a Root CA with a long-lived certificate 2. Create a certificate for our ClearPass servers, signed by that Root CA, making sure to include the attributes listed here: https://wiki.geant.org/display/H2eduroam/EAP+Server+Certificate+considerations 3. Apply the certificate to ClearPass and distribute our new Root CA via CAT or other means Would we be crazy to try to accomplish this inside of the 2 weeks that we have before students start to return to campus? Any advice is appreciated, just trying to steer this boat away from the iceberg. Thanks, Jonathan Miller Senior Network Analyst Franklin and Marshall College On Mon, Aug 9, 2021 at 12:12 PM Jeffrey D. Sessler wrote: > CA’s have done nothing is fifteen plus years, so from a risk management > perspective, the chance of them changing course now is rather low. As to > future RFCs, even if that happened tomorrow, it could be a decade or more > before there was broad support, and more importantly, we could think about > enforcement. > > > > Jeff > > > > > > *From:* The EDUCAUSE Wireless Issues Community Group Listserv < > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Tim Cappalli > *Sent:* Monday, August 09, 2021 8:05 AM > *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > *Subject:* Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New > Root > > > > CA policies really have nothing to do with implementations of other > protocols. There have been many discussions about this on this list and > others, and a future RFC will likely include further clarity. However, as > I've said in the past, RFCs do not dictate CA/B policies. > > > > If we're going to continue this discussion, we should fork a new thread as > it has nothing to do with the original question. > > > > tim > -- > > *From:* The EDUCAUSE Wireless Issues Community Group Listserv < > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Jeffrey D. Sessler < > j...@scrippscollege.edu> > *Sent:* Monday, August 9, 2021 10:53 > *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU < > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > *Subject:* Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New > Root > > > > Per the RFC, the certificate-using application _*MAY*_ require the EAP > extended key usage extension to be present. It is not a must or shall, so > I’m not exactly sure the problem here. Vendors have chosen against > requirement. > > > > The certificate-using application appears to be satisfied by the server > authentication EKU, which is appropriate, and I don’t see why the public CA > would consider it a misuse and invalidate it. > > > > As others have indicated, this is the de facto, and right or wrong, it’s > not going to change and not worth getting stirred up about. > > > > jeff > > > > *From: *The EDUCAUSE Wireless Issues Community Group Listserv < > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Doug Wussler < > 029e57f9967b-dmarc-requ...@listserv.educause.edu> > *Date: *Monday, August 9, 2021 at 7:33 AM > *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU < > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > *Subject: *Re: [WIRELESS-LAN] eduroam CAT Config/Cert Renewal with New > Root > > Well, here is Microsoft's take on it... > > > > > https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/certificate-requirements-eap-tls-peap > <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftroubleshoot%2Fwindows-server%2Fnetworking%2Fcertificate-requirements-eap-tls-peap=04%7C01%7CJeff%40scrippscollege.edu%7Cc8f0083e79e44aa4d7e608d95b4716a9%7C47274664281d4e3282489661a922b78c%7C0%7C0%7C637641183177714995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=hx1WCuagh9lX9pNwIudcw%2F%2B1L9iNEOFO13obhaS%2FJJo%3D=0> > > > > [image: Image removed by sender.] > <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftroubleshoot%2Fwindows-server%2Fnetworking%2Fcertificate-requirements-eap-tls-peap=04%7C01%7CJeff%40scrippscollege.edu%7Cc8f0083e79e44aa4d7e608d95b4716a9%7C47274664281d4e3282489661a922b78c%7C0%7C0%7C637641183177724
eduroam CAT Config/Cert Renewal with New Root
We are currently using publicly signed certificates for our eduroam access on a cluster of 2 ClearPass servers. We are in a situation where one of our certs will be expiring in October of this year, while the other is good until June of next year. The certificate are issued through InCommon, and when I renewed our expiring certificate, I noticed that it is showing that is has a root of Sectigo, where it was previously Comodo. The certificate that is not expiring has a root CA of Comodo. This leads me to the following questions: 1. Is it advisable to run certificates with different Root CAs on different members of our ClearPass cluster? Would we expect to see client issues? 2. If it's not a problem to do this, can I simply add the Root CA for Sectigo to our eduroam CAT configuration, or is there only one Root CA allowed? Any other advice is appreciated. I understand that most institutions are moving to privately issued certificates in order to get control of these certificate chain issues, but we haven't quite gotten there yet. Our plan to properly onboard clients is to use an SSID with a captive portal to direct them to the eduroam CAT download. Thanks, Jonathan Miller Senior Network Analyst Franklin and Marshall College ** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community
Re: [WIRELESS-LAN] MAC Randomization, a step further...
For those of us using ClearPass to authenticate users to eduroam, does this mean that every iOS device will get registered as a new endpoint every day? For others, does your NAC store a client's MAC persistently? I'm assuming that the answer to both is yes. How can we plan for the impact of that on our databases? Should we delete all iOS and Android devices after 48 hours? Am I missing something obvious? Jonathan Miller Senior Network Analyst Franklin and Marshall College On Fri, Jul 10, 2020 at 4:37 PM Enfield, Chuck wrote: > PS – My plan for supporting our guest network will be to tell any user who > contacts us with an Apple device that the network is fine and they should > contact Apple for device support. I can’t get away with that for our > enterprise network, but Apple is going to own the guest problem. > > > > *From:* The EDUCAUSE Wireless Issues Community Group Listserv < > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Enfield, Chuck > *Sent:* Friday, July 10, 2020 4:34 PM > *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further... > > > > My point wasn’t to debate Passpoint either. I’m wondering if Apple > actually has a plan, and if so, if they’ve bothered to tell anybody. > > > > *From:* The EDUCAUSE Wireless Issues Community Group Listserv < > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Tim Cappalli > *Sent:* Friday, July 10, 2020 4:22 PM > *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further... > > > > Passpoint is not just about mobile network operators. Any identity > provider can provision a Passpoint profile. That is the whole drive behind > OpenRoaming. The industry goal is that every user has at least 2 Passpoint > profiles on their devices: one tied to their enterprise/school identity and > the other tied to a personal identity. The traditional enterprise/school > onboarding process stays largely the same, except some additional Passpoint > logic is added. > > > > Mobile network operators / cell providers are only one (optional) piece of > the puzzle. > > > > Probably should start a separate thread for anything deeper on Passpoint > beyond it being a solution for network access. Don’t want to take away from > the OG conversation. > > > > tim > > > > *From: *The EDUCAUSE Wireless Issues Community Group Listserv < > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > *Date: *Friday, July 10, 2020 at 16:17 > *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU < > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > *Subject: *Re: [WIRELESS-LAN] MAC Randomization, a step further... > > Understood, but few Wi-Fi operators actually support Passpoint on their > networks. Since Apple is eliminating the alternatives, they either must be > idiots (my bet) or have a proposal for what we should all being doing > instead. > > > > I still get really confused looks when I try to discuss Passpoint with my > contacts at the major cellular providers, so it can’t possibly be a > realistic option for most of us. > > > > *From:* The EDUCAUSE Wireless Issues Community Group Listserv < > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Tim Cappalli > *Sent:* Friday, July 10, 2020 4:07 PM > *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further... > > > > Not sure I follow. Passpoint is an industry-wide solution for secure Wi-Fi > roaming. Passpoint has been supported on iOS and macOS (along with Windows > and Android) for a number of years. > > > > I definitely don’t follow this comment: “you can’t onboard your Apple to > enable identity-based auth.” > > > > tim > > > > > > *From: *The EDUCAUSE Wireless Issues Community Group Listserv < > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > *Date: *Friday, July 10, 2020 at 16:04 > *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU < > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > *Subject: *Re: [WIRELESS-LAN] MAC Randomization, a step further... > > So you can’t use an Apple MAC address for guest auth, and you can’t > onboard your Apple to enable identity-based auth. Apple must be thinking > that they can drag the entire world, kicking and screaming, into federated > authentication that Apple products ship knowing how to do (Passpoint, > openroaming, etc.). Do they have a proposal for this that I missed? > > > > *From:* The EDUCAUSE Wireless Issues Community Group Listserv < > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Rios, Hector J > *Sent:* Friday, July 10, 2020 2:56 PM > *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > *Subject:* [WIRELESS-LAN
Re: [WIRELESS-LAN] Theater wifi - to have or not to have
> Some of this can be affected by the architect and what they deem aesthetically pleasing... This is one of the few things that actually still gets under my skin in this line of work. Architects refusing to allow the installation of access points due to aesthetics is ludicrous. We recently ran into this - even after presenting options for mounts and covers to hide our APs in a new building. What about that big red fire alarm horn/strobe, are you not going to allow that? When the complaints about poor wireless performance come in, will you, oh great architect and designer of all things beautiful, come in and help us troubleshoot? How will it make you feel when we have to slap wire mold all over your glorious aesthetically pleasing creation to run data out to the APs that we end up having to install after you turn the building over to us? I guess as long as the wire mold isn't there for the opening ceremony it doesn't matter. If you happen to be in a position that has enough power to push back on architects and their asinine refusal to allow installation of access points, please back your local networking folks. OK, back to some deep breathing exercises. Jonathan Miller Network Analyst Franklin and Marshall College On Thu, Oct 24, 2019 at 1:50 PM Ronald Loneker wrote: > Good Afternoon - > > Some of this can be affected by the architect and what they deem > aesthetically pleasing... > > When our theater was built in our fine and performing arts center 12 years > ago, the architect was against us putting access points on the wall due to > aesthetics. We ended up putting on AP in our projection booth and one > backstage in one of the wings. > > Our theater was originally slated to be used for all purposes > (performances, concerts, lectures, conference presentations, admissions > Open Houses, etc) so it really could have used a lot more connectivity than > what we could put in the theater. > > Three years ago, we upgraded the APs in the fine and performing arts > center and, with new leadership at the college, added three more access > points to support more connections. Our theater has 560 seats, and we did > have a conference that we streamed video plus had public wifi available and > we seem to be fine with connectivity. > > If you can do it and not get pushback from the architect, I'd recommend > you build it into your plans for having availability day one. > > (then you can sit in the back of the theater and watch all the parents > with their smart phones raising them up and see the sea of phone screens as > they record their kids' performances...because it will happen when you > eventually rent out the space...) > > Ron Loneker, Jr. > Director, IT Special Projects > College of Saint Elizabeth > Mahoney Library > 2 Convent Road > Morristown, NJ 07960 > > Phone: 973-290-4229 > > e-mail: rlone...@cse.edu > > > > > > > > On Tue, Oct 22, 2019 at 12:44 PM Bull, Mary wrote: > >> Hello all, >> >> >> >> I’m wondering if anyone here has dealt with a decision on wireless in the >> theaters, concert halls, or recital halls on their campus. We have a new >> arts complex coming on line in the next two years and there’s no clear >> direction from faculty on whether wireless for the audience is desirable. >> The previous main theater, and other currently used theaters on campus, >> did/do not have full connectivity for the audience (just a few aps tacked >> on the walls that were useless when the room was full). Facilities planning >> is favorable toward building it in, so I’d prefer that too, especially >> since it would be much harder or impossible to install if the faculty >> changes their mind in a few years once the building is complete. However, >> I’m not sure whether there is really an expectation from the audience that >> they should have wifi when they attend a show or concert. >> >> >> >> Has anyone dealt with this on their campus? What influenced your choice? >> >> >> >> Mary Bull >> >> William and Mary >> >> 757-221-2491 >> >> mb...@wm.edu >> >> ** >> Replies to EDUCAUSE Community Group emails are sent to the entire >> community list. If you want to reply only to the person who sent the >> message, copy and paste their email address and forward the email reply. >> Additional participation and subscription information can be found at >> https://www.educause.edu/community >> > ** > Replies to EDUCAUSE Community Group emails are sent to the entire > community list. If you want to reply only to the person who sent the > message, copy and paste their email address and forward the email reply. >
Re: [WIRELESS-LAN] Aruba OS 6.5.X
We went to 6.5.3.2 for a fix to AirGroup, and hit the datapath timeout SoS crash on Sunday afternoon. TAC is reviewing our logs, they are curious about the high amount of untrusted unicast traffic in our network. Jonathan Miller Network Analyst Franklin and Marshall College On Mon, Sep 25, 2017 at 10:28 PM, Wesley Troy Scott <tsc...@uwyo.edu> wrote: > We ran into the SOS Assert crash too and the workaround was to disable > Deep Packet Inspection. Since then we've been stable. > -- > *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv < > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Johnson, Christopher < > cbjo...@ilstu.edu> > *Sent:* Monday, September 25, 2017 12:06:15 PM > *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > > *Subject:* Re: [WIRELESS-LAN] Aruba OS 6.5.X > > > We’re also on 6.5.3.1 and have ran into the “Reboot Cause: Datapath > timeout (SOS Assert) (Intent:cause:register 54:86:50:2) “ message with an > open TAC case. Something else I’d be curious about – for those of your > running 6.5.3.1 – could you verify via packet-capture that your configured > data rates match what your APs are actually broadcasting. We’ve recently > discovered during a packet-capture that our APs had the default 1,2, 5, and > 11 rates enabled – even though the controllers have those specifically > disabled via the running-config and webUI. Note this only affected on pair > of our 7240 controllers – but not another separate pair. > > > > *Christopher Johnson* > > Wireless Network Engineer > > AT Infrastructure Operations & Networking (ION) > > Illinois State University > > (309) 438-8444 > > Stay connected with ISU IT news and tips with @ISU IT Help on Facebook > <https://www.facebook.com/ISUITHelp/> and Twitter > <https://twitter.com/ISUITHelp> > > *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto: > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Jake Snyder > *Sent:* Saturday, September 23, 2017 8:13 PM > *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > *Subject:* Re: [WIRELESS-LAN] Aruba OS 6.5.X > > > > We had some issues with the controllers crashing on 6.5.2.1. 6.5.3.2 has > been solid for the same client. > > > > Sent from my iPhone > > > On Sep 22, 2017, at 1:55 PM, Brian L. Cox <cox...@unk.edu> wrote: > > For whatever it is worth, we are going to go from 6.5.2.0 to 6.5.3.2 > conservative release per TAC recommendation > > > > Brian > > > > *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [ > mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] *On Behalf Of *Michael Hulko > *Sent:* Friday, September 22, 2017 2:06 PM > *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > *Subject:* Re: [WIRELESS-LAN] Aruba OS 6.5.X > > > > I stand corrected… we are experiencing - Reboot Cause: Datapath > timeout (SOS Assert) (Intent:cause:register 54:86:50:2) associated with > bug ID: 168710 > > > > Cause: "contents in datapath is not freed. New streams are not allocated > with resources to categorize. Due to this duplicate session deletes were > not happening and hence the controller was crashing.” > > > > > > This appears to happen when the controllers reach over 9k users. > > > > We have been experiencing AP103H reboots since 6.4.4.x code base as well > as increased number of radar events. These were supposed to be fixed > moving to 6.5.4x code. > > > > We have over 4600 APs on Campus (105, 215, 225, 315,103H, 205H) > > > > M > > > > > > > > On Sep 22, 2017, at 12:21 PM, Colin Randall <crand...@mines.edu> wrote: > > > > We’re running 6.5.2.1 as well, without any issues. That said, we’re > running mostly AP-225’s and a few AP-335’s, and not running the DFS > frequencies at all. > > -Colin > > > Colin Randall > > Network Manager > > Colorado School of Mines > > 303-384-2208 <(303)%20384-2208> > > > > On Sep 22, 2017, at 9:18 AM, Amel Caldwell <am...@uw.edu> wrote: > > > > > Did they say what the release will be? Will it be 6.5.2.1 or are they > going to expect you to jump to 6.5.3 or 6.5.4? We often request fixes to > be put in older versions to minimize risk of going to a whole other train > of code. > > > > I am curious because I was told 6.5.2 had been “parked”. > > > > Amel Caldwell > > University of Washington UW-IT > > Wi-Fi Network Engineer > > Wi-Fi Service Manager > > > > am...@uw.edu > > 206-543-2915 <(206)%20543-2915> > > > > Ask me about open
Re: [WIRELESS-LAN] Dynamic vs Static Channel Plans
Todd, The Aruba equipment reports a radar event once in a while for channel 144; we are assuming that it's because we are close to a small airport. Even if it were a false positive, I'm not inclined to try to use the channel if there is a chance that clients will get knocked off. Based on the info that others have posted here, I think I'd avoid 144 even if we weren't near an airport. Learn something new every day! The best practice with ARM right now is to set it to a range of 3-6 dBm for Tx power. The general wisdom, we are told, is that this prevents having a few APs that start screaming and others that back way off to try to reduce CCI. So the short answer is kind of. ARM can adjust to the top of the specified range, but will not go past that even to compensate for a down neighbor. We are still in the process of our Aruba migration, and it's really been going well. We worked with a great VAR to get us bootstrapped, and now we're chugging right along. We have seen a dramatic drop in the number of wireless complaints with the new Aruba equipment. Jonathan Miller Network Analyst Franklin and Marshall College On Tue, May 30, 2017 at 11:09 AM, Smith, Todd <todd.sm...@camc.org> wrote: > Hello Jon, > > > > Thanks for the input! Aruba’s ARM is frequently been cited as the poster > child for dynamic channel plans. I am not using Aruba here but it is > probably my next upgrade choice unless something better comes long. > > > > Does ARM detect if an AP goes down and adjust TX power and/or channel > accordingly? > > > > Were you ever able to identify your DFS source on channel 144? Our core > facilities are near a regional airport that also serves the Air National > Guard and I don’t see DFS timeouts. I have read that sometimes false > positives can be generated in DFS channels and channel switches in response. > > > > Todd > > > > *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto: > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Jonathan Miller > > > > Todd, > > > > We are an Aruba shop using dynamic channel plans. > > > > We let Aruba's ARM (Adaptive Radio Management) decide on the best channel > for each radio, and in some cases, give it the ability to turn off a 2.4 > radio if it detects that there's too much co-channel interference in an > area. ARM will not switch channels if there is a client associated to a > radio, except in the case of an emergency (DFS beacon, etc). We also let > it pick the Tx power within a range that we specify (typically 12 - 15 EIRP > on 5GHz, lower on the 2.4). > > > > ARM has some secret sauce about how it decides which channel is best, and > has some parameters that we can tune, but we haven't really fiddled with > the knobs too much. > > > > We are using DFS channels, but we haven't had complaints about clients > that can't see them. I suspect that part of the reason that we haven't had > complaints about dead spots is that we have a pretty dense deployment, so > in our res halls, a client should be able to see at 3-4 APs, and the odds > of all of them running on a channel that a given client does not support > seems to be slim enough. Also, it may be that we just got lucky and don't > have too many older 5GHz radios around that don't support all DFS > channels. We have disabled channel 144 because we did see some beacon > events on it, but all other 5GHz channels are enabled. > > > -- > CONFIDENTIALITY NOTICE: The information contained in this message may be > privileged and confidential. If this e-mail contains protected health > information, you are hereby notified that any dissemination, distribution > or copying of this communication is strictly prohibited, except as > permitted by law. If you have received this communication in error, please > notify the sender immediately by replying to this message and deleting it > from your computer. Thank you > ** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at http://www.educause.edu/ > discuss. > > ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
Re: [WIRELESS-LAN] Dynamic vs Static Channel Plans
Todd, We are an Aruba shop using dynamic channel plans. We let Aruba's ARM (Adaptive Radio Management) decide on the best channel for each radio, and in some cases, give it the ability to turn off a 2.4 radio if it detects that there's too much co-channel interference in an area. ARM will not switch channels if there is a client associated to a radio, except in the case of an emergency (DFS beacon, etc). We also let it pick the Tx power within a range that we specify (typically 12 - 15 EIRP on 5GHz, lower on the 2.4). ARM has some secret sauce about how it decides which channel is best, and has some parameters that we can tune, but we haven't really fiddled with the knobs too much. We are using DFS channels, but we haven't had complaints about clients that can't see them. I suspect that part of the reason that we haven't had complaints about dead spots is that we have a pretty dense deployment, so in our res halls, a client should be able to see at 3-4 APs, and the odds of all of them running on a channel that a given client does not support seems to be slim enough. Also, it may be that we just got lucky and don't have too many older 5GHz radios around that don't support all DFS channels. We have disabled channel 144 because we did see some beacon events on it, but all other 5GHz channels are enabled. We have been running several dorms like this for about a year and have had very few complaints. Hope this helps, Jon Jonathan Miller Network Analyst Franklin and Marshall College On Tue, May 30, 2017 at 8:31 AM, Smith, Todd <todd.sm...@camc.org> wrote: > In my efforts to continuous improve the wireless experience here; I > occasionally like to revisit some of my assumptions to see if they are > still valid. What is the current consensus around channel plans for both > 2.4 GHz and 5 GHz ranges? Do organizations plan a static channel plan for > potentially thousands of access points or have the channel selection > algorithms matured enough to be truly useful now? > > If you use static channel plans, are there tools that you use to build > those plans? Do they handle 3 dimensions or are you mapping the channels > across an 2D floor? > > If you use dynamic channel plans, are there tools that you use to build > those plans? What parameters or metrics are being used to select a > channel? Is the issue of 2.4 GHz radios constantly changing channels still > a valid concern? If you are using 5 GHz DFS channels, do you have any > concerns about clients not being able to hear those channels and having > "dead spots". > > Thanks for the input! > > Todd Smith > Charleston Area Medical Center > > == > CONFIDENTIALITY NOTICE: The information contained in this message may be > privileged and confidential. If this e-mail contains protected health > information, you are hereby notified that any dissemination, distribution > or copying of this communication is strictly prohibited, except as > permitted by law. If you have received this communication in error, please > notify the sender immediately by replying to this message and deleting it > from your computer. Thank you > > ** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/discuss. > ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
Re: [WIRELESS-LAN] Ubiquiti per dorm room WIFI
Entirely my bad. I stopped reading that line as soon as I saw Passive PoE. Jonathan Miller Network Analyst Franklin and Marshall College On Wed, Mar 15, 2017 at 1:17 PM, Thomas Carter <tcar...@austincollege.edu> wrote: > The specs do say you can power it by PoE+ (802.3at). > > > > *Thomas Carter* > Network & Operations Manager / IT > > *Austin College* > 900 North Grand Avenue > Sherman, TX 75090 > > Phone: 903-813-2564 <(903)%20813-2564> > www.austincollege.edu > > [image: http://www.austincollege.edu/images/AusColl_Logo_Email.gif] > > > > *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto: > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Jonathan Miller > *Sent:* Wednesday, March 15, 2017 10:32 AM > *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > *Subject:* Re: [WIRELESS-LAN] Ubiquiti per dorm room WIFI > > > > You may already aware of this, but Passive PoE is not the compatible with > 802.3af, at, etc. You'll either need switches that provide *passive* PoE > or a separate power supply for the APs. I've seen a few posts around the > Internet where people got stung by trying to use industry standard PoE with > passive PoE UBNT APs. > > > > Jonathan Miller > > Network Analyst > > Franklin and Marshall College > > > > On Sat, Mar 11, 2017 at 11:01 AM, Michael Blaisdell < > mblaisd...@francis.edu> wrote: > > Has anyone looked at the new Ubiquiti IN WALL WAP? It has what I need. I > also believe it answers some of the questions that came up in past posts > about residence hall WIFI. > > UAP-AC-IW - Ubiquiti UniFi In-Wall 2.4 / 5GHz AC Access Point > > > I read some of the specs at the baltic network site. > > Product Specifications > • Dimensions: 139.7 x 86.7 x 25.75 mm (5.5 x 3.41 x 1.01 ") > • Weight: 200 g (6.43 oz) > • Networking Interface: (3) 10/100/1000 Ethernet Ports > • Buttons: Reset > • Power Method: Passive Power over Ethernet (48V), 803.2at Supported > (Supported Voltage Range: 44 to 57 VDC) > • Power Supply: UniFi Switch (PoE) > • Power Save: Supported > • PoE Out: 48V Pass-Through (Pins 1,2+; 3,6-) > • Maximum Power Consumption: 7W > • Maximum TX Power: > 2.4 GHz: 20 dBm > 5 GHz: 20 dBm > • Antennas: (1) Dual-Band Antenna, Single-Polarity > 2.4 GHz: 1 dBi > 5 GHz: 2 dBi > • Wi-Fi Standards: 802.11 a/b/g/n/ac > • Wireless Security: WEP, WPA-PSK, WPA-Enterprise (WPA/WPA2, TKIP/AES) > • BSSID: Up to Four per Radio > • Mounting: 1-Gang Electrical Wall Box (Not Included) > • Operating Temperature: -10 to 50°C (14 to 122°F) > • Operating Humidity: 5 to 95% Noncondensing > • Certifications: CE, FCC, IC > > Advanced Traffic Management > • VLAN: 802.1Q > • Advanced QoS: Per-User Rate Limiting > • Guest Traffic Isolation: Supported > • WMM: Voice, Video, Best Effort, and Background > • Concurrent Clients: 250+ > > I didn't post the link to the data sheet but is listed on the site. > > > > > > -- > > Michael Blaisdell > Director of Network Services > > IT Services > > Learning Commons/Library > Saint Francis University > > 117 Evergreen Drive > > Loretto, PA 15940 > 814-472-3242 <(814)%20472-3242> > http://www.francis.edu > > > *The best way to predict the future is to invent it.** - O**badiah Bumbly* > > ** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at http://www.educause.edu/ > discuss. > > > > ** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at http://www.educause.edu/ > discuss. > ** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at http://www.educause.edu/ > discuss. > > ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
Re: [WIRELESS-LAN] Ubiquiti per dorm room WIFI
You may already aware of this, but Passive PoE is not the compatible with 802.3af, at, etc. You'll either need switches that provide *passive* PoE or a separate power supply for the APs. I've seen a few posts around the Internet where people got stung by trying to use industry standard PoE with passive PoE UBNT APs. Jonathan Miller Network Analyst Franklin and Marshall College On Sat, Mar 11, 2017 at 11:01 AM, Michael Blaisdell <mblaisd...@francis.edu> wrote: > Has anyone looked at the new Ubiquiti IN WALL WAP? It has what I need. I > also believe it answers some of the questions that came up in past posts > about residence hall WIFI. > > UAP-AC-IW - Ubiquiti UniFi In-Wall 2.4 / 5GHz AC Access Point > > > I read some of the specs at the baltic network site. > > Product Specifications > • Dimensions: 139.7 x 86.7 x 25.75 mm (5.5 x 3.41 x 1.01 ") > • Weight: 200 g (6.43 oz) > • Networking Interface: (3) 10/100/1000 Ethernet Ports > • Buttons: Reset > • Power Method: Passive Power over Ethernet (48V), 803.2at Supported > (Supported Voltage Range: 44 to 57 VDC) > • Power Supply: UniFi Switch (PoE) > • Power Save: Supported > • PoE Out: 48V Pass-Through (Pins 1,2+; 3,6-) > • Maximum Power Consumption: 7W > • Maximum TX Power: > 2.4 GHz: 20 dBm > 5 GHz: 20 dBm > • Antennas: (1) Dual-Band Antenna, Single-Polarity > 2.4 GHz: 1 dBi > 5 GHz: 2 dBi > • Wi-Fi Standards: 802.11 a/b/g/n/ac > • Wireless Security: WEP, WPA-PSK, WPA-Enterprise (WPA/WPA2, TKIP/AES) > • BSSID: Up to Four per Radio > • Mounting: 1-Gang Electrical Wall Box (Not Included) > • Operating Temperature: -10 to 50°C (14 to 122°F) > • Operating Humidity: 5 to 95% Noncondensing > • Certifications: CE, FCC, IC > > Advanced Traffic Management > • VLAN: 802.1Q > • Advanced QoS: Per-User Rate Limiting > • Guest Traffic Isolation: Supported > • WMM: Voice, Video, Best Effort, and Background > • Concurrent Clients: 250+ > > I didn't post the link to the data sheet but is listed on the site. > > > -- > Michael Blaisdell > Director of Network Services > IT Services > Learning Commons/Library > Saint Francis University > 117 Evergreen Drive > Loretto, PA 15940 > 814-472-3242 <(814)%20472-3242> > http://www.francis.edu > > *The best way to predict the future is to invent it. - O**badiah Bumbly* > ** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at http://www.educause.edu/ > discuss. > > ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
Re: [WIRELESS-LAN] Helpdesk Troubleshooting of Wireless Issues
Our WiFi complaints fall into a couple categories: 1. I can't connect this device. - For this, the helpdesk will take the user through the steps to connect the device, at a walk-in location, over the phone, or via email/helpdesk software. For stubborn devices, the support folks will create a ticket and kick it over to one of our 3 Network Analysts (which includes me). Our network analyst position is basically admin/engineer/all network support escalations. We have access to all the tools provided by our vendors to do deep troubleshooting as to why a connection is failing. In a few instances, if we are burning too much time on a problem that is clearly a client issue, we will send it back to desktop support. This was the case with a Dell XPS that needed a BIOS update to connect to our .1x network. 2. There is no coverage in this spot. - One of the network analysts will go to the spot and survey the signal. For any trip to a residential building, we go in 2's to protect ourselves from false allegations of misconduct. We don't have full spectrum analysis tools, but we can at least check for signal level, and rogues, look around for microwaves or other obvious sources of interference. We don't have any specially trained helpdesk techs. Before they escalate a ticket to us, they are generally pretty good about gathering basic info - username, location, ideally the MAC address of the client device so we can look it up in AirWave and our NAC system. Same as Jason's earlier post, communication is handled by whoever is actively working the ticket. -- Jonathan Miller Network Analyst Franklin and Marshall College Jonathan Miller Network Analyst Franklin and Marshall College On Mon, Feb 27, 2017 at 6:13 PM, Norman Elton <normel...@gmail.com> wrote: > I'm curious if people can share their delineation of duties between > the support organization (help desk) and the network administration > (engineering, etc) teams, especially as it surrounds the triaging and > troubleshooting of wireless connectivity issues. > > What is expected from the support organization before an issue is > escalated? Who communicates with the end user? What tools, resources, > and training are made available to techs? Are all support techs > qualified, or just a "wifi strike team"? Lessons learned? > > Thanks! > > Norman Elton > William & Mary > > ** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/discuss. > ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
Re: [WIRELESS-LAN] support of L2 peering devices?
I should add that there are probably other products that have this functionality, but I'm not aware of them. Jonathan Miller Network Analyst Franklin and Marshall College On Wed, Nov 30, 2016 at 9:22 AM, Tim Tyler <ty...@beloit.edu> wrote: > > > Wireless Lan members, > > We use Aruba Networks for our wireless solution and we do have many L2 > devices working that leverage Bonjour, etc. We simply do mac address > authentication for them. Most L2 devices work fine.My big goal is to > find out the different methods that some of you might be using to support > the most difficult L2 devices such as Chromecast, Sonos speakers, and other > L2 devices that need to peer with another device in order to work. These > type of devices ultimately need to broadcast to see each other. Chromecast > generally needs to broadcast to the phone app so that the phone app can see > it and establish a connection with one another. If you create another > SSID for it, what are the key factors in making it work? > > Back in the earlier Fall, a number of you stated that you were using /16 > subnets or very large subnets so that you only needed one subnet for your > residential wireless network. So the question I have is did you do this > to better support L2 devices? If so, do you allow broadcasts on your > large wireless subnet or did you simply do one /16 subnet to simplify the > administration of your wireless network? > > Bottom line, how are some of you supporting L2 devices that allow > Chromecast and other peering L2 devices to work? > > > > > > Tim Tyler > > Network Engineer > > Beloit 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/.
Re: [WIRELESS-LAN] support of L2 peering devices?
Tim, The AirGroup functionality in Aruba ClearPass is probably what you're looking for. You can set it up so that when students register their devices, they can choose whether those devices are allowed to use broadcast/multicast to talk to their other devices, or even allow sharing to other users (potentially, depending on your setup). We've seen it work fairly well, although sometimes a chromecast or something will freak out and lose connectivity briefly with devices that it's supposed to be allowed to talk to. Jon Miller Network Analyst Franklin and Marshall College Jonathan Miller Network Analyst Franklin and Marshall College On Wed, Nov 30, 2016 at 9:22 AM, Tim Tyler <ty...@beloit.edu> wrote: > > > Wireless Lan members, > > We use Aruba Networks for our wireless solution and we do have many L2 > devices working that leverage Bonjour, etc. We simply do mac address > authentication for them. Most L2 devices work fine.My big goal is to > find out the different methods that some of you might be using to support > the most difficult L2 devices such as Chromecast, Sonos speakers, and other > L2 devices that need to peer with another device in order to work. These > type of devices ultimately need to broadcast to see each other. Chromecast > generally needs to broadcast to the phone app so that the phone app can see > it and establish a connection with one another. If you create another > SSID for it, what are the key factors in making it work? > > Back in the earlier Fall, a number of you stated that you were using /16 > subnets or very large subnets so that you only needed one subnet for your > residential wireless network. So the question I have is did you do this > to better support L2 devices? If so, do you allow broadcasts on your > large wireless subnet or did you simply do one /16 subnet to simplify the > administration of your wireless network? > > Bottom line, how are some of you supporting L2 devices that allow > Chromecast and other peering L2 devices to work? > > > > > > Tim Tyler > > Network Engineer > > Beloit 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/.
Re: [WIRELESS-LAN] 802.1x (eduroam) Win10 - no prompt for new password after credential change
Thanks for the replies. We've run into 2 issues with using username@domain for login. The first was that even using username@domain, the Windows client still passed netbiosdomain\user to the RADIUS server. It's my assumption that this would not work for remote users. The second issue that we hit is our own problem - our Windows domain is named fandm.dom, while our public domain is fandm.edu, so we can't authenticate to the computer using usern...@fandm.edu. Our systems guys are currently working on a migration, but that isn't due to be complete for some time. Jonathan Miller Network Analyst Franklin and Marshall College On Fri, Nov 4, 2016 at 7:47 AM, Osborne, Bruce W (Network Operations) < bosbo...@liberty.edu> wrote: > I may be wrong, but wouldn't the proper solution be to use the full > "username@domain" for login as Microsoft recommended when AD was > introduced? You could then have the network caching turned off. > > We do not use EDUROAM but only use the network caching for non-domain > (usually student owned) computers. > > > Bruce Osborne > Wireless Engineer > IT Network Operations - Wireless > (434) 592-4229 > > LIBERTY UNIVERSITY > Training Champions for Christ since 1971 > > -Original Message- > From: Harald Terkelsen [mailto:harald.terkel...@hioa.no] > Sent: Thursday, November 3, 2016 10:50 AM > Subject: Re: 802.1x (eduroam) Win10 - no prompt for new password after > credential change > > On 11/01/2016 06:25 PM, Jonathan Miller wrote: > > We are running into an issue where we have settings for eduroam pushed > > out via GPO (which cert authority is good, user auth only, and a few > > other settings). The problem that we are running into is that if we > > check the 'cache credentials' option in the GPO, Win10 won't prompt > > the user for their new password after a password change. Win7 and 8 > > will both pop up and ask the user to re-enter their username and > > password, it's just Win10 that won't. > > > > Has anybody else run into this? > > Yes: > > https://social.technet.microsoft.com/Forums/en-US/edabb0f1-7dda-4517-9af2- > 39dedeb7726d/update-user-credentials-on-a-wlan-profile- > with-8021x-coming-from-gpo?forum=win10itpronetworking > > Our workaround is to install a script on the PC which deletes the registry > key containing the cached credential when run. > > > Harald Terkelsen > Oslo and Akershus University College of Applied Sciences > > ** > 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/.
802.1x (eduroam) Win10 - no prompt for new password after credential change
We are running into an issue where we have settings for eduroam pushed out via GPO (which cert authority is good, user auth only, and a few other settings). The problem that we are running into is that if we check the 'cache credentials' option in the GPO, Win10 won't prompt the user for their new password after a password change. Win7 and 8 will both pop up and ask the user to re-enter their username and password, it's just Win10 that won't. Has anybody else run into this? TIA, Jonathan Miller Network Analyst Franklin and Marshall College ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
