RE: 802.11b data rates disabled?

[Anthony Croome]

Exactly, use 24Mbs to avoid weird behaviour.

We looked at this a few years ago and found that XP could not handle management 
packets being sent at 48Mb/s or 54Mb/s despite the card connecting at 450Mb/s 
on 5GHz N or 144Mb/s on 2.4GHz N.

On 5GHz the laptop could get an IP address but could not ping it's gateway.
On 2.4GHz the laptop could get an IP, it could ping it's gateway, but it's 
performance was terrible.

What we saw from a 5GHz packet capture was the AP continuously sending RTS to 
the client but never getting any packets from the client.  On 2.4GHz it would 
reply but only after a random number of RTS were sent.  

Anthony
IT Networks
Queensland University of Australia

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jason Cook
Sent: Tuesday, 21 June 2016 11:20 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

Yeah my understanding is that as per the standard devices are 
required(mandatory) to support 6,12,24 rates for 802.11g. So to ensure all 
devices are happy then 24 would be the right minimum, therefore you may see 
some weird behaviour.  So devices need to support that to be compliant, I'm not 
sure it means you have to use it. I'd say if your running 54 and there's no 
complaints why change.  it will be interesting to see how things go. 


We disabled 802.11b rates about 3 months back with no issues reported. We've 
left it enabled in some of our remote campuses where we use lower rates to get 
distance. 



--
Jason Cook
Technology Services
The University of Adelaide, AUSTRALIA 5005 Ph    : +61 8 8313 4800

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Chuck Enfield
Sent: Tuesday, 21 June 2016 6:21 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

Rick,

If I were brave enough to do what you've done, here's what I would worry
about:

- 802.11a/g devices are getting scarce, but I've heard rumors that there were 
802.11g devices that required a basic rate of 6, 12, or 24 Mb/s.
It's possible that there are no such devices left, that driver updates have 
eliminated the limitation, or that no such devices ever existed.
- Many client device drivers do unexpected things when connected to networks 
with unconventional settings.  For example, will clients with a marginal MCS 7 
connection probe for their next AP before their retry rate goes through the 
roof?
- We use 40Mhz channels, so reliable comm at MCS 7 requires about 28 dB SNR.  
It could be very difficult to maintain that while moving.
- Even if clients roam successfully, you'll see an increase in roaming 
activity.  Moving clients may normally hit every second or third AP along the 
way, in your case they'll probably hit every AP.  This could increase the 
overhead consumed by authentication and/or stress your AAA infrastructure.  
That said, the AAA load could be more than offset by reduced authentication 
attempts to indoor APs from outdoor passers-by.

I'm not suggesting these are reasons not to do it.  They're just things I'd 
worry about.  I'd be interested in hearing how it works out for you if you find 
the time to follow up.  

Thanks,

Chuck

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Rick.Decaro
Sent: Monday, June 20, 2016 2:10 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

It sound like a lot of people have already disabled the 802.11b data
rates.   That being saidwhat minimum rate is everyone using?  

We just changed ours last week from a minimum of 1Mbps to 54Mbps.   So far
we have not heard of any issues.Does anyone know what if any problems
could arise from this being set to 54Mbps?   Is there a sweet spot in
between that is better? 

Thanks,

Rick DeCaro
(636)230-1911
rick.dec...@logan.edu


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Watters, John
Sent: Monday, June 20, 2016 1:01 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

We have had the b rates disabled for 2 months short of 5 years. Not a single 
complaint that I am aware of.


-jcw

John WattersThe University of Alabama
Office of Information Technology
205-348-3992
 


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Todd M. Hall
Sent: Monday, June 20, 2016 10:50 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] 802.11b data rates disabled?

Do you have all of the 802.11b data rates disabled?  If 

Re: [WIRELESS-LAN] eduroam ssid

[Philippe Hanset]

David,

To clarify,
eduroam is not a standard, but a trust fabric to roam between research and 
education institutions. eduroam requires  IEEE 802.1X (which is a well used 
standard at many institutions for WLAN and sometimes LAN security) to operate 
which in turn can run on multiple different EAP methods. EAP-TTLS, PEAP, 
EAP-TLS, EAP-PWD,… can all be used with eduroam.  All these methods have their 
issues and schools pick them based on what suits them best for their 
requirements and their environment.

Hope this helps,

Philippe
www.eduroam.us


> On Jun 20, 2016, at 8:59 PM, Schuette, David  wrote:
> 
> Reading everyone comments about edu-roam has me believing it is an old 
> standard which needs to be updated for today's security needs.
> 
> 
> 
> Sent from my Verizon 4G LTE smartphone
> 
> 
>  Original message 
> From: "Curtis K. Larsen"  > 
> Date: 6/20/16 6:04 PM (GMT-07:00) 
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
>  
> Subject: Re: [WIRELESS-LAN] eduroam ssid 
> 
> The PEAP vulnerability is only mitigated by requiring EAP-TLS and disabling 
> PEAP.  (It may help a
> little to recommend the CAT tool or similar, but not much)  We've recommended 
> similar tools for 9
> years - I know the take rates - they aren't great.  Why?  Because it is 
> optional.
> 
> All I am pointing out is that one cannot say that they have completely 
> mitigated 100% the PEAP
> vulnerability while still running eduroam.  I can say that for my primary 
> SSID.
> 
> Thanks,
> 
> Curtis
> 
> 
> On Mon, June 20, 2016 5:19 pm, Jeremy Mooney wrote:
> > How would you plan to mitigate for your users at remote institutions if
> > they're not verifying the certificate? It seems you can only prevent at at
> > the IdP side of your radius infrastructure, and your clients can only trust
> > they're talking to that server by verifying the certificate. If they don't
> > verify the certificate, anyone can claim to be your server and just allow
> > PEAP without you ever seeing the traffic. Technically that's also the case
> > locally (someone else stands up an AP) and you could at most maybe see it
> > happened but not block it (at least without going into the legal minefield
> > of active rogue mitigation).
> >
> > I'd think that the best you can hope for (without solving the problem of
> > users falling for phishing/MitM in general) is just only allowing EAP-TLS
> > so any client with a working config for your institution won't use PEAP,
> > but that doesn't require blocking PEAP on the SP side.
> >
> >
> > On Mon, Jun 20, 2016 at 5:00 PM, Curtis K. Larsen  > >
> > wrote:
> >
> >> It's done on the RADIUS server, that's kind of my point.  You have a
> >> service in your environment
> >> that may pose risk to some and you can't control it.
> >>
> >> I can mitigate the PEAP vulnerability for our users on campus, and our
> >> users at remote
> >> institutions, but I cannot mitigate that same vulnerability for another
> >> institutions' users on my
> >> campus.
> >>
> >> -Curtis
> >>
> >>
> >> On Mon, June 20, 2016 3:50 pm, Chuck Enfield wrote:
> >> > How would you disable PEAP on the eduroam SSID?  I've never noticed a
> >> > setting for that.
> >> >
> >> > -Original Message-
> >> > From: The EDUCAUSE Wireless Issues Constituent Group Listserv
> >> > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> >> > ] On Behalf Of Curtis K.
> >> Larsen
> >> > Sent: Monday, June 20, 2016 5:19 PM
> >> > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> >> > 
> >> > Subject: Re: [WIRELESS-LAN] eduroam ssid
> >> >
> >> > Yes it does work.  That's the problem - PEAP is vulnerable to Evil Twin
> >> > attacks so we are disabling PEAP.  Doing that on eduroam would break all
> >> > institutions that still offer it.  Leaving it enabled exposes users at
> >> our
> >> > institution.
> >> >
> >> > -Curtis
> >> >
> >> > 
> >> > From: Johnson, Neil M [neil-john...@uiowa.edu 
> >> > ]
> >> > Sent: Monday, June 20, 2016 2:52 PM
> >> > To: Curtis K. Larsen
> >> > Cc: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> >> > 
> >> > Subject: Re: [WIRELESS-LAN] eduroam ssid
> >> >
> >> > eduroam should work with just about any authentication method that uses
> >> > EAP (PEAP,TLS,TTLS) etc.
> >> >
> >> > So if your are say moving to TLS (Client certificates) it should still
> >> > just work.
> >> >
> >> > -Neil
> >> >
> >> > --
> >> > Neil Johnson
> >> > Network Engineer
> >> > The University of Iowa
> >> > Phone: 319 384-0938
> >> > Fax: 319 335-2951
> >> > E-Mail: neil-john...@uiowa.edu 
> >> >
> >> >
> >> >
> >> >> On Jun 17, 2016, at 10:19 AM, Curtis K. 

RE: 802.11b data rates disabled?

[Jason Cook]

Yeah my understanding is that as per the standard devices are 
required(mandatory) to support 6,12,24 rates for 802.11g. So to ensure all 
devices are happy then 24 would be the right minimum, therefore you may see 
some weird behaviour.  So devices need to support that to be compliant, I'm not 
sure it means you have to use it. I'd say if your running 54 and there's no 
complaints why change.  it will be interesting to see how things go. 


We disabled 802.11b rates about 3 months back with no issues reported. We've 
left it enabled in some of our remote campuses where we use lower rates to get 
distance. 



--
Jason Cook
Technology Services
The University of Adelaide, AUSTRALIA 5005
Ph    : +61 8 8313 4800

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Chuck Enfield
Sent: Tuesday, 21 June 2016 6:21 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

Rick,

If I were brave enough to do what you've done, here's what I would worry
about:

- 802.11a/g devices are getting scarce, but I've heard rumors that there were 
802.11g devices that required a basic rate of 6, 12, or 24 Mb/s.
It's possible that there are no such devices left, that driver updates have 
eliminated the limitation, or that no such devices ever existed.
- Many client device drivers do unexpected things when connected to networks 
with unconventional settings.  For example, will clients with a marginal MCS 7 
connection probe for their next AP before their retry rate goes through the 
roof?
- We use 40Mhz channels, so reliable comm at MCS 7 requires about 28 dB SNR.  
It could be very difficult to maintain that while moving.
- Even if clients roam successfully, you'll see an increase in roaming 
activity.  Moving clients may normally hit every second or third AP along the 
way, in your case they'll probably hit every AP.  This could increase the 
overhead consumed by authentication and/or stress your AAA infrastructure.  
That said, the AAA load could be more than offset by reduced authentication 
attempts to indoor APs from outdoor passers-by.

I'm not suggesting these are reasons not to do it.  They're just things I'd 
worry about.  I'd be interested in hearing how it works out for you if you find 
the time to follow up.  

Thanks,

Chuck

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Rick.Decaro
Sent: Monday, June 20, 2016 2:10 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

It sound like a lot of people have already disabled the 802.11b data
rates.   That being saidwhat minimum rate is everyone using?  

We just changed ours last week from a minimum of 1Mbps to 54Mbps.   So far
we have not heard of any issues.Does anyone know what if any problems
could arise from this being set to 54Mbps?   Is there a sweet spot in
between that is better? 

Thanks,

Rick DeCaro
(636)230-1911
rick.dec...@logan.edu


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Watters, John
Sent: Monday, June 20, 2016 1:01 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

We have had the b rates disabled for 2 months short of 5 years. Not a single 
complaint that I am aware of.


-jcw

John WattersThe University of Alabama
Office of Information Technology
205-348-3992
 


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Todd M. Hall
Sent: Monday, June 20, 2016 10:50 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] 802.11b data rates disabled?

Do you have all of the 802.11b data rates disabled?  If so, how long have they 
been disabled?  Did you have many complaints when you disabled them?
Were there any particular devices that could not connect as a result?

I'm hoping this information will help us move towards disabling these old 
rates. 
Thank you for your feedback.

--
Todd M. Hall
Sr. Network Analyst
Information Technology Services
Mississippi State University
t...@msstate.edu
662-325-9311 (phone)

**
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 

RE: [WIRELESS-LAN] eduroam ssid

[Jason Cook]

Thanks Phillipe,

Good to know it's not that restrictive :) 

--
Jason Cook
Technology Services
The University of Adelaide, AUSTRALIA 5005
Ph    : +61 8 8313 4800

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Philippe Hanset
Sent: Tuesday, 21 June 2016 7:27 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] eduroam ssid

Jason et al.,

https://www.eduroam.org/wp-content/uploads/2016/05/eduroam_Compliance_Statement_v1_0.pdf

