Re: [WIRELESS-LAN] Aruba Instant IAP-215 Wireless Access Points

[Frans Panken]

We experienced that LLDP does not work properly in the case of non Cisco
the switches.
We have 3700 APs and Juniper switches. The APs require PoE+ to function
with all MIMO capabilities (4 spatial streams). The WLC tells us that
there is no PoE+. With Cisco switches, the WLC does mention that there
is PoE+. Even with a PoE+ injector of Cisco, the WLC still mentions PoE.
This was when we used 8.0 MR1. Clients could still use 4 spatial
streams. We were told this was a Cisco bug and the problem would be
solved in MR2 (which we are not intending to use).
According to the Juniper swith, the APs use less power than you would
expect:

InterfaceAdmin   OperMaxPriority   Power  Class
 status  status  power consumption
ge-6/0/15Enabled  ON 30.0W  Low4.3W4
ge-6/0/18Enabled  ON 30.0W  Low6.7W4
ge-6/0/19Enabled  ON 30.0W  Low6.1W4
ge-6/0/20Enabled  ON 30.0W  Low6.3W4
ge-6/0/21Enabled  ON 30.0W  Low6.1W4





Jake Snyder schreef op 15/09/15 om 03:20:
> The other thing you might check is to see if you have LLDP running on the 
> switches.  This can help with Poe negotiation.
>
> Thanks
> Jake Snyder
>
>
> Sent from my iPhone
>
>> On Sep 14, 2015, at 6:53 PM, James Michael Keller  
>> wrote:
>>
>>> On 09/14/2015 11:37 AM, Ronald Loneker wrote:
>>> Good Morning -
>>>
>>> (forgive cross-postings - a member of the NETMAN list suggested this
>>> might be the place to post this question)
>>>
>>> We just had close to 90 new Aruba Instant IAP-215 wireless access points
>>> installed in our residence halls to upgrade our wireless network. 
>>> Another building is soon to be underway, and I'm managing this project.
>>>
>>> Over the last couple of weeks, it seems like random access points are
>>> shutting down wireless access.  They are not all connected to the same
>>> Cisco switch (various Cisco POE switches in two residence halls).  The
>>> access point is not ping-able, the MAC address is not found in the
>>> virtual controller's table, the switch port is up and power is being
>>> supplied to the access point.  The only way we seem to get an access
>>> point back up is to do a shut/no shut on the switch port to which it is
>>> connected. 
>>>
>>> The vendor who configured the access points hasn't been able to
>>> determine why this is happening and before we initiate an Aruba support
>>> call, I was wondering if anyone had any similar experiences like this
>>> and what you determined was the cause of the issue.  We are running into
>>> walls here.
>>>
>>> Thanks in advance for any thoughts or ideas.
>>>
>>> Ron Loneker, Jr.
>>> Director of Media Services
>>> College of Saint Elizabeth
>>> Mahoney Library
>>> 2 Convent Road
>>> Morristown, NJ  07960
>>>
>>> Phone:  973-290-4229 
>>>
>>> e-mail:  rlone...@cse.edu 
>>>
>>> /**/
>>>
>>>
>>> ** Participation and subscription information for this EDUCAUSE
>>> Constituent Group discussion list can be found at
>>> http://www.educause.edu/groups/.
>> I have seen similar with the campus APs when the PoE power is either
>> dropping below min spec either due to switch power or cable run
>> resistance.   The APs will have enough power to initialize which brings
>> up the link, but they fail to boot into ArubaOS and hang until they are
>> power cycled.  Typically the ones with cable run issues continue to fail
>> on the next cycle.  Brown out triggered ones come up fine usually, and
>> typically we see more then one on the same switch do it for PoE power
>> issues.
>>
>> -- 
>>
>> -James
>>
>>
>> **
>> 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] FreeRADIUS Diffie-Hellman Keys and iOS9

[Bruce Curtis]

  We have not had any reported issues since we increased the size to 2048.  

  In fact the person with the Chromebook that reported the problem also 
reported that after the size increase he tried the process to connect his 
Android phone to our wireless and was very pleased with how easy it was 
compared to the last time he tried.  But I suspect the improvement in his 
experience had more to do with changes to our installation portal and to 
improvements in the XpressConnect client since the last time he tried 
connecting his Android phone.


On Sep 15, 2015, at 10:44 AM, Chuck Anderson  wrote:

> Does this change cause any other client incompatibilities or require
> any changes to existing clients?
> 
> On Tue, Sep 15, 2015 at 03:04:36PM +, Bruce Curtis wrote:
>> When we increased the size of our key Google had found a reference to 
>> putting this line in EAP.conf.
>> 
>>dh_key_length = 2048
>> 
>> I have not tested without the line but the presence of the line does not 
>> prevent freeradius from running and the device that was complaining about 
>> the size of the key now works.
>> 
>> On Sep 15, 2015, at 8:34 AM, Walter Reynolds  wrote:
>> 
>>> On freeradius does it use the size of the key or do you have to specify 
>>> somewhere?
>>> 
>>> When I put in a dh key that is 2048 and run in debug mode I see the 
>>> following
>>> 
>>> Tue Sep 15 09:30:18 2015 : Debug:  Module: Instantiating eap-tls
>>> Tue Sep 15 09:30:18 2015 : Debug:tls {
>>> Tue Sep 15 09:30:18 2015 : Debug:   rsa_key_exchange = no
>>> Tue Sep 15 09:30:18 2015 : Debug:   dh_key_exchange = yes
>>> Tue Sep 15 09:30:18 2015 : Debug:   rsa_key_length = 512
>>> Tue Sep 15 09:30:18 2015 : Debug:   dh_key_length = 512
>>> 
>>> But I verified the file itself.
>>> 
>>> [root@aaa-maccvm-05 certs]# openssl dhparam -in dh -text -noout
>>>PKCS#3 DH Parameters: (2048 bit)
>>> 
>>> 
>>> 
>>> 
>>> Walter Reynolds
>>> Principal Systems Security Development Engineer
>>> Information and Technology Services
>>> University of Michigan
>>> (734) 615-9438
>>> 
>>> On Mon, Sep 14, 2015 at 8:43 AM, Christopher Michael Allison 
>>>  wrote:
>>> Actually, We Upgraded to FreeRadius 2.2.8 to solve some issues with iOS9. 
>>> We have been using a 2048 bit Diffie-Hellman.  And it is a must do ASAP as 
>>> when it rolls out official you will have issues with clients connecting. 
>>> Also if you aren't on FreeRadius 2.2.7 or higher you will run into the same 
>>> issues that we did. Radius will answer the iOS9 clients TLS v1.2 Hello but 
>>> can't transmit anything back to it so the client will never authenticate.
>>> 
>>> Thanks,
>>> 
>>> CHRISTOPHER ALLISON
>>> Network Engineer I
>>> 
>>> Information Technology
>>> Mail Code 4622
>>> 625 Wham Drive
>>> Carbondale, Illinois 62901
>>> 
>>> chris.m.alli...@siu.edu
>>> P: 618 / 453 - 8415
>>> F: 618 / 453 - 5261
>>> INFOTECH.SIU.EDU
>>> 
>>> 
>>> 
>>> "Choose a job you love, and you will never have to work a day in your life."
>>> Confucius
>>> 
>>> 
>>> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
>>>  on behalf of Bruce Curtis 
>>> 
>>> Sent: Sunday, September 13, 2015 6:14 AM
>>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>>> Subject: Re: [WIRELESS-LAN] FreeRADIUS Diffie-Hellman Keys and iOS9
>>> 
>>>  We just upgraded to 2048 bit Diffie-Helman won September 3.   We had a 
>>> person come to the help desk with a Chromebook that stopped connecting to 
>>> the wireless on September 1, after an OS update.  We had been using a 512 
>>> bit Diffie Helman key.
>>> 
>>> 
>>> 
>>> 2015-09-03T18:01:36.709399+00:00 NOTICE wpa_supplicant[472]: OpenSSL: 
>>> openssl_handshake - SSL_connect error:14082174:SSL 
>>> routines:ssl3_check_cert_and_algorithm:dh key too small
>>> 
>>> On Sep 11, 2015, at 4:55 PM, Curtis K. Larsen  
>>> wrote:
>>> 
 Hello,
 
 Are any other FreeRADIUS users planning to upgrade to 2048 bit 
 Diffie-Hellman keys before the iOS9 release?  Just came across these and 
 thinking it's a must do ASAP:
 
 https://support.apple.com/en-us/HT204932
 https://community.jisc.ac.uk/blogs/8021x-clients-and-radius-server-supporting-bigger-diffie-hellman-dh-keys
> 
> **
> Participation and subscription information for this EDUCAUSE Constituent 
> Group discussion list can be found at http://www.educause.edu/groups/.

---
Bruce Curtis bruce.cur...@ndsu.edu
Certified NetAnalyst II701-231-8527
North Dakota State University

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

Re: [WIRELESS-LAN] FreeRADIUS Diffie-Hellman Keys and iOS9

[John Rodkey]

Interesting...  because when I installed a DH2048 key without adding the
dh_key_length parameter, users were not able to authenticate.
When I added the length, things worked.   I'm good with it just being
magic, as long as it works...

John Rodkey
Director of Servers and Networks
Westmont College

On Tue, Sep 15, 2015 at 9:10 AM, Walter Reynolds  wrote:

> Based on the following link, it implies that flag does not do anything.
> It is old, but did the same thing on code I am running (2.2.8)
>
> http://freeradius.1045715.n5.nabble.com/Why-is-the-default-DH-keysize-only-512-bits-td2754757.html
>
>
>
>
> 
> Walter Reynolds
> Principal Systems Security Development Engineer
> Information and Technology Services
> University of Michigan
> (734) 615-9438
>
> On Tue, Sep 15, 2015 at 11:04 AM, Bruce Curtis 
> wrote:
>
>> When we increased the size of our key Google had found a reference to
>> putting this line in EAP.conf.
>>
>> dh_key_length = 2048
>>
>> I have not tested without the line but the presence of the line does not
>> prevent freeradius from running and the device that was complaining about
>> the size of the key now works.
>>
>> On Sep 15, 2015, at 8:34 AM, Walter Reynolds  wrote:
>>
>> > On freeradius does it use the size of the key or do you have to specify
>> somewhere?
>> >
>> > When I put in a dh key that is 2048 and run in debug mode I see the
>> following
>> >
>> > Tue Sep 15 09:30:18 2015 : Debug:  Module: Instantiating eap-tls
>> > Tue Sep 15 09:30:18 2015 : Debug:tls {
>> > Tue Sep 15 09:30:18 2015 : Debug:   rsa_key_exchange = no
>> > Tue Sep 15 09:30:18 2015 : Debug:   dh_key_exchange = yes
>> > Tue Sep 15 09:30:18 2015 : Debug:   rsa_key_length = 512
>> > Tue Sep 15 09:30:18 2015 : Debug:   dh_key_length = 512
>> >
>> > But I verified the file itself.
>> >
>> > [root@aaa-maccvm-05 certs]# openssl dhparam -in dh -text -noout
>> > PKCS#3 DH Parameters: (2048 bit)
>> >
>> >
>> >
>> > 
>> > Walter Reynolds
>> > Principal Systems Security Development Engineer
>> > Information and Technology Services
>> > University of Michigan
>> > (734) 615-9438
>> >
>> > On Mon, Sep 14, 2015 at 8:43 AM, Christopher Michael Allison <
>> chris.m.alli...@siu.edu> wrote:
>> > Actually, We Upgraded to FreeRadius 2.2.8 to solve some issues with
>> iOS9. We have been using a 2048 bit Diffie-Hellman.  And it is a must do
>> ASAP as when it rolls out official you will have issues with clients
>> connecting. Also if you aren't on FreeRadius 2.2.7 or higher you will run
>> into the same issues that we did. Radius will answer the iOS9 clients TLS
>> v1.2 Hello but can't transmit anything back to it so the client will never
>> authenticate.
>> >
>> > Thanks,
>> >
>> > CHRISTOPHER ALLISON
>> > Network Engineer I
>> >
>> > Information Technology
>> > Mail Code 4622
>> > 625 Wham Drive
>> > Carbondale, Illinois 62901
>> >
>> > chris.m.alli...@siu.edu
>> > P: 618 / 453 - 8415
>> > F: 618 / 453 - 5261
>> > INFOTECH.SIU.EDU
>> >
>> >
>> >
>> > "Choose a job you love, and you will never have to work a day in your
>> life."
>> > Confucius
>> >
>> > 
>> > From: The EDUCAUSE Wireless Issues Constituent Group Listserv <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Bruce Curtis <
>> bruce.cur...@ndsu.edu>
>> > Sent: Sunday, September 13, 2015 6:14 AM
>> > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> > Subject: Re: [WIRELESS-LAN] FreeRADIUS Diffie-Hellman Keys and iOS9
>> >
>> >   We just upgraded to 2048 bit Diffie-Helman won September 3.   We had
>> a person come to the help desk with a Chromebook that stopped connecting to
>> the wireless on September 1, after an OS update.  We had been using a 512
>> bit Diffie Helman key.
>> >
>> >
>> >
>> > 2015-09-03T18:01:36.709399+00:00 NOTICE wpa_supplicant[472]: OpenSSL:
>> openssl_handshake - SSL_connect error:14082174:SSL
>> routines:ssl3_check_cert_and_algorithm:dh key too small
>> >
>> > On Sep 11, 2015, at 4:55 PM, Curtis K. Larsen 
>> wrote:
>> >
>> > > Hello,
>> > >
>> > > Are any other FreeRADIUS users planning to upgrade to 2048 bit
>> Diffie-Hellman keys before the iOS9 release?  Just came across these and
>> thinking it's a must do ASAP:
>> > >
>> > > https://support.apple.com/en-us/HT204932
>> > >
>> https://community.jisc.ac.uk/blogs/8021x-clients-and-radius-server-supporting-bigger-diffie-hellman-dh-keys
>> > >
>> > >
>> > > Thanks,
>> > >
>> > > Curtis Larsen
>> > > University IT/CIS
>> > > Sr. Network Engineer
>> > >
>> > >
>> > >
>> > > **
>> > > Participation and subscription information for this EDUCAUSE
>> Constituent Group discussion list can be found at
>> http://www.educause.edu/groups/.
>> >
>> > ---
>> > Bruce Curtis bruce.cur...@ndsu.edu
>> > Certified NetAnalyst II701-231-8527
>> > North Dakota 

Re: [WIRELESS-LAN] Sanity check- spontaneously changing WLC configs- is it just us?

[Matthew Newton]

On Mon, Sep 14, 2015 at 07:24:04PM +, Lee H Badman wrote:
> - APs renaming themselves
> - Clean Air getting wholesale disabled on a controller
> - APs that way back when were config'd with static IP addresses,
>   but that have been using DHCP for years, going back to showing
>   static IPs configs
> - APs taking themselves out of a given AP group to default
...
> Does anyone else experience anything like this?

Haven't seen anything like those over the last 8 or so years.
Mixture of APs from 1131s all the way up to 3702s, and 2504, 5508
and 8510 controllers.

We don't use prime/wcs/ncs/whatever Cisco are promoting these
days, and use an in-house system instead for basic AP management
and monitoring.

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] FreeRADIUS Diffie-Hellman Keys and iOS9

[Walter Reynolds]

Based on the following link, it implies that flag does not do anything.  It
is old, but did the same thing on code I am running (2.2.8)
http://freeradius.1045715.n5.nabble.com/Why-is-the-default-DH-keysize-only-512-bits-td2754757.html





Walter Reynolds
Principal Systems Security Development Engineer
Information and Technology Services
University of Michigan
(734) 615-9438

On Tue, Sep 15, 2015 at 11:04 AM, Bruce Curtis 
wrote:

> When we increased the size of our key Google had found a reference to
> putting this line in EAP.conf.
>
> dh_key_length = 2048
>
> I have not tested without the line but the presence of the line does not
> prevent freeradius from running and the device that was complaining about
> the size of the key now works.
>
> On Sep 15, 2015, at 8:34 AM, Walter Reynolds  wrote:
>
> > On freeradius does it use the size of the key or do you have to specify
> somewhere?
> >
> > When I put in a dh key that is 2048 and run in debug mode I see the
> following
> >
> > Tue Sep 15 09:30:18 2015 : Debug:  Module: Instantiating eap-tls
> > Tue Sep 15 09:30:18 2015 : Debug:tls {
> > Tue Sep 15 09:30:18 2015 : Debug:   rsa_key_exchange = no
> > Tue Sep 15 09:30:18 2015 : Debug:   dh_key_exchange = yes
> > Tue Sep 15 09:30:18 2015 : Debug:   rsa_key_length = 512
> > Tue Sep 15 09:30:18 2015 : Debug:   dh_key_length = 512
> >
> > But I verified the file itself.
> >
> > [root@aaa-maccvm-05 certs]# openssl dhparam -in dh -text -noout
> > PKCS#3 DH Parameters: (2048 bit)
> >
> >
> >
> > 
> > Walter Reynolds
> > Principal Systems Security Development Engineer
> > Information and Technology Services
> > University of Michigan
> > (734) 615-9438
> >
> > On Mon, Sep 14, 2015 at 8:43 AM, Christopher Michael Allison <
> chris.m.alli...@siu.edu> wrote:
> > Actually, We Upgraded to FreeRadius 2.2.8 to solve some issues with
> iOS9. We have been using a 2048 bit Diffie-Hellman.  And it is a must do
> ASAP as when it rolls out official you will have issues with clients
> connecting. Also if you aren't on FreeRadius 2.2.7 or higher you will run
> into the same issues that we did. Radius will answer the iOS9 clients TLS
> v1.2 Hello but can't transmit anything back to it so the client will never
> authenticate.
> >
> > Thanks,
> >
> > CHRISTOPHER ALLISON
> > Network Engineer I
> >
> > Information Technology
> > Mail Code 4622
> > 625 Wham Drive
> > Carbondale, Illinois 62901
> >
> > chris.m.alli...@siu.edu
> > P: 618 / 453 - 8415
> > F: 618 / 453 - 5261
> > INFOTECH.SIU.EDU
> >
> >
> >
> > "Choose a job you love, and you will never have to work a day in your
> life."
> > Confucius
> >
> > 
> > From: The EDUCAUSE Wireless Issues Constituent Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Bruce Curtis <
> bruce.cur...@ndsu.edu>
> > Sent: Sunday, September 13, 2015 6:14 AM
> > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> > Subject: Re: [WIRELESS-LAN] FreeRADIUS Diffie-Hellman Keys and iOS9
> >
> >   We just upgraded to 2048 bit Diffie-Helman won September 3.   We had a
> person come to the help desk with a Chromebook that stopped connecting to
> the wireless on September 1, after an OS update.  We had been using a 512
> bit Diffie Helman key.
> >
> >
> >
> > 2015-09-03T18:01:36.709399+00:00 NOTICE wpa_supplicant[472]: OpenSSL:
> openssl_handshake - SSL_connect error:14082174:SSL
> routines:ssl3_check_cert_and_algorithm:dh key too small
> >
> > On Sep 11, 2015, at 4:55 PM, Curtis K. Larsen 
> wrote:
> >
> > > Hello,
> > >
> > > Are any other FreeRADIUS users planning to upgrade to 2048 bit
> Diffie-Hellman keys before the iOS9 release?  Just came across these and
> thinking it's a must do ASAP:
> > >
> > > https://support.apple.com/en-us/HT204932
> > >
> https://community.jisc.ac.uk/blogs/8021x-clients-and-radius-server-supporting-bigger-diffie-hellman-dh-keys
> > >
> > >
> > > Thanks,
> > >
> > > Curtis Larsen
> > > University IT/CIS
> > > Sr. Network Engineer
> > >
> > >
> > >
> > > **
> > > Participation and subscription information for this EDUCAUSE
> Constituent Group discussion list can be found at
> http://www.educause.edu/groups/.
> >
> > ---
> > Bruce Curtis bruce.cur...@ndsu.edu
> > Certified NetAnalyst II701-231-8527
> > North Dakota State University
> >
> > **
> > Participation and subscription information for this EDUCAUSE Constituent
> Group discussion list can be found at http://www.educause.edu/groups/.
> >
> > **
> > Participation and subscription information for this EDUCAUSE Constituent
> Group discussion list can be found at http://www.educause.edu/groups/.
> >
> > ** Participation and subscription information for this EDUCAUSE
> Constituent Group discussion list can be found at
> http://www.educause.edu/groups/.
> 

RE: Supporting "those other Wi-Fi devices" in the dorms- quick Survey

[Osborne, Bruce W (Network Services)]

The system is also used to track usage by University departments.  I assume 
there is some chargeback system in place there too. 

 
Bruce Osborne
Wireless Engineer
IT Infrastructure & Media Solutions
 
(434) 592-4229
 
LIBERTY UNIVERSITY
Training Champions for Christ since 1971

-Original Message-
From: Jeffrey D. Sessler [mailto:j...@scrippscollege.edu] 
Sent: Monday, September 14, 2015 11:47 AM
Subject: Re: Supporting "those other Wi-Fi devices" in the dorms- quick Survey

I’d curious as to what the break-even is here? The college invests money to 
build and maintain an infrastructure to track users and manage bandwidth, 
charge-back fees, staff time to manage, etc. If instead, those funds were 
invested in just increasing Internet bandwidth, do you come out ahead? What if 
you invest those funds in Internet bandwidth and charge a small technology fee 
to all students?

Jeff



On 9/14/15, 4:18 AM, "The EDUCAUSE Wireless Issues Constituent Group Listserv 
on behalf of Osborne, Bruce W (Network Services)" 
 wrote:

>We map username to password and use bandwidth management to limit the amount 
>used per month. Users have the option of purchasing additional bandwidth. This 
>money helps subsidize our Internet connections.

**
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: Supporting "those other Wi-Fi devices" in the dorms- quick Survey

[Osborne, Bruce W (Network Services)]

We are just throttling and offering purchase of more usage. I believe we are 
targeting the top 2% of users. 

 
Bruce Osborne
Wireless Engineer
IT Infrastructure & Media Solutions
 
(434) 592-4229
 
LIBERTY UNIVERSITY
Training Champions for Christ since 1971

-Original Message-
From: Jeffrey D. Sessler [mailto:j...@scrippscollege.edu] 
Sent: Monday, September 14, 2015 11:36 AM
Subject: Re: Supporting "those other Wi-Fi devices" in the dorms- quick Survey

It doesn’t in fact give you assurance that the actual user is connecting. It 
just tells you what credentials the device happens to have. I’ve run into a 
number of cases where we've contacted a user based on the device’s 
authentication only to find out that it belongs to someone else, but the auth’d 
user helped them set it up. 

Oh, and if you are using bandwidth management, it’s worth talking to legal 
about the implications under the DMCA. It may in fact erase your ISP immunity 
for student data transiting your network. 

Jeff





On 9/14/15, 4:16 AM, "The EDUCAUSE Wireless Issues Constituent Group Listserv 
on behalf of Osborne, Bruce W (Network Services)" 
 wrote:

>In our case, at least, the WPA2-Ent gives us assurance that the actual user is 
>connecting

**
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] FreeRADIUS Diffie-Hellman Keys and iOS9

[Bruce Curtis]

When we increased the size of our key Google had found a reference to putting 
this line in EAP.conf.

dh_key_length = 2048

I have not tested without the line but the presence of the line does not 
prevent freeradius from running and the device that was complaining about the 
size of the key now works.

On Sep 15, 2015, at 8:34 AM, Walter Reynolds  wrote:

> On freeradius does it use the size of the key or do you have to specify 
> somewhere?
> 
> When I put in a dh key that is 2048 and run in debug mode I see the following
> 
> Tue Sep 15 09:30:18 2015 : Debug:  Module: Instantiating eap-tls
> Tue Sep 15 09:30:18 2015 : Debug:tls {
> Tue Sep 15 09:30:18 2015 : Debug:   rsa_key_exchange = no
> Tue Sep 15 09:30:18 2015 : Debug:   dh_key_exchange = yes
> Tue Sep 15 09:30:18 2015 : Debug:   rsa_key_length = 512
> Tue Sep 15 09:30:18 2015 : Debug:   dh_key_length = 512
> 
> But I verified the file itself.
> 
> [root@aaa-maccvm-05 certs]# openssl dhparam -in dh -text -noout
> PKCS#3 DH Parameters: (2048 bit)
> 
> 
> 
> 
> Walter Reynolds
> Principal Systems Security Development Engineer
> Information and Technology Services
> University of Michigan
> (734) 615-9438
> 
> On Mon, Sep 14, 2015 at 8:43 AM, Christopher Michael Allison 
>  wrote:
> Actually, We Upgraded to FreeRadius 2.2.8 to solve some issues with iOS9. We 
> have been using a 2048 bit Diffie-Hellman.  And it is a must do ASAP as when 
> it rolls out official you will have issues with clients connecting. Also if 
> you aren't on FreeRadius 2.2.7 or higher you will run into the same issues 
> that we did. Radius will answer the iOS9 clients TLS v1.2 Hello but can't 
> transmit anything back to it so the client will never authenticate.
> 
> Thanks,
> 
> CHRISTOPHER ALLISON
> Network Engineer I
> 
> Information Technology
> Mail Code 4622
> 625 Wham Drive
> Carbondale, Illinois 62901
> 
> chris.m.alli...@siu.edu
> P: 618 / 453 - 8415
> F: 618 / 453 - 5261
> INFOTECH.SIU.EDU
> 
> 
> 
> "Choose a job you love, and you will never have to work a day in your life."
> Confucius
> 
> 
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
>  on behalf of Bruce Curtis 
> 
> Sent: Sunday, September 13, 2015 6:14 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] FreeRADIUS Diffie-Hellman Keys and iOS9
> 
>   We just upgraded to 2048 bit Diffie-Helman won September 3.   We had a 
> person come to the help desk with a Chromebook that stopped connecting to the 
> wireless on September 1, after an OS update.  We had been using a 512 bit 
> Diffie Helman key.
> 
> 
> 
> 2015-09-03T18:01:36.709399+00:00 NOTICE wpa_supplicant[472]: OpenSSL: 
> openssl_handshake - SSL_connect error:14082174:SSL 
> routines:ssl3_check_cert_and_algorithm:dh key too small
> 
> On Sep 11, 2015, at 4:55 PM, Curtis K. Larsen  
> wrote:
> 
> > Hello,
> >
> > Are any other FreeRADIUS users planning to upgrade to 2048 bit 
> > Diffie-Hellman keys before the iOS9 release?  Just came across these and 
> > thinking it's a must do ASAP:
> >
> > https://support.apple.com/en-us/HT204932
> > https://community.jisc.ac.uk/blogs/8021x-clients-and-radius-server-supporting-bigger-diffie-hellman-dh-keys
> >
> >
> > Thanks,
> >
> > Curtis Larsen
> > University IT/CIS
> > Sr. Network Engineer
> >
> >
> >
> > **
> > Participation and subscription information for this EDUCAUSE Constituent 
> > Group discussion list can be found at http://www.educause.edu/groups/.
> 
> ---
> Bruce Curtis bruce.cur...@ndsu.edu
> Certified NetAnalyst II701-231-8527
> North Dakota State University
> 
> **
> Participation and subscription information for this EDUCAUSE Constituent 
> Group discussion list can be found at http://www.educause.edu/groups/.
> 
> **
> Participation and subscription information for this EDUCAUSE Constituent 
> Group discussion list can be found at http://www.educause.edu/groups/.
> 
> ** Participation and subscription information for this EDUCAUSE 
> Constituent Group discussion list can be found at 
> http://www.educause.edu/groups/.
> 

---
Bruce Curtis bruce.cur...@ndsu.edu
Certified NetAnalyst II701-231-8527
North Dakota State University

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

Re: [WIRELESS-LAN] Smart TVs and other "smart" devices

[Jeremy Gibbs]

We are having the same issue.  So many people with these WiFi direct
devices.  It is causing serious performance problems with our WiFi network,
especially the people who can't connect at 5 Ghz.

On Mon, Sep 14, 2015 at 10:35 AM, Lee H Badman  wrote:

> There is a glaring element of cluelessness here- is amazing.
>
>
>
> *Lee Badman* | Network Architect
>
> Information Technology Services
> 206 Machinery Hall
> 120 Smith Drive
> Syracuse, New York 13244
>
> *t* 315.443.3003  * f* 315.443.4325   *e* lhbad...@syr.edu *w* its.syr.edu
>
> *SYRACUSE UNIVERSITY*
> syr.edu
>
>
>
> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Osborne, Bruce W
> (Network Services)
> *Sent:* Monday, September 14, 2015 7:27 AM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] Smart TVs and other "smart" devices
>
>
>
> And the enterprise Wi-Fi vendors choose to ignore Wi-Fi Direct.
>
>
>
> A while ago when the specification was approved, I asked our vendor how
> they were going to deal with this. They could not see how this home
> technology would impact the enterprise network.
>
> ​
>
>
>
> *Bruce Osborne*
>
> *Wireless Engineer*
>
> *IT Infrastructure & Media Solutions*
>
>
>
> *(434) 592-4229 <%28434%29%20592-4229>*
>
>
>
> *LIBERTY UNIVERSITY*
>
> *Training Champions for Christ since 1971*
>
>
>
> *From:* Thomas Carter [mailto:tcar...@austincollege.edu
> ]
> *Sent:* Monday, September 7, 2015 6:04 PM
> *Subject:* Re: Smart TVs and other "smart" devices
>
>
>
> Yes, wiFi direct is growing in use – Playstation 4s broadcast wifi direct
> to connect to Playstation portables. Some Roku players use wifi direct for
> remote controls. We have a blanket statement disallowing anything that we
> deem interference with the campus wireless.  As a smaller private
> institution, we work with the students to remove the wireless network. It’s
> no different than most HP wireless printers that broadcast a wireless
> network for setup.
>
>
>
> Thomas Carter
>
>
>
> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> ] *On Behalf Of *Jeremy Gibbs
> *Sent:* Monday, September 7, 2015 2:26 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* [WIRELESS-LAN] Smart TVs and other "smart" devices
>
>
>
> I have been seeing more and more students coming to campus with "smart"
> tv's.  We allow them to register the TV on our wireless network.  Recently,
> I have been seeing a lot of "Hidden" networks when doing some WiFi scans.
> Turns out, many of these TVs are broadcasting their own SSID, some hidden
> and some not.  This is obviously causing interference with our production
> wireless network in the dorms.  Also, I have seen xbox one devices
> broadcasting their own SSID, hidden but it is broadcasting.
>
>
>
> On many of these "Smart" TVs and devices, I cannot find a way to turn off
> the broadcast of these networks.
>
>
>
> Anyone have any experience mitigating problems like these?  It just
> appears that every new device these days broadcasts some sort of 2.4 Ghz
> network.
>
>
>
> Thanks
>
>
>
>
>
>
>
> *-- Jeremy L. Gibbs*
>
> Sr. Network Engineer
> Utica College IITS
>
> ** 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/.
>
>