The compliance statement doesn’t require a specific frequency. So, if you want 
to turn 2.4 GHz off, nothing prevents you to do so for eduroam.
eduroam doesn’t try to regulate local decisions too much, but enough to provide 
standardization and a consistent user experience (if 2.4 GHz is not supported 
the SSID won’t show up at all for 2.4 GHz users!…but the dot on the map might 
still confuse them a bit). On the other hand, you have to pass all EAP methods.
So Curtis discussion on the evil twin and preventing this to happen can be done 
for IDPs but not for SPs (an SP must pass all EAP conversations).
If you fear man in middle for password based EAP methods, using the CAT tool 
can help in that respect since it forces the installation of the RADIUS 
infrastructure certificate.
Nothing beats EAP-TLS of course since the password is not involved except 
during the initial EAP-TLS on-boarding (can you MiTM the initial on-boarding? 
;-)

The same applies to the conflicting eduroam SSID. If you read the compliance 
statement you can create an “eduroam-” SSID.
It is really not advised, as Jason mentioned, to run a different name since it 
breaks the “instant connectivity” and creates much confusion for users (and 
Help Desk calls!).
We always promote agreements between the two neighboring institutions (exchange 
VLANs, Wi-Fi controllers collaboration when same brand is involved, IP 
Mobility, ...). 

PassPoint/HotSpot2.0 should address some of these concerns of neighboring SSIDs 
since preferences can be given to different networks.


Best,

Philippe

Philippe Hanset
www.eduroam.us
www.anyroam.net


> On Jun 19, 2016, at 8:53 PM, Jason Cook  wrote:
> 
> Yeah we have had this problem at a few different levels... sorry for 
> the long response
> 
> Initially we had AARNET (the Australian national operator) sharing our floor, 
> so we managed to experience the issue first hand. At that stage we got 
> approval to change our SSID to resolve the issue. "eduroam-UofA" was chosen 
> and our normal ssid is "UofA". To be honest this is not an ideal solution, 
> and at the time (and probably still) is not actually allowed. It brakes the 
> idea of eduroam simply working, the plan is you configure your device once 
> and you can then go to any participating institution around the world, turn 
> your device on and away you go. Having a different SSID means more support 
> requests for you and the home institution when it doesn't just work.  At the 
> time (2007) the usage wasn't as high so it wasn't a huge issue. though 
> supplicants tended be troublesome to configure.  A few years later AARnet 
> offices moved and we wanted to be standard so we are back to "eduroam" SSID. 
> 
> It's not all over though, we have multiple institutions (3) around us 
> offering eduroam including buildings 15m away, and a new medical precinct is 
> being built that will potentially end up with 5 different institutions in an 
> area. Finally something on the back burner is the our city wireless offering 
> eduroam So the future will get interesting. But onto the current 
> situation. To be honest at this point we haven't had too many issues recently 
> with users hopping between SSID's in their offices. Likely the fact we don't 
> recommend eduroam as the users primary SSID would be the primary reason. We 
> did  have a few calls on the close buildings years back, however coverage was 
> done differently and it wasn't un-common in non-dense installs to sometimes 
> see higher signal from neighbouring buildings in some rooms. But with denser 
> deployments and more consistent signal provision you rarely see neighbouring 
> buildings with higher signal In addition for eduroam visitors as a 
> workaround they can use our "UofA" SSID, don't remember this ever being 
> required but it does work. eduroam  participation "requires" that SSID but as 
> far as I'm aware doesn’t stop you from also offering it on others, or even 
> wired dot1x for that matter. 
> 
> Likely we'll never go to eduroam as the only SSID for the many neighbours 
> reason as well as it's good to have your branding in the air. You can also 
> have issues like Curtis is mentioning where you want to change something for 
> security or other reasons but may be restricted by eduroam policy. I don't 
> think eduroam would approve of disabling 2.4ghz completely for example. 
> Our national document is 

RE: [WIRELESS-LAN] eduroam ssid

[Schuette, David]

Reading everyone comments about edu-roam has me believing it is an old standard 
which needs to be updated for today's security needs.



Sent from my Verizon 4G LTE smartphone


 Original message 
From: "Curtis K. Larsen" 
Date: 6/20/16 6:04 PM (GMT-07:00)
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] eduroam ssid

The PEAP vulnerability is only mitigated by requiring EAP-TLS and disabling 
PEAP.  (It may help a
little to recommend the CAT tool or similar, but not much)  We've recommended 
similar tools for 9
years - I know the take rates - they aren't great.  Why?  Because it is 
optional.

All I am pointing out is that one cannot say that they have completely 
mitigated 100% the PEAP
vulnerability while still running eduroam.  I can say that for my primary SSID.

Thanks,

Curtis


On Mon, June 20, 2016 5:19 pm, Jeremy Mooney wrote:
> How would you plan to mitigate for your users at remote institutions if
> they're not verifying the certificate? It seems you can only prevent at at
> the IdP side of your radius infrastructure, and your clients can only trust
> they're talking to that server by verifying the certificate. If they don't
> verify the certificate, anyone can claim to be your server and just allow
> PEAP without you ever seeing the traffic. Technically that's also the case
> locally (someone else stands up an AP) and you could at most maybe see it
> happened but not block it (at least without going into the legal minefield
> of active rogue mitigation).
>
> I'd think that the best you can hope for (without solving the problem of
> users falling for phishing/MitM in general) is just only allowing EAP-TLS
> so any client with a working config for your institution won't use PEAP,
> but that doesn't require blocking PEAP on the SP side.
>
>
> On Mon, Jun 20, 2016 at 5:00 PM, Curtis K. Larsen 
> wrote:
>
>> It's done on the RADIUS server, that's kind of my point.  You have a
>> service in your environment
>> that may pose risk to some and you can't control it.
>>
>> I can mitigate the PEAP vulnerability for our users on campus, and our
>> users at remote
>> institutions, but I cannot mitigate that same vulnerability for another
>> institutions' users on my
>> campus.
>>
>> -Curtis
>>
>>
>> On Mon, June 20, 2016 3:50 pm, Chuck Enfield wrote:
>> > How would you disable PEAP on the eduroam SSID?  I've never noticed a
>> > setting for that.
>> >
>> > -Original Message-
>> > From: The EDUCAUSE Wireless Issues Constituent Group Listserv
>> > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Curtis K.
>> Larsen
>> > Sent: Monday, June 20, 2016 5:19 PM
>> > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> > Subject: Re: [WIRELESS-LAN] eduroam ssid
>> >
>> > Yes it does work.  That's the problem - PEAP is vulnerable to Evil Twin
>> > attacks so we are disabling PEAP.  Doing that on eduroam would break all
>> > institutions that still offer it.  Leaving it enabled exposes users at
>> our
>> > institution.
>> >
>> > -Curtis
>> >
>> > 
>> > From: Johnson, Neil M [neil-john...@uiowa.edu]
>> > Sent: Monday, June 20, 2016 2:52 PM
>> > To: Curtis K. Larsen
>> > Cc: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> > Subject: Re: [WIRELESS-LAN] eduroam ssid
>> >
>> > eduroam should work with just about any authentication method that uses
>> > EAP (PEAP,TLS,TTLS) etc.
>> >
>> > So if your are say moving to TLS (Client certificates) it should still
>> > just work.
>> >
>> > -Neil
>> >
>> > --
>> > Neil Johnson
>> > Network Engineer
>> > The University of Iowa
>> > Phone: 319 384-0938
>> > Fax: 319 335-2951
>> > E-Mail: neil-john...@uiowa.edu
>> >
>> >
>> >
>> >> On Jun 17, 2016, at 10:19 AM, Curtis K. Larsen
>> >  wrote:
>> >>
>> >> We're beginning to run into this problem as well.  Luckily, eduroam is
>> >> not our primary SSID so at least the critical business functions
>> >> continue to work fine on a separate SSID.  My guess is that we'll end up
>> > turning eduroam off at those remote locations if problems get reported.
>> >>
>> >> In talking with the eduroam admin from the other institution they
>> >> mentioned that when this occurs in Europe the solution has been to
>> >> change the name of the SSID.  Is this really allowed?  If so, I'm
>> >> sold!  Then we can start using our primary SSID with eduroam
>> >> credentials!  This is what I always thought eduroam should have been.
>> >> To me the value was always in the universal credential
>> >> *NOT* the SSID name.  That was always a drawback for me especially as
>> >> supplicants become easier to configure.
>> >>
>> >> The other problem that we're going to run into soon is that we will be
>> >> phasing out PEAP on our main SSID to mitigate against the evil twin
>> >> vulnerability, but what do we do with eduroam?  I mean I guess you
>> >> could say it is the remote institution's problem, or the user's
>> >> 

Re: [WIRELESS-LAN] eduroam ssid

[Curtis K. Larsen]

The PEAP vulnerability is only mitigated by requiring EAP-TLS and disabling 
PEAP.  (It may help a
little to recommend the CAT tool or similar, but not much)  We've recommended 
similar tools for 9
years - I know the take rates - they aren't great.  Why?  Because it is 
optional.

All I am pointing out is that one cannot say that they have completely 
mitigated 100% the PEAP
vulnerability while still running eduroam.  I can say that for my primary SSID.

Thanks,

Curtis


On Mon, June 20, 2016 5:19 pm, Jeremy Mooney wrote:
> How would you plan to mitigate for your users at remote institutions if
> they're not verifying the certificate? It seems you can only prevent at at
> the IdP side of your radius infrastructure, and your clients can only trust
> they're talking to that server by verifying the certificate. If they don't
> verify the certificate, anyone can claim to be your server and just allow
> PEAP without you ever seeing the traffic. Technically that's also the case
> locally (someone else stands up an AP) and you could at most maybe see it
> happened but not block it (at least without going into the legal minefield
> of active rogue mitigation).
>
> I'd think that the best you can hope for (without solving the problem of
> users falling for phishing/MitM in general) is just only allowing EAP-TLS
> so any client with a working config for your institution won't use PEAP,
> but that doesn't require blocking PEAP on the SP side.
>
>
> On Mon, Jun 20, 2016 at 5:00 PM, Curtis K. Larsen 
> wrote:
>
>> It's done on the RADIUS server, that's kind of my point.  You have a
>> service in your environment
>> that may pose risk to some and you can't control it.
>>
>> I can mitigate the PEAP vulnerability for our users on campus, and our
>> users at remote
>> institutions, but I cannot mitigate that same vulnerability for another
>> institutions' users on my
>> campus.
>>
>> -Curtis
>>
>>
>> On Mon, June 20, 2016 3:50 pm, Chuck Enfield wrote:
>> > How would you disable PEAP on the eduroam SSID?  I've never noticed a
>> > setting for that.
>> >
>> > -Original Message-
>> > From: The EDUCAUSE Wireless Issues Constituent Group Listserv
>> > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Curtis K.
>> Larsen
>> > Sent: Monday, June 20, 2016 5:19 PM
>> > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> > Subject: Re: [WIRELESS-LAN] eduroam ssid
>> >
>> > Yes it does work.  That's the problem - PEAP is vulnerable to Evil Twin
>> > attacks so we are disabling PEAP.  Doing that on eduroam would break all
>> > institutions that still offer it.  Leaving it enabled exposes users at
>> our
>> > institution.
>> >
>> > -Curtis
>> >
>> > 
>> > From: Johnson, Neil M [neil-john...@uiowa.edu]
>> > Sent: Monday, June 20, 2016 2:52 PM
>> > To: Curtis K. Larsen
>> > Cc: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> > Subject: Re: [WIRELESS-LAN] eduroam ssid
>> >
>> > eduroam should work with just about any authentication method that uses
>> > EAP (PEAP,TLS,TTLS) etc.
>> >
>> > So if your are say moving to TLS (Client certificates) it should still
>> > just work.
>> >
>> > -Neil
>> >
>> > --
>> > Neil Johnson
>> > Network Engineer
>> > The University of Iowa
>> > Phone: 319 384-0938
>> > Fax: 319 335-2951
>> > E-Mail: neil-john...@uiowa.edu
>> >
>> >
>> >
>> >> On Jun 17, 2016, at 10:19 AM, Curtis K. Larsen
>> >  wrote:
>> >>
>> >> We're beginning to run into this problem as well.  Luckily, eduroam is
>> >> not our primary SSID so at least the critical business functions
>> >> continue to work fine on a separate SSID.  My guess is that we'll end up
>> > turning eduroam off at those remote locations if problems get reported.
>> >>
>> >> In talking with the eduroam admin from the other institution they
>> >> mentioned that when this occurs in Europe the solution has been to
>> >> change the name of the SSID.  Is this really allowed?  If so, I'm
>> >> sold!  Then we can start using our primary SSID with eduroam
>> >> credentials!  This is what I always thought eduroam should have been.
>> >> To me the value was always in the universal credential
>> >> *NOT* the SSID name.  That was always a drawback for me especially as
>> >> supplicants become easier to configure.
>> >>
>> >> The other problem that we're going to run into soon is that we will be
>> >> phasing out PEAP on our main SSID to mitigate against the evil twin
>> >> vulnerability, but what do we do with eduroam?  I mean I guess you
>> >> could say it is the remote institution's problem, or the user's
>> >> problem if they connect to an evil twin on your campus because they're
>> >> not validating the server.  But if the evil twin is on your campus it
>> > seems you have at least some responsibility in the matter.  But as it
>> > stands, eduroam will leave a bit of a gaping security hole for us.
>> >>
>> >> --
>> >> Curtis K. Larsen
>> >> Senior Network Engineer
>> >> University of Utah 

Aruba education (was "Aruba Controller code recommendations")

[Brian Helman]

I'm going to fork this topic a little.  We are relatively happy with our 
current wireless vendor, but I've been asked to look around to see what else is 
out there.  At the NERCOMP Annual Conference a few months ago, I lead a joint 
NETMAN/WirelessLAN discussion.  I listed the wireless vendors to see who was 
using each.  I did this alphabetically, and was pretty much able to stop on the 
2nd vendor .. Aruba.  Clearly, it's pretty popular in Higher Ed..

So, I have a few questions that I hope will be easy.  Obviously the Controllers 
have code that gets updated.  Do the AP's also get flashed?   Do they get 
flashed based on the controller code level?  Do you ever get to a point where 
you cannot flash the controller because that code level is not/will not be 
supported by an older AP (we've experienced this with our management platform, 
where we had to run 2 instances .. and old and a new .. to support older AP's 
and move forward in supporting new ones).

For those of you who have rolled out 5GHz deployments, since the Aruba AP's 
appear to have fixed radios (ie one 2.4GHz and one 5GHz, rather than the 
ability to go with two 5GHz), do you ever find yourself deploying more AP's 
than you'd otherwise like to get a great 5GHz density?

Thanks!

-Brian

VENDORS: PLEASE DO NOT CALL ME.  I'm gathering info.  I'll make the first 
contact if I decide to move forward.


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Sidharth Nandury 
[nandu...@denison.edu]
Sent: Friday, June 17, 2016 8:28 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Aruba Controller code recommendations

We are running v6.4.3.7 on the controller while running v8.2.0.2 here at 
Denison University. The controller has not had any issues with it and works 
great! While there are no compatibility issues with each other, Airwave has had 
problems recognizing Cisco equipment gear. We have Cisco 2960X and S series 
switches, both 24 and 48 port. Airwave recognizes these switches as stack 
switches and instead of the particular model of switches that they actually 
are. Also, there was the issue of duplicate devices, where when scanning the 
network for devices it would add the device according to the MAC address of the 
device and then also the devices according to the MAC address of the management 
VLAN of the switch.

The code upgrade form 8.2.0.1 to 8.2.0.2 solved the duplicate device issue, but 
we still continue to have problems with recognizing the correct Cisco models.

We are moving to HP switches for our access layer this summer, we have rolled 
out some switches already. Airwave seems to recognize these switches correctly, 
give all the correct information but Auditing the device configuration has not 
been successful so far. It may be that I am doing something wrong, but I 
thought this was worth mentioning.

Thank you.

Regards,
Sid

On Fri, Jun 17, 2016 at 7:24 AM, Osborne, Bruce W (Network Services) 
> wrote:
We are running 6.4.3.x with Airwave 8.2.0.x. We see no ArubaOS compatibility 
issues, but are working with Aruba support on some specific VisualRF issues 
within Airwave that appear to be restricted to our environment.

​

Bruce Osborne
Wireless Engineer
IT Network Services - Wireless

(434) 592-4229

LIBERTY UNIVERSITY
Training Champions for Christ since 1971

From: Entwistle, Bruce 
[mailto:bruce_entwis...@redlands.edu]
Sent: Thursday, June 16, 2016 3:26 PM
Subject: Re: Aruba Controller code recommendations

Thank you.  We are primarily looking to upgrade to be compatible with the 
newest version of Airwave.

Bruce


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of McClintic, Thomas
Sent: Thursday, June 16, 2016 12:10 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Aruba Controller code recommendations

Bruce,

I was hoping others would reply to get some feedback. Currently running 
6.4.2.13, 7210 and 215s. Asked my HPE rep and they said we can stay on the same 
version unless we run into an issue that needs addressing?

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Entwistle, Bruce
Sent: Monday, June 13, 2016 12:52 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Aruba Controller code recommendations

We are looking to upgrade our Aruba 7210 controllers which are currently 
running software version 6.4.2.4.  Looking at the versions currently available 
on the web site I see the latest GA version is 6.4.3.9 and the latest ED 
version is 6.4.4.8.  I was looking to see what others are running and what 
their recommendation would 

Re: [WIRELESS-LAN] eduroam ssid

[Philippe Hanset]

Jeremy,


You can still help your users with PEAP (and that will help at remote locations 
or on campus as well) by forcing them to on-board their original eduroam config 
via an installer (e.g. CAT or a commercial one).
With Operating Systems using profiles you can lock the config so that users 
won’t be able to authenticate if the RADIUS infrastructure certificate is 
incorrect (case of MiTM attacks).
Now, if the user has the ability to delete the installed profile and to 
manually join eduroam there is nothing to prevent that.

This “locking” mechanism of the infrastructure certificate  is a feature of 
automatic installers  that network operators tend to overlook.
We often have eduroam operators telling us that they don’t need to use CAT 
(cat.eduroam.org, it’s free!) since OSes are doing such a good job at prompting 
users
for credentials. True, but those same OSes are not good at preventing MiTM 
attacks.

Philippe
www.eduroam.us



> On Jun 20, 2016, at 7:19 PM, Jeremy Mooney  wrote:
> 
> How would you plan to mitigate for your users at remote institutions if 
> they're not verifying the certificate? It seems you can only prevent at at 
> the IdP side of your radius infrastructure, and your clients can only trust 
> they're talking to that server by verifying the certificate. If they don't 
> verify the certificate, anyone can claim to be your server and just allow 
> PEAP without you ever seeing the traffic. Technically that's also the case 
> locally (someone else stands up an AP) and you could at most maybe see it 
> happened but not block it (at least without going into the legal minefield of 
> active rogue mitigation).
> 
> I'd think that the best you can hope for (without solving the problem of 
> users falling for phishing/MitM in general) is just only allowing EAP-TLS so 
> any client with a working config for your institution won't use PEAP, but 
> that doesn't require blocking PEAP on the SP side.
> 
> 
> On Mon, Jun 20, 2016 at 5:00 PM, Curtis K. Larsen  > wrote:
> It's done on the RADIUS server, that's kind of my point.  You have a service 
> in your environment
> that may pose risk to some and you can't control it.
> 
> I can mitigate the PEAP vulnerability for our users on campus, and our users 
> at remote
> institutions, but I cannot mitigate that same vulnerability for another 
> institutions' users on my
> campus.
> 
> -Curtis
> 
> 
> On Mon, June 20, 2016 3:50 pm, Chuck Enfield wrote:
> > How would you disable PEAP on the eduroam SSID?  I've never noticed a
> > setting for that.
> >
> > -Original Message-
> > From: The EDUCAUSE Wireless Issues Constituent Group Listserv
> > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> > ] On Behalf Of Curtis K. Larsen
> > Sent: Monday, June 20, 2016 5:19 PM
> > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> > 
> > Subject: Re: [WIRELESS-LAN] eduroam ssid
> >
> > Yes it does work.  That's the problem - PEAP is vulnerable to Evil Twin
> > attacks so we are disabling PEAP.  Doing that on eduroam would break all
> > institutions that still offer it.  Leaving it enabled exposes users at our
> > institution.
> >
> > -Curtis
> >
> > 
> > From: Johnson, Neil M [neil-john...@uiowa.edu 
> > ]
> > Sent: Monday, June 20, 2016 2:52 PM
> > To: Curtis K. Larsen
> > Cc: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
> > 
> > Subject: Re: [WIRELESS-LAN] eduroam ssid
> >
> > eduroam should work with just about any authentication method that uses
> > EAP (PEAP,TLS,TTLS) etc.
> >
> > So if your are say moving to TLS (Client certificates) it should still
> > just work.
> >
> > -Neil
> >
> > --
> > Neil Johnson
> > Network Engineer
> > The University of Iowa
> > Phone: 319 384-0938 
> > Fax: 319 335-2951 
> > E-Mail: neil-john...@uiowa.edu 
> >
> >
> >
> >> On Jun 17, 2016, at 10:19 AM, Curtis K. Larsen
> > > wrote:
> >>
> >> We're beginning to run into this problem as well.  Luckily, eduroam is
> >> not our primary SSID so at least the critical business functions
> >> continue to work fine on a separate SSID.  My guess is that we'll end up
> > turning eduroam off at those remote locations if problems get reported.
> >>
> >> In talking with the eduroam admin from the other institution they
> >> mentioned that when this occurs in Europe the solution has been to
> >> change the name of the SSID.  Is this really allowed?  If so, I'm
> >> sold!  Then we can start using our primary SSID with eduroam
> >> credentials!  This is what I always thought eduroam should have been.
> >> To me the value was always in the universal credential
> >> *NOT* the SSID name.  That was always 

Re: [WIRELESS-LAN] eduroam ssid

[Jeremy Mooney]

How would you plan to mitigate for your users at remote institutions if
they're not verifying the certificate? It seems you can only prevent at at
the IdP side of your radius infrastructure, and your clients can only trust
they're talking to that server by verifying the certificate. If they don't
verify the certificate, anyone can claim to be your server and just allow
PEAP without you ever seeing the traffic. Technically that's also the case
locally (someone else stands up an AP) and you could at most maybe see it
happened but not block it (at least without going into the legal minefield
of active rogue mitigation).

I'd think that the best you can hope for (without solving the problem of
users falling for phishing/MitM in general) is just only allowing EAP-TLS
so any client with a working config for your institution won't use PEAP,
but that doesn't require blocking PEAP on the SP side.


On Mon, Jun 20, 2016 at 5:00 PM, Curtis K. Larsen 
wrote:

> It's done on the RADIUS server, that's kind of my point.  You have a
> service in your environment
> that may pose risk to some and you can't control it.
>
> I can mitigate the PEAP vulnerability for our users on campus, and our
> users at remote
> institutions, but I cannot mitigate that same vulnerability for another
> institutions' users on my
> campus.
>
> -Curtis
>
>
> On Mon, June 20, 2016 3:50 pm, Chuck Enfield wrote:
> > How would you disable PEAP on the eduroam SSID?  I've never noticed a
> > setting for that.
> >
> > -Original Message-
> > From: The EDUCAUSE Wireless Issues Constituent Group Listserv
> > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Curtis K.
> Larsen
> > Sent: Monday, June 20, 2016 5:19 PM
> > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> > Subject: Re: [WIRELESS-LAN] eduroam ssid
> >
> > Yes it does work.  That's the problem - PEAP is vulnerable to Evil Twin
> > attacks so we are disabling PEAP.  Doing that on eduroam would break all
> > institutions that still offer it.  Leaving it enabled exposes users at
> our
> > institution.
> >
> > -Curtis
> >
> > 
> > From: Johnson, Neil M [neil-john...@uiowa.edu]
> > Sent: Monday, June 20, 2016 2:52 PM
> > To: Curtis K. Larsen
> > Cc: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> > Subject: Re: [WIRELESS-LAN] eduroam ssid
> >
> > eduroam should work with just about any authentication method that uses
> > EAP (PEAP,TLS,TTLS) etc.
> >
> > So if your are say moving to TLS (Client certificates) it should still
> > just work.
> >
> > -Neil
> >
> > --
> > Neil Johnson
> > Network Engineer
> > The University of Iowa
> > Phone: 319 384-0938
> > Fax: 319 335-2951
> > E-Mail: neil-john...@uiowa.edu
> >
> >
> >
> >> On Jun 17, 2016, at 10:19 AM, Curtis K. Larsen
> >  wrote:
> >>
> >> We're beginning to run into this problem as well.  Luckily, eduroam is
> >> not our primary SSID so at least the critical business functions
> >> continue to work fine on a separate SSID.  My guess is that we'll end up
> > turning eduroam off at those remote locations if problems get reported.
> >>
> >> In talking with the eduroam admin from the other institution they
> >> mentioned that when this occurs in Europe the solution has been to
> >> change the name of the SSID.  Is this really allowed?  If so, I'm
> >> sold!  Then we can start using our primary SSID with eduroam
> >> credentials!  This is what I always thought eduroam should have been.
> >> To me the value was always in the universal credential
> >> *NOT* the SSID name.  That was always a drawback for me especially as
> >> supplicants become easier to configure.
> >>
> >> The other problem that we're going to run into soon is that we will be
> >> phasing out PEAP on our main SSID to mitigate against the evil twin
> >> vulnerability, but what do we do with eduroam?  I mean I guess you
> >> could say it is the remote institution's problem, or the user's
> >> problem if they connect to an evil twin on your campus because they're
> >> not validating the server.  But if the evil twin is on your campus it
> > seems you have at least some responsibility in the matter.  But as it
> > stands, eduroam will leave a bit of a gaping security hole for us.
> >>
> >> --
> >> Curtis K. Larsen
> >> Senior Network Engineer
> >> University of Utah IT/CIS
> >>
> >>
> >>
> >> On Fri, June 17, 2016 7:35 am, Turner, Ryan H wrote:
> >>> Yes.  We have a satellite school at UNC Asheville.  Up until
> >>> recently, UNC Asheville was not running eduroam, and UNC Chapel Hill
> > was the only occupant of a couple of buildings on campus.
> >>> UNC Asheville adopted eduroam and wanted to move into adjoining spaces.
> > So we were going to have
> >>> the situation where UNC Chapel Hill folks might attach to the wrong
> >>> institution's eduroam and vice versa.  We ended up bridging the two
> >>> networks together through a single link, and based on realm, UNC
> >>> Asheville will terminate UNC 

Re: [WIRELESS-LAN] eduroam ssid

[Matthew Newton]

On Mon, Jun 20, 2016 at 05:50:51PM -0400, Chuck Enfield wrote:
> How would you disable PEAP on the eduroam SSID?  I've never noticed a
> setting for that.

Easy on the RADIUS server - reject if EAP-Message matches
/^0x19/.

Not that anyone should do that for non-local accounts. That's a
whole can of worms to be opened... and rather defeats the point of
offering a visitor service; I'd hazard a guess that more people
use PEAP than anything else.

Cheers,

Matthew


-- 
Matthew Newton, Ph.D. 

Systems Specialist, Infrastructure Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, 

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

Re: [WIRELESS-LAN] eduroam ssid

[Philippe Hanset]

Chuck, everyone,

Do not disable PEAP or EAP-TTLS on the eduroam SSID.
You can turn off PEAP or EAP-TTLS for your own users of course if you decide to 
support mainly EAP-TLS (on your RADIUS server), but do not do that for eduroam 
guests/visitors.

Thanks,

Philippe

Philippe Hanset
www.eduroam.us
www.anyroam.net



> On Jun 20, 2016, at 5:50 PM, Chuck Enfield  wrote:
> 
> How would you disable PEAP on the eduroam SSID?  I've never noticed a
> setting for that.
> 
> -Original Message-
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv
> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Curtis K. Larsen
> Sent: Monday, June 20, 2016 5:19 PM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] eduroam ssid
> 
> Yes it does work.  That's the problem - PEAP is vulnerable to Evil Twin
> attacks so we are disabling PEAP.  Doing that on eduroam would break all
> institutions that still offer it.  Leaving it enabled exposes users at our
> institution.
> 
> -Curtis
> 
> 
> From: Johnson, Neil M [neil-john...@uiowa.edu]
> Sent: Monday, June 20, 2016 2:52 PM
> To: Curtis K. Larsen
> Cc: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] eduroam ssid
> 
> eduroam should work with just about any authentication method that uses
> EAP (PEAP,TLS,TTLS) etc.
> 
> So if your are say moving to TLS (Client certificates) it should still
> just work.
> 
> -Neil
> 
> --
> Neil Johnson
> Network Engineer
> The University of Iowa
> Phone: 319 384-0938
> Fax: 319 335-2951
> E-Mail: neil-john...@uiowa.edu
> 
> 
> 
>> On Jun 17, 2016, at 10:19 AM, Curtis K. Larsen
>  wrote:
>> 
>> We're beginning to run into this problem as well.  Luckily, eduroam is 
>> not our primary SSID so at least the critical business functions 
>> continue to work fine on a separate SSID.  My guess is that we'll end up
> turning eduroam off at those remote locations if problems get reported.
>> 
>> In talking with the eduroam admin from the other institution they 
>> mentioned that when this occurs in Europe the solution has been to 
>> change the name of the SSID.  Is this really allowed?  If so, I'm 
>> sold!  Then we can start using our primary SSID with eduroam 
>> credentials!  This is what I always thought eduroam should have been.  
>> To me the value was always in the universal credential
>> *NOT* the SSID name.  That was always a drawback for me especially as 
>> supplicants become easier to configure.
>> 
>> The other problem that we're going to run into soon is that we will be 
>> phasing out PEAP on our main SSID to mitigate against the evil twin 
>> vulnerability, but what do we do with eduroam?  I mean I guess you 
>> could say it is the remote institution's problem, or the user's 
>> problem if they connect to an evil twin on your campus because they're 
>> not validating the server.  But if the evil twin is on your campus it
> seems you have at least some responsibility in the matter.  But as it
> stands, eduroam will leave a bit of a gaping security hole for us.
>> 
>> --
>> Curtis K. Larsen
>> Senior Network Engineer
>> University of Utah IT/CIS
>> 
>> 
>> 
>> On Fri, June 17, 2016 7:35 am, Turner, Ryan H wrote:
>>> Yes.  We have a satellite school at UNC Asheville.  Up until 
>>> recently, UNC Asheville was not running eduroam, and UNC Chapel Hill
> was the only occupant of a couple of buildings on campus.
>>> UNC Asheville adopted eduroam and wanted to move into adjoining spaces.
> So we were going to have
>>> the situation where UNC Chapel Hill folks might attach to the wrong 
>>> institution's eduroam and vice versa.  We ended up bridging the two 
>>> networks together through a single link, and based on realm, UNC 
>>> Asheville will terminate UNC Chapel Hill folks directly to our 
>>> network (through trunked vlans).  It is nice, because now anywhere on 
>>> UNC Asheville campus, UNC Chapel Hill folks have UNC Chapel Hill IP
> space.  Because it made sense, we actually turned off our access points
> and allowed UNC Asheville to provide wireless in our areas (so we wouldn't
> have competing wireless).
>>> 
>>> 
>>> Ryan Turner
>>> Manager of Network Operations
>>> ITS Communication Technologies
>>> The University of North Carolina at Chapel Hill
>>> 
>>> r...@unc.edu
>>> +1 919 445 0113 Office
>>> +1 919 274 7926 Mobile
>>> 
>>> 
>>> 
>>> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
>>> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Becker, 
>>> Jason
>>> Sent: Thursday, June 16, 2016 11:45 PM
>>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>>> Subject: [WIRELESS-LAN] eduroam ssid
>>> 
>>> Has anyone ran into this situation.
>>> 
>>> We are an eduroam participating school and have multiple buildings 
>>> that are either across the road or sometimes sidewalk that another 
>>> University owns.  The other school is wanting to join eduroam so my 
>>> issue 

Re: [WIRELESS-LAN] eduroam ssid

[Curtis K. Larsen]

It's done on the RADIUS server, that's kind of my point.  You have a service in 
your environment
that may pose risk to some and you can't control it.

I can mitigate the PEAP vulnerability for our users on campus, and our users at 
remote
institutions, but I cannot mitigate that same vulnerability for another 
institutions' users on my
campus.

-Curtis


On Mon, June 20, 2016 3:50 pm, Chuck Enfield wrote:
> How would you disable PEAP on the eduroam SSID?  I've never noticed a
> setting for that.
>
> -Original Message-
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv
> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Curtis K. Larsen
> Sent: Monday, June 20, 2016 5:19 PM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] eduroam ssid
>
> Yes it does work.  That's the problem - PEAP is vulnerable to Evil Twin
> attacks so we are disabling PEAP.  Doing that on eduroam would break all
> institutions that still offer it.  Leaving it enabled exposes users at our
> institution.
>
> -Curtis
>
> 
> From: Johnson, Neil M [neil-john...@uiowa.edu]
> Sent: Monday, June 20, 2016 2:52 PM
> To: Curtis K. Larsen
> Cc: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] eduroam ssid
>
> eduroam should work with just about any authentication method that uses
> EAP (PEAP,TLS,TTLS) etc.
>
> So if your are say moving to TLS (Client certificates) it should still
> just work.
>
> -Neil
>
> --
> Neil Johnson
> Network Engineer
> The University of Iowa
> Phone: 319 384-0938
> Fax: 319 335-2951
> E-Mail: neil-john...@uiowa.edu
>
>
>
>> On Jun 17, 2016, at 10:19 AM, Curtis K. Larsen
>  wrote:
>>
>> We're beginning to run into this problem as well.  Luckily, eduroam is
>> not our primary SSID so at least the critical business functions
>> continue to work fine on a separate SSID.  My guess is that we'll end up
> turning eduroam off at those remote locations if problems get reported.
>>
>> In talking with the eduroam admin from the other institution they
>> mentioned that when this occurs in Europe the solution has been to
>> change the name of the SSID.  Is this really allowed?  If so, I'm
>> sold!  Then we can start using our primary SSID with eduroam
>> credentials!  This is what I always thought eduroam should have been.
>> To me the value was always in the universal credential
>> *NOT* the SSID name.  That was always a drawback for me especially as
>> supplicants become easier to configure.
>>
>> The other problem that we're going to run into soon is that we will be
>> phasing out PEAP on our main SSID to mitigate against the evil twin
>> vulnerability, but what do we do with eduroam?  I mean I guess you
>> could say it is the remote institution's problem, or the user's
>> problem if they connect to an evil twin on your campus because they're
>> not validating the server.  But if the evil twin is on your campus it
> seems you have at least some responsibility in the matter.  But as it
> stands, eduroam will leave a bit of a gaping security hole for us.
>>
>> --
>> Curtis K. Larsen
>> Senior Network Engineer
>> University of Utah IT/CIS
>>
>>
>>
>> On Fri, June 17, 2016 7:35 am, Turner, Ryan H wrote:
>>> Yes.  We have a satellite school at UNC Asheville.  Up until
>>> recently, UNC Asheville was not running eduroam, and UNC Chapel Hill
> was the only occupant of a couple of buildings on campus.
>>> UNC Asheville adopted eduroam and wanted to move into adjoining spaces.
> So we were going to have
>>> the situation where UNC Chapel Hill folks might attach to the wrong
>>> institution's eduroam and vice versa.  We ended up bridging the two
>>> networks together through a single link, and based on realm, UNC
>>> Asheville will terminate UNC Chapel Hill folks directly to our
>>> network (through trunked vlans).  It is nice, because now anywhere on
>>> UNC Asheville campus, UNC Chapel Hill folks have UNC Chapel Hill IP
> space.  Because it made sense, we actually turned off our access points
> and allowed UNC Asheville to provide wireless in our areas (so we wouldn't
> have competing wireless).
>>>
>>>
>>> Ryan Turner
>>> Manager of Network Operations
>>> ITS Communication Technologies
>>> The University of North Carolina at Chapel Hill
>>>
>>> r...@unc.edu
>>> +1 919 445 0113 Office
>>> +1 919 274 7926 Mobile
>>>
>>>
>>>
>>> From: The EDUCAUSE Wireless Issues Constituent Group Listserv
>>> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Becker,
>>> Jason
>>> Sent: Thursday, June 16, 2016 11:45 PM
>>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>>> Subject: [WIRELESS-LAN] eduroam ssid
>>>
>>> Has anyone ran into this situation.
>>>
>>> We are an eduroam participating school and have multiple buildings
>>> that are either across the road or sometimes sidewalk that another
>>> University owns.  The other school is wanting to join eduroam so my
>>> issue is when we are both broadcasting 