-- 


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

T: (315) 223-2383
F: (315) 792-3814
E: jlgi...@utica.edu
http://www.utica.edu

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

Re: [WIRELESS-LAN] FreeRADIUS Diffie-Hellman Keys and iOS9

[Chuck Anderson]

Does this change cause any other client incompatibilities or require
any changes to existing clients?

On Tue, Sep 15, 2015 at 03:04:36PM +, Bruce Curtis wrote:
> When we increased the size of our key Google had found a reference to putting 
> this line in EAP.conf.
> 
> dh_key_length = 2048
> 
> I have not tested without the line but the presence of the line does not 
> prevent freeradius from running and the device that was complaining about the 
> size of the key now works.
> 
> On Sep 15, 2015, at 8:34 AM, Walter Reynolds  wrote:
> 
> > On freeradius does it use the size of the key or do you have to specify 
> > somewhere?
> > 
> > When I put in a dh key that is 2048 and run in debug mode I see the 
> > following
> > 
> > Tue Sep 15 09:30:18 2015 : Debug:  Module: Instantiating eap-tls
> > Tue Sep 15 09:30:18 2015 : Debug:tls {
> > Tue Sep 15 09:30:18 2015 : Debug:   rsa_key_exchange = no
> > Tue Sep 15 09:30:18 2015 : Debug:   dh_key_exchange = yes
> > Tue Sep 15 09:30:18 2015 : Debug:   rsa_key_length = 512
> > Tue Sep 15 09:30:18 2015 : Debug:   dh_key_length = 512
> > 
> > But I verified the file itself.
> > 
> > [root@aaa-maccvm-05 certs]# openssl dhparam -in dh -text -noout
> > PKCS#3 DH Parameters: (2048 bit)
> > 
> > 
> > 
> > 
> > Walter Reynolds
> > Principal Systems Security Development Engineer
> > Information and Technology Services
> > University of Michigan
> > (734) 615-9438
> > 
> > On Mon, Sep 14, 2015 at 8:43 AM, Christopher Michael Allison 
> >  wrote:
> > Actually, We Upgraded to FreeRadius 2.2.8 to solve some issues with iOS9. 
> > We have been using a 2048 bit Diffie-Hellman.  And it is a must do ASAP as 
> > when it rolls out official you will have issues with clients connecting. 
> > Also if you aren't on FreeRadius 2.2.7 or higher you will run into the same 
> > issues that we did. Radius will answer the iOS9 clients TLS v1.2 Hello but 
> > can't transmit anything back to it so the client will never authenticate.
> > 
> > Thanks,
> > 
> > CHRISTOPHER ALLISON
> > Network Engineer I
> > 
> > Information Technology
> > Mail Code 4622
> > 625 Wham Drive
> > Carbondale, Illinois 62901
> > 
> > chris.m.alli...@siu.edu
> > P: 618 / 453 - 8415
> > F: 618 / 453 - 5261
> > INFOTECH.SIU.EDU
> > 
> > 
> > 
> > "Choose a job you love, and you will never have to work a day in your life."
> > Confucius
> > 
> > 
> > From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> >  on behalf of Bruce Curtis 
> > 
> > Sent: Sunday, September 13, 2015 6:14 AM
> > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> > Subject: Re: [WIRELESS-LAN] FreeRADIUS Diffie-Hellman Keys and iOS9
> > 
> >   We just upgraded to 2048 bit Diffie-Helman won September 3.   We had a 
> > person come to the help desk with a Chromebook that stopped connecting to 
> > the wireless on September 1, after an OS update.  We had been using a 512 
> > bit Diffie Helman key.
> > 
> > 
> > 
> > 2015-09-03T18:01:36.709399+00:00 NOTICE wpa_supplicant[472]: OpenSSL: 
> > openssl_handshake - SSL_connect error:14082174:SSL 
> > routines:ssl3_check_cert_and_algorithm:dh key too small
> > 
> > On Sep 11, 2015, at 4:55 PM, Curtis K. Larsen  
> > wrote:
> > 
> > > Hello,
> > >
> > > Are any other FreeRADIUS users planning to upgrade to 2048 bit 
> > > Diffie-Hellman keys before the iOS9 release?  Just came across these and 
> > > thinking it's a must do ASAP:
> > >
> > > https://support.apple.com/en-us/HT204932
> > > https://community.jisc.ac.uk/blogs/8021x-clients-and-radius-server-supporting-bigger-diffie-hellman-dh-keys

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

RE: [WIRELESS-LAN] Aruba Instant IAP-215 Wireless Access Points

[Eric Rose]

We ran into an LLDP issue with Juniper EX switches and Aruba APs last summer, 
see PR898234. We disabled LLDP  as a work around on the specific ports until we 
could update to the latest TAC approved firmware.

https://prsearch.juniper.net/InfoCenter/index?page=prcontent=PR898234

Hope this helps,

Eric

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Frans Panken
Sent: Tuesday, September 15, 2015 2:50 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Aruba Instant IAP-215 Wireless Access Points

We experienced that LLDP does not work properly in the case of non Cisco the 
switches.
We have 3700 APs and Juniper switches. The APs require PoE+ to function with 
all MIMO capabilities (4 spatial streams). The WLC tells us that there is no 
PoE+. With Cisco switches, the WLC does mention that there is PoE+. Even with a 
PoE+ injector of Cisco, the WLC still mentions PoE.
This was when we used 8.0 MR1. Clients could still use 4 spatial streams. We 
were told this was a Cisco bug and the problem would be solved in MR2 (which we 
are not intending to use).
According to the Juniper swith, the APs use less power than you would
expect:

InterfaceAdmin   OperMaxPriority   Power  Class
 status  status  power consumption
ge-6/0/15Enabled  ON 30.0W  Low4.3W4
ge-6/0/18Enabled  ON 30.0W  Low6.7W4
ge-6/0/19Enabled  ON 30.0W  Low6.1W4
ge-6/0/20Enabled  ON 30.0W  Low6.3W4
ge-6/0/21Enabled  ON 30.0W  Low6.1W4





Jake Snyder schreef op 15/09/15 om 03:20:
> The other thing you might check is to see if you have LLDP running on the 
> switches.  This can help with Poe negotiation.
>
> Thanks
> Jake Snyder
>
>
> Sent from my iPhone
>
>> On Sep 14, 2015, at 6:53 PM, James Michael Keller  
>> wrote:
>>
>>> On 09/14/2015 11:37 AM, Ronald Loneker wrote:
>>> Good Morning -
>>>
>>> (forgive cross-postings - a member of the NETMAN list suggested this 
>>> might be the place to post this question)
>>>
>>> We just had close to 90 new Aruba Instant IAP-215 wireless access 
>>> points installed in our residence halls to upgrade our wireless network.
>>> Another building is soon to be underway, and I'm managing this project.
>>>
>>> Over the last couple of weeks, it seems like random access points 
>>> are shutting down wireless access.  They are not all connected to 
>>> the same Cisco switch (various Cisco POE switches in two residence 
>>> halls).  The access point is not ping-able, the MAC address is not 
>>> found in the virtual controller's table, the switch port is up and 
>>> power is being supplied to the access point.  The only way we seem 
>>> to get an access point back up is to do a shut/no shut on the switch 
>>> port to which it is connected.
>>>
>>> The vendor who configured the access points hasn't been able to 
>>> determine why this is happening and before we initiate an Aruba 
>>> support call, I was wondering if anyone had any similar experiences 
>>> like this and what you determined was the cause of the issue.  We 
>>> are running into walls here.
>>>
>>> Thanks in advance for any thoughts or ideas.
>>>
>>> Ron Loneker, Jr.
>>> Director of Media Services
>>> College of Saint Elizabeth
>>> Mahoney Library
>>> 2 Convent Road
>>> Morristown, NJ  07960
>>>
>>> Phone:  973-290-4229 
>>>
>>> e-mail:  rlone...@cse.edu 
>>>
>>> /**/
>>>
>>>
>>> ** Participation and subscription information for this 
>>> EDUCAUSE Constituent Group discussion list can be found at 
>>> http://www.educause.edu/groups/.
>> I have seen similar with the campus APs when the PoE power is either 
>> dropping below min spec either due to switch power or cable run
>> resistance.   The APs will have enough power to initialize which brings
>> up the link, but they fail to boot into ArubaOS and hang until they 
>> are power cycled.  Typically the ones with cable run issues continue 
>> to fail on the next cycle.  Brown out triggered ones come up fine 
>> usually, and typically we see more then one on the same switch do it 
>> for PoE power issues.
>>
>> --
>>
>> -James
>>
>>
>> **
>> 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 

RE: Supporting "those other Wi-Fi devices" in the dorms- quick Survey

[Osborne, Bruce W (Network Services)]

I will try and get some information, but I believe the system currently has 
issues and is not enforcing.

 
Bruce Osborne
Wireless Engineer
IT Infrastructure & Media Solutions
 
(434) 592-4229
 
LIBERTY UNIVERSITY
Training Champions for Christ since 1971

-Original Message-
From: Dan Brisson [mailto:dbris...@uvm.edu] 
Sent: Monday, September 14, 2015 11:54 AM
Subject: Re: Supporting "those other Wi-Fi devices" in the dorms- quick Survey

Interesting.  Would you be willing to share what your average user consumes per 
month?

Thanks,
-dan


Dan Brisson
Network Engineer
University of Vermont

On 9/14/2015 7:18 AM, Osborne, Bruce W (Network Services) wrote:
> We map username to password and use bandwidth management to limit the amount 
> used per month. Users have the option of purchasing additional bandwidth. 
> This money helps subsidize our Internet connections.
>
>   
> Bruce Osborne
> Wireless Engineer
> IT Infrastructure & Media Solutions
>   
> (434) 592-4229
>   
> LIBERTY UNIVERSITY
> Training Champions for Christ since 1971
>
> -Original Message-
> From: Danny Eaton [mailto:dannyea...@rice.edu]
> Sent: Friday, September 4, 2015 3:04 PM
> Subject: Re: Supporting "those other Wi-Fi devices" in the dorms- 
> quick Survey
>
> Just to turn this on it’s ear a bit...
>
> Why not go back to an open network for student devices, with the same EULA as 
> they’d get be it at a Starbucks, McDonalds, hotel, or convention center? Why 
> are we (my self included) so hell bent on student devices connecting via 
> WPA-Ent and all the challenges associated with accommodating devices that 
> can’t?
>
>   Here at Rice, we have just that - 1 network (eduroam), 2 network (Rice 
> Owls, 802.1X authenticated), and 3 network (Rice Visitor, open, unencrypted, 
> with a pop-up welcome page to accept our use policy).  We are not necessarily 
> hell-bent on getting a PSK/MAC authenticated network built, but our students 
> are.  They want to put their Wii-U, Xbox, AppleTV, Roku, Google Chromecast, 
> etc. on the wireless network just like they would at home, their apartment, 
> etc.  Obviously, they wouldn't do that at Starbucks, a hotel, or the like.  
> They live on campus, so it's their home.
>
> Does data exist that shows all of this overhead we’ve created has had any 
> measurable benefit (for the cost), especially when the same users aren’t 
> concerned about over-the-air security when at the above mentioned places?
>
> Why do we care so much? Is there some middle-ground that is “good enough” but 
> provides almost the same experience as at home?
>
> Would our efforts be better spent implementing other beneficial technologies 
> such location-aware WiFi, where after the student connects all their AppleTV, 
> TimeMachine, and Chromecast devices, the network is smart enough to provide 
> them visibility of only those devices when in/near the same location e.g. 
> Location-aware bonjour?
>
>
>
> Jeff
>
>
> On 9/4/15, 7:51 AM, "The EDUCAUSE Wireless Issues Constituent Group Listserv 
> on behalf of Lee H Badman"  lhbad...@syr.edu> wrote:
>
>> Where it gets interesting- broadcast and single class C required. But- this 
>> is a great summary of requirements.
>>
>> Lee Badman | Network Architect
>> Information Technology Services
>> 206 Machinery Hall
>> 120 Smith Drive
>> Syracuse, New York 13244
>> t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu w its.syr.edu
>> SYRACUSE UNIVERSITY
>> syr.edu
>>
>> -Original Message-
>> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
>> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Johnson, 
>> Neil M
>> Sent: Friday, September 04, 2015 10:46 AM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> Subject: Re: [WIRELESS-LAN] Supporting "those other Wi-Fi devices" in 
>> the dorms- quick Survey
>>
>> Here is my first pass at requirements:
>>
>> 1. The service must prevent or discourage devices that ARE capable of 
>> using 802.1x authentication from using the service.
>>
>> 2. The service should provide some sort of traceability of devices back 
>> to their owners.
>>
>> 3. The service must provide some method to deny access to an individual 
>> device.
>>
>> 4. The service must be easy enough to use that the average student can 
>> connect a device to the network in 10-15 minutes without requiring 
>> assistance from ITS.
>>
>> 5. The service must restrict access to only authorized University 
>> customers.
>>
>> 6. In the residence Halls, the service must support most the most common 
>> consumer devices that students might bring to campus
>>
>>
>> We are also looking at a “Device Net” for campus for other devices that may 
>> not do 802.1X (freezer monitors, digital signage, instrumentation, etc.).
>>
>> For the residence hall device net we are thinking about blocking all access 
>> to campus resources and just allowing internet access.
>>
>> For the campus device 

Re: [WIRELESS-LAN] FreeRADIUS Diffie-Hellman Keys and iOS9

[Walter Reynolds]

On freeradius does it use the size of the key or do you have to specify
somewhere?

When I put in a dh key that is 2048 and run in debug mode I see the
following

Tue Sep 15 09:30:18 2015 : Debug:  Module: Instantiating eap-tls
Tue Sep 15 09:30:18 2015 : Debug:tls {
Tue Sep 15 09:30:18 2015 : Debug:   rsa_key_exchange = no
Tue Sep 15 09:30:18 2015 : Debug:   dh_key_exchange = yes
Tue Sep 15 09:30:18 2015 : Debug:   rsa_key_length = 512
Tue Sep 15 09:30:18 2015 : Debug:   dh_key_length = 512


But I verified the file itself.

[root@aaa-maccvm-05 certs]# openssl dhparam -in dh -text -noout
PKCS#3 DH Parameters: (2048 bit)




Walter Reynolds
Principal Systems Security Development Engineer
Information and Technology Services
University of Michigan
(734) 615-9438

On Mon, Sep 14, 2015 at 8:43 AM, Christopher Michael Allison <
chris.m.alli...@siu.edu> wrote:

> Actually, We Upgraded to FreeRadius 2.2.8 to solve some issues with iOS9.
> We have been using a 2048 bit Diffie-Hellman.  And it is a must do ASAP as
> when it rolls out official you will have issues with clients connecting.
> Also if you aren't on FreeRadius 2.2.7 or higher you will run into the same
> issues that we did. Radius will answer the iOS9 clients TLS v1.2 Hello but
> can't transmit anything back to it so the client will never authenticate.
>
> Thanks,
>
> CHRISTOPHER ALLISON
> Network Engineer I
>
> Information Technology
> Mail Code 4622
> 625 Wham Drive
> Carbondale, Illinois 62901
>
> chris.m.alli...@siu.edu
> P: 618 / 453 - 8415
> F: 618 / 453 - 5261
> INFOTECH.SIU.EDU
>
>
>
> "Choose a job you love, and you will never have to work a day in your
> life."
> Confucius
>
> 
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Bruce Curtis <
> bruce.cur...@ndsu.edu>
> Sent: Sunday, September 13, 2015 6:14 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] FreeRADIUS Diffie-Hellman Keys and iOS9
>
>   We just upgraded to 2048 bit Diffie-Helman won September 3.   We had a
> person come to the help desk with a Chromebook that stopped connecting to
> the wireless on September 1, after an OS update.  We had been using a 512
> bit Diffie Helman key.
>
>
>
> 2015-09-03T18:01:36.709399+00:00 NOTICE wpa_supplicant[472]: OpenSSL:
> openssl_handshake - SSL_connect error:14082174:SSL
> routines:ssl3_check_cert_and_algorithm:dh key too small
>
> On Sep 11, 2015, at 4:55 PM, Curtis K. Larsen 
> wrote:
>
> > Hello,
> >
> > Are any other FreeRADIUS users planning to upgrade to 2048 bit
> Diffie-Hellman keys before the iOS9 release?  Just came across these and
> thinking it's a must do ASAP:
> >
> > https://support.apple.com/en-us/HT204932
> >
> https://community.jisc.ac.uk/blogs/8021x-clients-and-radius-server-supporting-bigger-diffie-hellman-dh-keys
> >
> >
> > Thanks,
> >
> > Curtis Larsen
> > University IT/CIS
> > Sr. Network Engineer
> >
> >
> >
> > **
> > Participation and subscription information for this EDUCAUSE Constituent
> Group discussion list can be found at http://www.educause.edu/groups/.
>
> ---
> Bruce Curtis bruce.cur...@ndsu.edu
> Certified NetAnalyst II701-231-8527
> North Dakota State University
>
> **
> Participation and subscription information for this EDUCAUSE Constituent
> Group discussion list can be found at http://www.educause.edu/groups/.
>
> **
> Participation and subscription information for this EDUCAUSE Constituent
> Group discussion list can be found at http://www.educause.edu/groups/.
>

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

RE: [WIRELESS-LAN] Cisco AP Horizontal Mounting Bracket

[Mattson III, Ken V.]

We usually use the Oberon bracket, but we have used these in less/non visible 
places.
http://www.homedepot.com/p/Unbranded-7-25-in-x-7-25-in-White-Over-Under-Shelf-Bracket-EB-0051-8WT/204657444

After seeing them installed we have thought about using them in some more 
visible places.  If you need a place to hide the cable, it is fairly easy to 
clamshell two of them together to make a cable path between them.


Kenneth V. Mattson III
Director - Network and Data
DoIT
Creighton University
402-280-2743
402-981-1140
 
A password is like a toothbrush:
Choose a good one, change it regularly and don't share it.

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeffrey D. Sessler
Sent: Monday, September 14, 2015 10:28 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Cisco AP Horizontal Mounting Bracket

And if someone were to calculate the labor cost to piece that solution 
together, the $50 Oberon likely comes out ahead. :(

Jeff



On 9/14/15, 5:33 AM, "The EDUCAUSE Wireless Issues Constituent Group Listserv 
on behalf of Jon Scot Prunckle"  wrote:

>I tired to get our Services department to buy-in to the Oberon unit for 
>several of our more architecturally unique buildings, but there was no 
>interest due to the cost.  I think the Oberon Units are quite nice.  
>
>Currently we have contracted out the cabling portion of our Wi-Fi expansion.  
>The contractor happens to be a licensed electrical contractor (by state law, 
>our Network Services department is allowed to pull cable, but is not allowed 
>to install conduit other than wiremold or a fire-stopping penetration; conduit 
>must be installed by a licensed, state approved contractor).  The electrical 
>contractor has devised a mount using:
>- a wiremold 4 1/2" square by 3 1/2" deep surface mount electrical box 
>- covered with a 4" square blank plate w/ a 1/2 knock out (with a plastic KO 
>bushing) and a 
>- 1/4" mud ring screwed into 
>- two small angle brackets mounted to the 4" blank plate, and
>- mounted to the 1/4" mud ring is a Juniper WLA-BRKT-WALL to which we mount our
>- Juniper WLA532-US APs.
>
>It's convoluted and may not present an ideal solution for many environments.
>
>Sincerely,
>
>
>J. Scot Prunckle
>Network Engineer
>UITS Network and Operations Services
>University of Wisconsin-Milwaukee
>Office Mobile: (414) 416-9709
>E-mail: prunc...@uwm.edu
>
>
>From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> on behalf of Jeffrey D. Sessler 
>
>Sent: Friday, September 11, 2015 5:48 PM
>To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>Subject: Re: [WIRELESS-LAN] Cisco AP Horizontal Mounting Bracket
>
>WE using the Oberon unit. Without the key lock they are very inexpensive and 
>it’s built such that it’s nearly impossible to use it as a place to hang 
>cloths (if installed in a room).
>
>Jeff
>
>
>
>
>On 9/11/15, 12:03 PM, "The EDUCAUSE Wireless Issues Constituent Group Listserv 
>on behalf of Dan Brisson" dbris...@uvm.edu> wrote:
>
>>Oberon
>
>**
>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/.