Re: [WIRELESS-LAN] eduroam ssid

[Philippe Hanset]

Jason et al.,

https://www.eduroam.org/wp-content/uploads/2016/05/eduroam_Compliance_Statement_v1_0.pdf

The compliance statement doesn’t require a specific frequency. So, if you want 
to turn 2.4 GHz off, nothing prevents you to do so for eduroam.
eduroam doesn’t try to regulate local decisions too much, but enough to provide 
standardization and a consistent user experience (if 2.4 GHz is not supported
the SSID won’t show up at all for 2.4 GHz users!…but the dot on the map might 
still confuse them a bit). On the other hand, you have to pass all EAP methods.
So Curtis discussion on the evil twin and preventing this to happen can be done 
for IDPs but not for SPs (an SP must pass all EAP conversations).
If you fear man in middle for password based EAP methods, using the CAT tool 
can help in that respect since it forces the installation of the RADIUS 
infrastructure certificate.
Nothing beats EAP-TLS of course since the password is not involved except 
during the initial EAP-TLS on-boarding (can you MiTM the initial on-boarding? 
;-)

The same applies to the conflicting eduroam SSID. If you read the compliance 
statement you can create an “eduroam-” SSID.
It is really not advised, as Jason mentioned, to run a different name since it 
breaks the “instant connectivity” and creates much confusion for users (and 
Help Desk calls!).
We always promote agreements between the two neighboring institutions (exchange 
VLANs, Wi-Fi controllers collaboration when same brand is involved, IP 
Mobility, ...). 

PassPoint/HotSpot2.0 should address some of these concerns of neighboring SSIDs 
since preferences can be given to different networks.


Best,

Philippe

Philippe Hanset
www.eduroam.us
www.anyroam.net


> On Jun 19, 2016, at 8:53 PM, Jason Cook  wrote:
> 
> Yeah we have had this problem at a few different levels... sorry for the long 
> response
> 
> Initially we had AARNET (the Australian national operator) sharing our floor, 
> so we managed to experience the issue first hand. At that stage we got 
> approval to change our SSID to resolve the issue. "eduroam-UofA" was chosen 
> and our normal ssid is "UofA". To be honest this is not an ideal solution, 
> and at the time (and probably still) is not actually allowed. It brakes the 
> idea of eduroam simply working, the plan is you configure your device once 
> and you can then go to any participating institution around the world, turn 
> your device on and away you go. Having a different SSID means more support 
> requests for you and the home institution when it doesn't just work.  At the 
> time (2007) the usage wasn't as high so it wasn't a huge issue. though 
> supplicants tended be troublesome to configure.  A few years later AARnet 
> offices moved and we wanted to be standard so we are back to "eduroam" SSID. 
> 
> It's not all over though, we have multiple institutions (3) around us 
> offering eduroam including buildings 15m away, and a new medical precinct is 
> being built that will potentially end up with 5 different institutions in an 
> area. Finally something on the back burner is the our city wireless offering 
> eduroam So the future will get interesting. But onto the current 
> situation. To be honest at this point we haven't had too many issues recently 
> with users hopping between SSID's in their offices. Likely the fact we don't 
> recommend eduroam as the users primary SSID would be the primary reason. We 
> did  have a few calls on the close buildings years back, however coverage was 
> done differently and it wasn't un-common in non-dense installs to sometimes 
> see higher signal from neighbouring buildings in some rooms. But with denser 
> deployments and more consistent signal provision you rarely see neighbouring 
> buildings with higher signal In addition for eduroam visitors as a 
> workaround they can use our "UofA" SSID, don't remember this ever being 
> required but it does work. eduroam  participation "requires" that SSID but as 
> far as I'm aware doesn’t stop you from also offering it on others, or even 
> wired dot1x for that matter. 
> 
> Likely we'll never go to eduroam as the only SSID for the many neighbours 
> reason as well as it's good to have your branding in the air. You can also 
> have issues like Curtis is mentioning where you want to change something for 
> security or other reasons but may be restricted by eduroam policy. I don't 
> think eduroam would approve of disabling 2.4ghz completely for example. 
> Our national document is being reviewed but currently states WPA-TKIP is 
> required..HAHAHA. Don't think so.
> 
> Finally we and other insinuations have wireless installs in our hospitals, 
> recently the hospitals have provided blanket wireless coverage and 
> interference became a major issue. The hospitals agreed to offer eduroam 
> SSID, and we are all pulling out our gear.  (so more similar to Ryan's 
> experience). We started by disabling eduroam when they 

RE: [WIRELESS-LAN] eduroam ssid

[Chuck Enfield]

How would you disable PEAP on the eduroam SSID?  I've never noticed a
setting for that.

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Curtis K. Larsen
Sent: Monday, June 20, 2016 5:19 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] eduroam ssid

Yes it does work.  That's the problem - PEAP is vulnerable to Evil Twin
attacks so we are disabling PEAP.  Doing that on eduroam would break all
institutions that still offer it.  Leaving it enabled exposes users at our
institution.

-Curtis


From: Johnson, Neil M [neil-john...@uiowa.edu]
Sent: Monday, June 20, 2016 2:52 PM
To: Curtis K. Larsen
Cc: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] eduroam ssid

eduroam should work with just about any authentication method that uses
EAP (PEAP,TLS,TTLS) etc.

So if your are say moving to TLS (Client certificates) it should still
just work.

-Neil

--
Neil Johnson
Network Engineer
The University of Iowa
Phone: 319 384-0938
Fax: 319 335-2951
E-Mail: neil-john...@uiowa.edu



> On Jun 17, 2016, at 10:19 AM, Curtis K. Larsen
 wrote:
>
> We're beginning to run into this problem as well.  Luckily, eduroam is 
> not our primary SSID so at least the critical business functions 
> continue to work fine on a separate SSID.  My guess is that we'll end up
turning eduroam off at those remote locations if problems get reported.
>
> In talking with the eduroam admin from the other institution they 
> mentioned that when this occurs in Europe the solution has been to 
> change the name of the SSID.  Is this really allowed?  If so, I'm 
> sold!  Then we can start using our primary SSID with eduroam 
> credentials!  This is what I always thought eduroam should have been.  
> To me the value was always in the universal credential
> *NOT* the SSID name.  That was always a drawback for me especially as 
> supplicants become easier to configure.
>
> The other problem that we're going to run into soon is that we will be 
> phasing out PEAP on our main SSID to mitigate against the evil twin 
> vulnerability, but what do we do with eduroam?  I mean I guess you 
> could say it is the remote institution's problem, or the user's 
> problem if they connect to an evil twin on your campus because they're 
> not validating the server.  But if the evil twin is on your campus it
seems you have at least some responsibility in the matter.  But as it
stands, eduroam will leave a bit of a gaping security hole for us.
>
> --
> Curtis K. Larsen
> Senior Network Engineer
> University of Utah IT/CIS
>
>
>
> On Fri, June 17, 2016 7:35 am, Turner, Ryan H wrote:
>> Yes.  We have a satellite school at UNC Asheville.  Up until 
>> recently, UNC Asheville was not running eduroam, and UNC Chapel Hill
was the only occupant of a couple of buildings on campus.
>> UNC Asheville adopted eduroam and wanted to move into adjoining spaces.
So we were going to have
>> the situation where UNC Chapel Hill folks might attach to the wrong 
>> institution's eduroam and vice versa.  We ended up bridging the two 
>> networks together through a single link, and based on realm, UNC 
>> Asheville will terminate UNC Chapel Hill folks directly to our 
>> network (through trunked vlans).  It is nice, because now anywhere on 
>> UNC Asheville campus, UNC Chapel Hill folks have UNC Chapel Hill IP
space.  Because it made sense, we actually turned off our access points
and allowed UNC Asheville to provide wireless in our areas (so we wouldn't
have competing wireless).
>>
>>
>> Ryan Turner
>> Manager of Network Operations
>> ITS Communication Technologies
>> The University of North Carolina at Chapel Hill
>>
>> r...@unc.edu
>> +1 919 445 0113 Office
>> +1 919 274 7926 Mobile
>>
>>
>>
>> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
>> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Becker, 
>> Jason
>> Sent: Thursday, June 16, 2016 11:45 PM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> Subject: [WIRELESS-LAN] eduroam ssid
>>
>> Has anyone ran into this situation.
>>
>> We are an eduroam participating school and have multiple buildings 
>> that are either across the road or sometimes sidewalk that another 
>> University owns.  The other school is wanting to join eduroam so my 
>> issue is when we are both broadcasting the same ssid in possibly the 
>> same airspace.  I have a felling this is going to cause many problems
as clients could bounce back and forth between systems.
>>
>> If you had to deal with this I like to hear your thoughts on it.
>>
>> --
>> Thanks,
>> Jason Becker
>> Network Systems Engineer
>> Washington University in St. Louis
>> jbec...@wustl.edu
>> 314-935-5006
>> ** Participation and subscription information for this 
>> EDUCAUSE Constituent Group discussion list can be found at 
>>

RE: [WIRELESS-LAN] eduroam ssid

[Curtis K. Larsen]

Yes it does work.  That's the problem - PEAP is vulnerable to Evil Twin attacks 
so we are disabling PEAP.  Doing that on eduroam would break all institutions 
that still offer it.  Leaving it enabled exposes users at our institution.

-Curtis


From: Johnson, Neil M [neil-john...@uiowa.edu]
Sent: Monday, June 20, 2016 2:52 PM
To: Curtis K. Larsen
Cc: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] eduroam ssid

eduroam should work with just about any authentication method that uses EAP 
(PEAP,TLS,TTLS) etc.

So if your are say moving to TLS (Client certificates) it should still just 
work.

-Neil

--
Neil Johnson
Network Engineer
The University of Iowa
Phone: 319 384-0938
Fax: 319 335-2951
E-Mail: neil-john...@uiowa.edu



> On Jun 17, 2016, at 10:19 AM, Curtis K. Larsen  
> wrote:
>
> We're beginning to run into this problem as well.  Luckily, eduroam is not 
> our primary SSID so at
> least the critical business functions continue to work fine on a separate 
> SSID.  My guess is that
> we'll end up turning eduroam off at those remote locations if problems get 
> reported.
>
> In talking with the eduroam admin from the other institution they mentioned 
> that when this occurs
> in Europe the solution has been to change the name of the SSID.  Is this 
> really allowed?  If so,
> I'm sold!  Then we can start using our primary SSID with eduroam credentials! 
>  This is what I
> always thought eduroam should have been.  To me the value was always in the 
> universal credential
> *NOT* the SSID name.  That was always a drawback for me especially as 
> supplicants become easier to
> configure.
>
> The other problem that we're going to run into soon is that we will be 
> phasing out PEAP on our
> main SSID to mitigate against the evil twin vulnerability, but what do we do 
> with eduroam?  I mean
> I guess you could say it is the remote institution's problem, or the user's 
> problem if they
> connect to an evil twin on your campus because they're not validating the 
> server.  But if the evil
> twin is on your campus it seems you have at least some responsibility in the 
> matter.  But as it
> stands, eduroam will leave a bit of a gaping security hole for us.
>
> --
> Curtis K. Larsen
> Senior Network Engineer
> University of Utah IT/CIS
>
>
>
> On Fri, June 17, 2016 7:35 am, Turner, Ryan H wrote:
>> Yes.  We have a satellite school at UNC Asheville.  Up until recently, UNC 
>> Asheville was not
>> running eduroam, and UNC Chapel Hill was the only occupant of a couple of 
>> buildings on campus.
>> UNC Asheville adopted eduroam and wanted to move into adjoining spaces.   So 
>> we were going to have
>> the situation where UNC Chapel Hill folks might attach to the wrong 
>> institution’s eduroam and
>> vice versa.  We ended up bridging the two networks together through a single 
>> link, and based on
>> realm, UNC Asheville will terminate UNC Chapel Hill folks directly to our 
>> network (through trunked
>> vlans).  It is nice, because now anywhere on UNC Asheville campus, UNC 
>> Chapel Hill folks have UNC
>> Chapel Hill IP space.  Because it made sense, we actually turned off our 
>> access points and allowed
>> UNC Asheville to provide wireless in our areas (so we wouldn’t have 
>> competing wireless).
>>
>>
>> Ryan Turner
>> Manager of Network Operations
>> ITS Communication Technologies
>> The University of North Carolina at Chapel Hill
>>
>> r...@unc.edu
>> +1 919 445 0113 Office
>> +1 919 274 7926 Mobile
>>
>>
>>
>> From: The EDUCAUSE Wireless Issues Constituent Group Listserv
>> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Becker, Jason
>> Sent: Thursday, June 16, 2016 11:45 PM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> Subject: [WIRELESS-LAN] eduroam ssid
>>
>> Has anyone ran into this situation…
>>
>> We are an eduroam participating school and have multiple buildings that are 
>> either across the road
>> or sometimes sidewalk that another University owns.  The other school is 
>> wanting to join eduroam
>> so my issue is when we are both broadcasting the same ssid in possibly the 
>> same airspace.  I have
>> a felling this is going to cause many problems as clients could bounce back 
>> and forth between
>> systems.
>>
>> If you had to deal with this I like to hear your thoughts on it.
>>
>> --
>> Thanks,
>> Jason Becker
>> Network Systems Engineer
>> Washington University in St. Louis
>> jbec...@wustl.edu
>> 314-935-5006
>> ** Participation and subscription information for this EDUCAUSE 
>> Constituent Group
>> discussion list can be found at
>> http://www.educause.edu/groups/.
>>
>> **
>> 

Re: [WIRELESS-LAN] 802.11b data rates disabled?

[Jason Wang]

We removed 802.11b data rates on our campus in 2011. We didn't hear any 
feedback directly or by way of our Helpdesk. At the time we turned those 
rates off, 802.11b clients were a negligible percentage of our wireless 
users (rounded to ~0.0% when we put together our usage stats for that year).


Jason


On 06/20/2016 10:49 AM, Todd M. Hall wrote:
Do you have all of the 802.11b data rates disabled? If so, how long 
have they been disabled?  Did you have many complaints when you 
disabled them?  Were there any particular devices that could not 
connect as a result?


I'm hoping this information will help us move towards disabling these 
old rates. Thank you for your feedback.






**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.



smime.p7s
Description: S/MIME Cryptographic Signature

RE: [WIRELESS-LAN] 802.11b data rates disabled?

[Danny Eaton]

We have the 5.5 Mbps, 6 Mbps, 9 Mbps, 12 Mbps, 18 Mbps, 24 Mbps, 36 Mbps, 48
Mbps, and 54 Mbps as supported; 11 Mbps as Mandatory, but 1 Mbps and 2 Mbps
as disabled.  

We probably should disable the 5.5, 6, 9, and 11 Mbps, to really "eliminate"
them, but even with 1 and 2 disabled, we're not seeing anyone on 802.11b.
About 20% of my users are on 802.11n (2.4 Ghz), and just over 18% are on 5
Ghz.  I have a total of 17 users on 802.11g, and one on 802.11a.   


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Chuck Enfield
Sent: Monday, June 20, 2016 3:51 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

Rick,

If I were brave enough to do what you've done, here's what I would worry
about:

- 802.11a/g devices are getting scarce, but I've heard rumors that there
were 802.11g devices that required a basic rate of 6, 12, or 24 Mb/s.
It's possible that there are no such devices left, that driver updates have
eliminated the limitation, or that no such devices ever existed.
- Many client device drivers do unexpected things when connected to networks
with unconventional settings.  For example, will clients with a marginal MCS
7 connection probe for their next AP before their retry rate goes through
the roof?
- We use 40Mhz channels, so reliable comm at MCS 7 requires about 28 dB SNR.
It could be very difficult to maintain that while moving.
- Even if clients roam successfully, you'll see an increase in roaming
activity.  Moving clients may normally hit every second or third AP along
the way, in your case they'll probably hit every AP.  This could increase
the overhead consumed by authentication and/or stress your AAA
infrastructure.  That said, the AAA load could be more than offset by
reduced authentication attempts to indoor APs from outdoor passers-by.

I'm not suggesting these are reasons not to do it.  They're just things I'd
worry about.  I'd be interested in hearing how it works out for you if you
find the time to follow up.  

Thanks,

Chuck

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Rick.Decaro
Sent: Monday, June 20, 2016 2:10 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

It sound like a lot of people have already disabled the 802.11b data
rates.   That being saidwhat minimum rate is everyone using?  

We just changed ours last week from a minimum of 1Mbps to 54Mbps.   So far
we have not heard of any issues.Does anyone know what if any problems
could arise from this being set to 54Mbps?   Is there a sweet spot in
between that is better? 

Thanks,

Rick DeCaro
(636)230-1911
rick.dec...@logan.edu


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Watters, John
Sent: Monday, June 20, 2016 1:01 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

We have had the b rates disabled for 2 months short of 5 years. Not a single
complaint that I am aware of.


-jcw

John WattersThe University of Alabama
Office of Information Technology
205-348-3992
 


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Todd M. Hall
Sent: Monday, June 20, 2016 10:50 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] 802.11b data rates disabled?

Do you have all of the 802.11b data rates disabled?  If so, how long have
they been disabled?  Did you have many complaints when you disabled them?
Were there any particular devices that could not connect as a result?

I'm hoping this information will help us move towards disabling these old
rates. 
Thank you for your feedback.

--
Todd M. Hall
Sr. Network Analyst
Information Technology Services
Mississippi State University
t...@msstate.edu
662-325-9311 (phone)

**
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/.

!DSPAM:911,5768574a116701014119785!

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

Re: [WIRELESS-LAN] eduroam ssid

[Johnson, Neil M]

eduroam should work with just about any authentication method that uses EAP 
(PEAP,TLS,TTLS) etc.

So if your are say moving to TLS (Client certificates) it should still just 
work.

-Neil

-- 
Neil Johnson
Network Engineer
The University of Iowa
Phone: 319 384-0938
Fax: 319 335-2951
E-Mail: neil-john...@uiowa.edu



> On Jun 17, 2016, at 10:19 AM, Curtis K. Larsen  
> wrote:
> 
> We're beginning to run into this problem as well.  Luckily, eduroam is not 
> our primary SSID so at
> least the critical business functions continue to work fine on a separate 
> SSID.  My guess is that
> we'll end up turning eduroam off at those remote locations if problems get 
> reported.
> 
> In talking with the eduroam admin from the other institution they mentioned 
> that when this occurs
> in Europe the solution has been to change the name of the SSID.  Is this 
> really allowed?  If so,
> I'm sold!  Then we can start using our primary SSID with eduroam credentials! 
>  This is what I
> always thought eduroam should have been.  To me the value was always in the 
> universal credential
> *NOT* the SSID name.  That was always a drawback for me especially as 
> supplicants become easier to
> configure.
> 
> The other problem that we're going to run into soon is that we will be 
> phasing out PEAP on our
> main SSID to mitigate against the evil twin vulnerability, but what do we do 
> with eduroam?  I mean
> I guess you could say it is the remote institution's problem, or the user's 
> problem if they
> connect to an evil twin on your campus because they're not validating the 
> server.  But if the evil
> twin is on your campus it seems you have at least some responsibility in the 
> matter.  But as it
> stands, eduroam will leave a bit of a gaping security hole for us.
> 
> -- 
> Curtis K. Larsen
> Senior Network Engineer
> University of Utah IT/CIS
> 
> 
> 
> On Fri, June 17, 2016 7:35 am, Turner, Ryan H wrote:
>> Yes.  We have a satellite school at UNC Asheville.  Up until recently, UNC 
>> Asheville was not
>> running eduroam, and UNC Chapel Hill was the only occupant of a couple of 
>> buildings on campus.
>> UNC Asheville adopted eduroam and wanted to move into adjoining spaces.   So 
>> we were going to have
>> the situation where UNC Chapel Hill folks might attach to the wrong 
>> institution’s eduroam and
>> vice versa.  We ended up bridging the two networks together through a single 
>> link, and based on
>> realm, UNC Asheville will terminate UNC Chapel Hill folks directly to our 
>> network (through trunked
>> vlans).  It is nice, because now anywhere on UNC Asheville campus, UNC 
>> Chapel Hill folks have UNC
>> Chapel Hill IP space.  Because it made sense, we actually turned off our 
>> access points and allowed
>> UNC Asheville to provide wireless in our areas (so we wouldn’t have 
>> competing wireless).
>> 
>> 
>> Ryan Turner
>> Manager of Network Operations
>> ITS Communication Technologies
>> The University of North Carolina at Chapel Hill
>> 
>> r...@unc.edu
>> +1 919 445 0113 Office
>> +1 919 274 7926 Mobile
>> 
>> 
>> 
>> From: The EDUCAUSE Wireless Issues Constituent Group Listserv
>> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Becker, Jason
>> Sent: Thursday, June 16, 2016 11:45 PM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> Subject: [WIRELESS-LAN] eduroam ssid
>> 
>> Has anyone ran into this situation…
>> 
>> We are an eduroam participating school and have multiple buildings that are 
>> either across the road
>> or sometimes sidewalk that another University owns.  The other school is 
>> wanting to join eduroam
>> so my issue is when we are both broadcasting the same ssid in possibly the 
>> same airspace.  I have
>> a felling this is going to cause many problems as clients could bounce back 
>> and forth between
>> systems.
>> 
>> If you had to deal with this I like to hear your thoughts on it.
>> 
>> --
>> Thanks,
>> Jason Becker
>> Network Systems Engineer
>> Washington University in St. Louis
>> jbec...@wustl.edu
>> 314-935-5006
>> ** 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 

RE: [WIRELESS-LAN] 802.11b data rates disabled?

[Chuck Enfield]

Rick,

If I were brave enough to do what you've done, here's what I would worry
about:

- 802.11a/g devices are getting scarce, but I've heard rumors that there
were 802.11g devices that required a basic rate of 6, 12, or 24 Mb/s.
It's possible that there are no such devices left, that driver updates
have eliminated the limitation, or that no such devices ever existed.
- Many client device drivers do unexpected things when connected to
networks with unconventional settings.  For example, will clients with a
marginal MCS 7 connection probe for their next AP before their retry rate
goes through the roof?
- We use 40Mhz channels, so reliable comm at MCS 7 requires about 28 dB
SNR.  It could be very difficult to maintain that while moving.
- Even if clients roam successfully, you'll see an increase in roaming
activity.  Moving clients may normally hit every second or third AP along
the way, in your case they'll probably hit every AP.  This could increase
the overhead consumed by authentication and/or stress your AAA
infrastructure.  That said, the AAA load could be more than offset by
reduced authentication attempts to indoor APs from outdoor passers-by.

I'm not suggesting these are reasons not to do it.  They're just things
I'd worry about.  I'd be interested in hearing how it works out for you if
you find the time to follow up.  

Thanks,

Chuck

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Rick.Decaro
Sent: Monday, June 20, 2016 2:10 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

It sound like a lot of people have already disabled the 802.11b data
rates.   That being saidwhat minimum rate is everyone using?  

We just changed ours last week from a minimum of 1Mbps to 54Mbps.   So far
we have not heard of any issues.Does anyone know what if any problems
could arise from this being set to 54Mbps?   Is there a sweet spot in
between that is better? 

Thanks,

Rick DeCaro
(636)230-1911
rick.dec...@logan.edu


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Watters, John
Sent: Monday, June 20, 2016 1:01 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

We have had the b rates disabled for 2 months short of 5 years. Not a
single complaint that I am aware of.


-jcw

John WattersThe University of Alabama
Office of Information Technology
205-348-3992
 


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Todd M. Hall
Sent: Monday, June 20, 2016 10:50 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] 802.11b data rates disabled?

Do you have all of the 802.11b data rates disabled?  If so, how long have
they been disabled?  Did you have many complaints when you disabled them?
Were there any particular devices that could not connect as a result?

I'm hoping this information will help us move towards disabling these old
rates. 
Thank you for your feedback.

--
Todd M. Hall
Sr. Network Analyst
Information Technology Services
Mississippi State University
t...@msstate.edu
662-325-9311 (phone)

**
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] 802.11b data rates disabled?

[Jeremy Mooney]

Not specifically. That's something I haven't seen a straight answer on how
the options interact (Cisco), and haven't spent the time to research yet.
Technically all the a/b/g rates are a modulation and coding scheme and have
MCS bits, although the term (especially with "index" and the number scheme)
often seems to only refer to the n+ standard options. In any case the main
goal was to keep broadcast traffic and distant clients from using
disproportionate airtime, which setting the base rate solved. I figured
even if it's possible for a client to drop to the lower rates under n or ac
for its private traffic, it's unlikely to do so if it's able to maintain an
association at 24+ for the base stream and we could revisit if it became an
issue.

On Mon, Jun 20, 2016 at 1:38 PM, McClintic, Thomas <
thomas.mcclin...@uth.tmc.edu> wrote:

> Your mention of QAM peaks my interest. Have you disabled lower MCS index
> rates? I’ve often wondered if we disabled 18 and below but leave MCS 0-2
> enabled, can clients use that lower rate on HT and VHT? This is included in
> both beacons and probe responses.
>
>
>
> To the original topic, we have b disabled for at least 2 years. No issues
> or concerns. In fact, we only see about 5% of users on a/g. n is very
> prevalent now.
>
>
>
>
>
> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Jeremy Mooney
> *Sent:* Monday, June 20, 2016 1:14 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] 802.11b data rates disabled?
>
>
>
> We've had b disabled for several years, and when we did a complete
> wireless replacement last year dropped rates below 24Mbps to get everything
> up to QAM. The only definite complaints I know about are the Wii users
> everyone else has mentioned. Eliminating the rates would have effectively
> shrunk cell size (indirectly the point - force a roam), but given the
> entire system was replaced as well we've just been addressing them as
> coverage issues (which we also knew existed before the swap) so can't
> quantify that impact.
>
>
>
> On Mon, Jun 20, 2016 at 10:49 AM, Todd M. Hall  wrote:
>
> Do you have all of the 802.11b data rates disabled?  If so, how long have
> they been disabled?  Did you have many complaints when you disabled them?
> Were there any particular devices that could not connect as a result?
>
> I'm hoping this information will help us move towards disabling these old
> rates. Thank you for your feedback.
>
> --
> Todd M. Hall
> Sr. Network Analyst
> Information Technology Services
> Mississippi State University
> t...@msstate.edu
> 662-325-9311 (phone)
>
> **
> Participation and subscription information for this EDUCAUSE Constituent
> Group discussion list can be found at http://www.educause.edu/groups/
> 
> .
>
>
>
>
>
> --
>
> Jeremy Mooney
>
> ITS - Bethel 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/.
>
>


-- 
Jeremy Mooney
ITS - Bethel University

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

RE: [WIRELESS-LAN] 802.11b data rates disabled?

[Watters, John]

We have our minimum/required rate set at 12 Mbps but may go up to 18 in August 
(after the summer term and before the kids come back for fall).


-jcw

John WattersThe University of Alabama
Office of Information Technology
205-348-3992
 


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Rick.Decaro
Sent: Monday, June 20, 2016 1:10 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

It sound like a lot of people have already disabled the 802.11b data rates.   
That being saidwhat minimum rate is everyone using?  

We just changed ours last week from a minimum of 1Mbps to 54Mbps.   So far we 
have not heard of any issues.Does anyone know what if any problems could 
arise from this being set to 54Mbps?   Is there a sweet spot in between that is 
better? 

Thanks,

Rick DeCaro
(636)230-1911
rick.dec...@logan.edu


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Watters, John
Sent: Monday, June 20, 2016 1:01 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

We have had the b rates disabled for 2 months short of 5 years. Not a single 
complaint that I am aware of.


-jcw

John WattersThe University of Alabama
Office of Information Technology
205-348-3992
 


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Todd M. Hall
Sent: Monday, June 20, 2016 10:50 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] 802.11b data rates disabled?

Do you have all of the 802.11b data rates disabled?  If so, how long have they 
been disabled?  Did you have many complaints when you disabled them?  Were 
there any particular devices that could not connect as a result?

I'm hoping this information will help us move towards disabling these old 
rates. 
Thank you for your feedback.

--
Todd M. Hall
Sr. Network Analyst
Information Technology Services
Mississippi State University
t...@msstate.edu
662-325-9311 (phone)

**
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] 802.11b data rates disabled?

[Chuck Enfield]

Be aware, the minimum rate question is far less straight-forward than the
11b rates question.  The latter is really an issue of client device
compatibility - something we can expect to be similar across our market
sector.  In addition client device compatibility, minimum data rate
depends upon signal strength, noise level, and channel width.

That said, if you use 40MHz channels and maintain an SNR >= 20dB (I assume
that's most of us these days), you can definitely disable MCS 1 & 2 -
probably even MCS 3.

Chuck

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Rick.Decaro
Sent: Monday, June 20, 2016 2:10 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

It sound like a lot of people have already disabled the 802.11b data
rates.   That being saidwhat minimum rate is everyone using?  

We just changed ours last week from a minimum of 1Mbps to 54Mbps.   So far
we have not heard of any issues.Does anyone know what if any problems
could arise from this being set to 54Mbps?   Is there a sweet spot in
between that is better? 

Thanks,

Rick DeCaro
(636)230-1911
rick.dec...@logan.edu


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Watters, John
Sent: Monday, June 20, 2016 1:01 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

We have had the b rates disabled for 2 months short of 5 years. Not a
single complaint that I am aware of.


-jcw

John WattersThe University of Alabama
Office of Information Technology
205-348-3992
 


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Todd M. Hall
Sent: Monday, June 20, 2016 10:50 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] 802.11b data rates disabled?

Do you have all of the 802.11b data rates disabled?  If so, how long have
they been disabled?  Did you have many complaints when you disabled them?
Were there any particular devices that could not connect as a result?

I'm hoping this information will help us move towards disabling these old
rates. 
Thank you for your feedback.

--
Todd M. Hall
Sr. Network Analyst
Information Technology Services
Mississippi State University
t...@msstate.edu
662-325-9311 (phone)

**
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] 802.11b data rates disabled?

[Kanan E Simpson]

Rick, 
I'm not sure of issues other than shrinking the AP cell size. With a minimum 
data rate of 54mbps, you must have a dense ap deployment. How many redundant 
aps are you surveyed for?

Thanks,

Kanan Simpson, CWNA, JNCIA
Network Services Specialist
Information Technology Division
Valdosta State University
Dept: 229-333-7396
Office: 229-333-5740
Helpdesk: 229-245-4357


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Rick.Decaro
Sent: Monday, June 20, 2016 2:10 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

It sound like a lot of people have already disabled the 802.11b data rates.   
That being saidwhat minimum rate is everyone using?  

We just changed ours last week from a minimum of 1Mbps to 54Mbps.   So far we 
have not heard of any issues.Does anyone know what if any problems could 
arise from this being set to 54Mbps?   Is there a sweet spot in between that is 
better? 

Thanks,

Rick DeCaro
(636)230-1911
rick.dec...@logan.edu


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Watters, John
Sent: Monday, June 20, 2016 1:01 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

We have had the b rates disabled for 2 months short of 5 years. Not a single 
complaint that I am aware of.


-jcw

John WattersThe University of Alabama
Office of Information Technology
205-348-3992
 


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Todd M. Hall
Sent: Monday, June 20, 2016 10:50 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] 802.11b data rates disabled?

Do you have all of the 802.11b data rates disabled?  If so, how long have they 
been disabled?  Did you have many complaints when you disabled them?  Were 
there any particular devices that could not connect as a result?

I'm hoping this information will help us move towards disabling these old 
rates. 
Thank you for your feedback.

--
Todd M. Hall
Sr. Network Analyst
Information Technology Services
Mississippi State University
t...@msstate.edu
662-325-9311 (phone)

**
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] 802.11b data rates disabled?

[Chuck Enfield]

I'm eagerly awaiting my invitation to the anniversary party.

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Watters, John
Sent: Monday, June 20, 2016 2:01 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

We have had the b rates disabled for 2 months short of 5 years. Not a
single complaint that I am aware of.


-jcw

John WattersThe University of Alabama
Office of Information Technology
205-348-3992
 


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Todd M. Hall
Sent: Monday, June 20, 2016 10:50 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] 802.11b data rates disabled?

Do you have all of the 802.11b data rates disabled?  If so, how long have
they been disabled?  Did you have many complaints when you disabled them?
Were there any particular devices that could not connect as a result?

I'm hoping this information will help us move towards disabling these old
rates. 
Thank you for your feedback.

--
Todd M. Hall
Sr. Network Analyst
Information Technology Services
Mississippi State University
t...@msstate.edu
662-325-9311 (phone)

**
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] 802.11b data rates disabled?

[McClintic, Thomas]

Your mention of QAM peaks my interest. Have you disabled lower MCS index rates? 
I’ve often wondered if we disabled 18 and below but leave MCS 0-2 enabled, can 
clients use that lower rate on HT and VHT? This is included in both beacons and 
probe responses.

To the original topic, we have b disabled for at least 2 years. No issues or 
concerns. In fact, we only see about 5% of users on a/g. n is very prevalent 
now.


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeremy Mooney
Sent: Monday, June 20, 2016 1:14 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

We've had b disabled for several years, and when we did a complete wireless 
replacement last year dropped rates below 24Mbps to get everything up to QAM. 
The only definite complaints I know about are the Wii users everyone else has 
mentioned. Eliminating the rates would have effectively shrunk cell size 
(indirectly the point - force a roam), but given the entire system was replaced 
as well we've just been addressing them as coverage issues (which we also knew 
existed before the swap) so can't quantify that impact.

On Mon, Jun 20, 2016 at 10:49 AM, Todd M. Hall 
> wrote:
Do you have all of the 802.11b data rates disabled?  If so, how long have they 
been disabled?  Did you have many complaints when you disabled them?  Were 
there any particular devices that could not connect as a result?

I'm hoping this information will help us move towards disabling these old 
rates. Thank you for your feedback.

--
Todd M. Hall
Sr. Network Analyst
Information Technology Services
Mississippi State University
t...@msstate.edu
662-325-9311 (phone)

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at 
http://www.educause.edu/groups/.



--
Jeremy Mooney
ITS - Bethel 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] 802.11b data rates disabled?

[Jeremy Mooney]

We've had b disabled for several years, and when we did a complete wireless
replacement last year dropped rates below 24Mbps to get everything up to
QAM. The only definite complaints I know about are the Wii users everyone
else has mentioned. Eliminating the rates would have effectively shrunk
cell size (indirectly the point - force a roam), but given the entire
system was replaced as well we've just been addressing them as coverage
issues (which we also knew existed before the swap) so can't quantify that
impact.

On Mon, Jun 20, 2016 at 10:49 AM, Todd M. Hall  wrote:

> Do you have all of the 802.11b data rates disabled?  If so, how long have
> they been disabled?  Did you have many complaints when you disabled them?
> Were there any particular devices that could not connect as a result?
>
> I'm hoping this information will help us move towards disabling these old
> rates. Thank you for your feedback.
>
> --
> Todd M. Hall
> Sr. Network Analyst
> Information Technology Services
> Mississippi State University
> t...@msstate.edu
> 662-325-9311 (phone)
>
> **
> Participation and subscription information for this EDUCAUSE Constituent
> Group discussion list can be found at http://www.educause.edu/groups/.
>



-- 
Jeremy Mooney
ITS - Bethel University

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

RE: [WIRELESS-LAN] 802.11b data rates disabled?

[Rick . Decaro]

It sound like a lot of people have already disabled the 802.11b data rates.   
That being saidwhat minimum rate is everyone using?  

We just changed ours last week from a minimum of 1Mbps to 54Mbps.   So far we 
have not heard of any issues.Does anyone know what if any problems could 
arise from this being set to 54Mbps?   Is there a sweet spot in between that is 
better? 

Thanks,

Rick DeCaro
(636)230-1911
rick.dec...@logan.edu


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Watters, John
Sent: Monday, June 20, 2016 1:01 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?

We have had the b rates disabled for 2 months short of 5 years. Not a single 
complaint that I am aware of.


-jcw

John WattersThe University of Alabama
Office of Information Technology
205-348-3992
 


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Todd M. Hall
Sent: Monday, June 20, 2016 10:50 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] 802.11b data rates disabled?

Do you have all of the 802.11b data rates disabled?  If so, how long have they 
been disabled?  Did you have many complaints when you disabled them?  Were 
there any particular devices that could not connect as a result?

I'm hoping this information will help us move towards disabling these old 
rates. 
Thank you for your feedback.

--
Todd M. Hall
Sr. Network Analyst
Information Technology Services
Mississippi State University
t...@msstate.edu
662-325-9311 (phone)

**
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] 802.11b data rates disabled?

[Watters, John]

We have had the b rates disabled for 2 months short of 5 years. Not a single 
complaint that I am aware of.


-jcw

John WattersThe University of Alabama
Office of Information Technology
205-348-3992
 


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Todd M. Hall
Sent: Monday, June 20, 2016 10:50 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] 802.11b data rates disabled?

Do you have all of the 802.11b data rates disabled?  If so, how long have they 
been disabled?  Did you have many complaints when you disabled them?  Were 
there any particular devices that could not connect as a result?

I'm hoping this information will help us move towards disabling these old 
rates. 
Thank you for your feedback.

--
Todd M. Hall
Sr. Network Analyst
Information Technology Services
Mississippi State University
t...@msstate.edu
662-325-9311 (phone)

**
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.11b data rates disabled?

[Bucklaew, Jerry]

On 06/20/2016 11:50 AM, Todd M. Hall wrote:
> Do you have all of the 802.11b data rates disabled?  If so, how long have they
> been disabled?  Did you have many complaints when you disabled them?  Were 
> there
> any particular devices that could not connect as a result?
>
> I'm hoping this information will help us move towards disabling these old 
> rates.
> Thank you for your feedback.
>


We did it about 2 years ago, our lowest 2.4ghz rate is 18meg.   We had the wii 
issue also, but very few of them.

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

RE: [WIRELESS-LAN] 802.11b data rates disabled?

[Chuck Enfield]

We shut off 802.11b rates in 2011.  While we received no complaints about 
incompatible devices, it’s worth mentioning that our only SSID was 
WPA2-Enterpirse.  We knew going in that there we few if any 802.11b devices 
could connect anyway.  In fact, that’s what encouraged us to shut it off. 
We had lots of devices connecting at 802.11b data rates that we knew shouldn’t 
be.  Once those rates were disabled, some of those devices just naturally 
started connecting at g-rates and some stopped connecting until their 
drivers were updated, but it allowed us to solve a problem that was severely 
hurting network performance.



Chuck Enfield

Manager, Wireless Systems & Engineering

Telecommunications & Networking Services

The Pennsylvania State University

110H, USB2, UP, PA 16802

ph: 814.863.8715

fx: 814.865.3988



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Samuel Clements
Sent: Monday, June 20, 2016 11:56 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] 802.11b data rates disabled?



I think we've arrived at a point where most 802.11b devices are flat out 
deprecated. I also believe that you're going to run into far more 802.11g 
devices that don't like 1 & 2 being disabled (most notably the Nintendo Wii) 
than you are people that actually expect an 802.11b device to still 
function. Between that, and the significant positive impact to CU that 
you'll undoubtedly get, it's a very timely conversation to be having. 
Unfortunately, you can't rely on your NMS platforms reporting of 802.11b 
devices since many .11g clients will stick further out than what's 
reasonable using CCK modulation (and showing .11b clients). In all instances 
in recent memory (say, 2 years), I've had the number of complaints by 
disabling .11b data rates be so low as to be background noise. Couple the 
ethernet adapter for the Wii into the equation, and the problems are 
practically nonexistent except in the most corner of cases.

  -Sam



On Mon, Jun 20, 2016 at 10:49 AM, Todd M. Hall  > wrote:

Do you have all of the 802.11b data rates disabled?  If so, how long have 
they been disabled?  Did you have many complaints when you disabled them? 
Were there any particular devices that could not connect as a result?

I'm hoping this information will help us move towards disabling these old 
rates. Thank you for your feedback.

-- 
Todd M. Hall
Sr. Network Analyst
Information Technology Services
Mississippi State University
t...@msstate.edu 
662-325-9311   (phone)

**
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] 802.11b data rates disabled?

[Matthew Newton]

On Mon, Jun 20, 2016 at 10:49:35AM -0500, Todd M. Hall wrote:
> Do you have all of the 802.11b data rates disabled?

Yes.

> If so, how long have they been disabled?

Two or three years IIRC.

> Did you have many complaints when you disabled them?

None.

> Were there any particular devices that could not connect as a
> result?

Probably, but we never heard of them.

I seem to remember we saw about three 11b clients connected before
we killed it.

> I'm hoping this information will help us move towards disabling these old
> rates.

We're beaconing at 24Mpbs. For 2.4ghz the slowest rate we allow
allow is 12Mbps, and for 5Gzh the slowest is 24Mbps.

The thing to watch out is that your coverage area will drop (which
is probably a good thing, but you may need to install more APs...)

Matthew


-- 
Matthew Newton, Ph.D. 

Systems Specialist, Infrastructure Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, 

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

Re: [WIRELESS-LAN] 802.11b data rates disabled?

[Reyes, Esteban]

RIP 802.11b

Esteban Reyes 

Sent from my iPhone

> On Jun 20, 2016, at 11:03 AM, Kanan E Simpson  wrote:
> 
> We disabled the 11b rates last summer. For the most part, we didn't have too 
> many complaints. The complaints that we received was from the students that 
> own the legacy Wii. All though the devices support 11g, it must see the SSID 
> broadcasted at a 11b (1mbps) rate in order to connect.  This was the only 
> complaint. We no longer support the original Wii.
> 
> We also have institutional devices at that are older and only support 11b. 
> For these devices, we simply left the 11b rates on for the APs in the area 
> they connect. Thankfully, it's only one building. 
> 
> 
> Thanks,
> 
> Kanan Simpson, CWNA, JNCIA
> Network Services Specialist
> Information Technology Division
> Valdosta State University
> 
> -Original Message-
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Todd M. Hall
> Sent: Monday, June 20, 2016 11:50 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: [WIRELESS-LAN] 802.11b data rates disabled?
> 
> Do you have all of the 802.11b data rates disabled?  If so, how long have 
> they been disabled?  Did you have many complaints when you disabled them?  
> Were there any particular devices that could not connect as a result?
> 
> I'm hoping this information will help us move towards disabling these old 
> rates. 
> Thank you for your feedback.
> 
> --
> Todd M. Hall
> Sr. Network Analyst
> Information Technology Services
> Mississippi State University
> t...@msstate.edu
> 662-325-9311 (phone)
> 
> **
> 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] 802.11b data rates disabled?

[Frank Sweetser]

We killed off all 11b data rates about two years ago.  We've had no 
complaints, but also don't have any wireless network set up to handle non-1x 
devices, like game consoles.


Frank Sweetser fs at wpi.edu|  For every problem, there is a solution that
Manager of Network Operations   |  is simple, elegant, and wrong.
Worcester Polytechnic Institute |   - HL Mencken

On 06/20/2016 11:49 AM, Todd M. Hall wrote:

Do you have all of the 802.11b data rates disabled?  If so, how long have they
been disabled?  Did you have many complaints when you disabled them?  Were
there any particular devices that could not connect as a result?

I'm hoping this information will help us move towards disabling these old
rates. Thank you for your feedback.



**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

RE: [WIRELESS-LAN] 802.11b data rates disabled?

[Kanan E Simpson]

We disabled the 11b rates last summer. For the most part, we didn't have too 
many complaints. The complaints that we received was from the students that own 
the legacy Wii. All though the devices support 11g, it must see the SSID 
broadcasted at a 11b (1mbps) rate in order to connect.  This was the only 
complaint. We no longer support the original Wii.

We also have institutional devices at that are older and only support 11b. For 
these devices, we simply left the 11b rates on for the APs in the area they 
connect. Thankfully, it's only one building. 


Thanks,

Kanan Simpson, CWNA, JNCIA
Network Services Specialist
Information Technology Division
Valdosta State University

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Todd M. Hall
Sent: Monday, June 20, 2016 11:50 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] 802.11b data rates disabled?

Do you have all of the 802.11b data rates disabled?  If so, how long have they 
been disabled?  Did you have many complaints when you disabled them?  Were 
there any particular devices that could not connect as a result?

I'm hoping this information will help us move towards disabling these old 
rates. 
Thank you for your feedback.

--
Todd M. Hall
Sr. Network Analyst
Information Technology Services
Mississippi State University
t...@msstate.edu
662-325-9311 (phone)

**
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.11b data rates disabled?

[Jeremy Gibbs]

Gone for 2 years.  We have had only a handful of people complain, mostly
about the Wii.




*--Jeremy L. Gibbs*
Sr. Network Engineer
Utica College IITS

On Mon, Jun 20, 2016 at 11:57 AM, Britton Anderson 
wrote:

> We have had them disabled now for about two years now. When we were
> planning this, we had about 10 routine clients that were associating at
> .11b rates routinely on our guest network--so we couldn't identify them,
> just where they were connecting. When we pitched this, we thought it best
> to invest in a couple dozen low profile USB wifi NICs that we were certain
> worked with Windows 2000 that we could hand out to clients that requested
> them. I think we bought 20 total of a couple different models, and I still
> have a handful left.
>
> Could be a possible avenue for you. Good luck.
>
>
>
> Britton Anderson  |  Senior Network
> Communications Specialist |  University of Alaska
>  |  907.450.8250
>
> On Mon, Jun 20, 2016 at 7:49 AM, Todd M. Hall  wrote:
>
>> Do you have all of the 802.11b data rates disabled?  If so, how long have
>> they been disabled?  Did you have many complaints when you disabled them?
>> Were there any particular devices that could not connect as a result?
>>
>> I'm hoping this information will help us move towards disabling these old
>> rates. Thank you for your feedback.
>>
>> --
>> Todd M. Hall
>> Sr. Network Analyst
>> Information Technology Services
>> Mississippi State University
>> t...@msstate.edu
>> 662-325-9311 (phone)
>>
>> **
>> 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] 802.11b data rates disabled?

[Britton Anderson]

We have had them disabled now for about two years now. When we were
planning this, we had about 10 routine clients that were associating at
.11b rates routinely on our guest network--so we couldn't identify them,
just where they were connecting. When we pitched this, we thought it best
to invest in a couple dozen low profile USB wifi NICs that we were certain
worked with Windows 2000 that we could hand out to clients that requested
them. I think we bought 20 total of a couple different models, and I still
have a handful left.

Could be a possible avenue for you. Good luck.



Britton Anderson  |  Senior Network Communications
Specialist |  University of Alaska  |
 907.450.8250

On Mon, Jun 20, 2016 at 7:49 AM, Todd M. Hall  wrote:

> Do you have all of the 802.11b data rates disabled?  If so, how long have
> they been disabled?  Did you have many complaints when you disabled them?
> Were there any particular devices that could not connect as a result?
>
> I'm hoping this information will help us move towards disabling these old
> rates. Thank you for your feedback.
>
> --
> Todd M. Hall
> Sr. Network Analyst
> Information Technology Services
> Mississippi State University
> t...@msstate.edu
> 662-325-9311 (phone)
>
> **
> 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.11b data rates disabled?

[Samuel Clements]

I think we've arrived at a point where most 802.11b devices are flat out
deprecated. I also believe that you're going to run into far more 802.11g
devices that don't like 1 & 2 being disabled (most notably the Nintendo
Wii) than you are people that actually expect an 802.11b device to still
function. Between that, and the significant positive impact to CU that
you'll undoubtedly get, it's a very timely conversation to be having.
Unfortunately, you can't rely on your NMS platforms reporting of 802.11b
devices since many .11g clients will stick further out than what's
reasonable using CCK modulation (and showing .11b clients). In all
instances in recent memory (say, 2 years), I've had the number of
complaints by disabling .11b data rates be so low as to be background
noise. Couple the ethernet adapter for the Wii into the equation, and the
problems are practically nonexistent except in the most corner of cases.
  -Sam

On Mon, Jun 20, 2016 at 10:49 AM, Todd M. Hall  wrote:

> Do you have all of the 802.11b data rates disabled?  If so, how long have
> they been disabled?  Did you have many complaints when you disabled them?
> Were there any particular devices that could not connect as a result?
>
> I'm hoping this information will help us move towards disabling these old
> rates. Thank you for your feedback.
>
> --
> Todd M. Hall
> Sr. Network Analyst
> Information Technology Services
> Mississippi State University
> t...@msstate.edu
> 662-325-9311 (phone)
>
> **
> 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.11b data rates disabled?

[Todd M. Hall]

Do you have all of the 802.11b data rates disabled?  If so, how long have they 
been disabled?  Did you have many complaints when you disabled them?  Were there 
any particular devices that could not connect as a result?


I'm hoping this information will help us move towards disabling these old rates. 
Thank you for your feedback.


--
Todd M. Hall
Sr. Network Analyst
Information Technology Services
Mississippi State University
t...@msstate.edu
662-325-9311 (phone)

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.