Re: [WIRELESS-LAN] Certificate for 802.1x

[Travis Schick]

Hmm tempted to create my own signing authority cert and create one with
expiration way into the future  though I just know if I do that - next
week we'll find out that we can't use SHA-2 anymore - or any keys less than
8192 bits are too small

So until that quantum cryptography stuph gets sorted out to stop all chance
of man in the middle  I think the best option is :

use one cert for all radius servers - use a server name that is simple -
have scheduled and well announced cert updates when needed.


So far we have gone through a few cert changes - and its pain - but
scheduling them after our spring session ends and before summer sessions
helps.   So outgoing students don't necessarily need to care early into
the summer for any prospective students to get proper certs via eduroam CAT
tool.   Also having the date set ahead of time - gets support staff ready
and allows for communication to go out...  so hopefully when prompted a
student knows why - what to look for and life with wifi continues
 (possibly a few weeks with increased captive portal ssid usage)

Ultimately it comes to education - as much as we want devices to just
auto-magically connect securely without prompting the user - even with
provisioning tools the user gets prompted to trust something - just not
enough data to auto-trust.  So they need to know what to trust.

Also keep the setup as simple as possible.   We use a single cert on all
our radius servers  with a simple name to look for eap. - publish
the digest and the cert so security minded folks can verify - or download
and install via other means.

Our university is under InCommon - so cost of public CA signed certs is not
an issue for me.  I like to see that I'm getting prompted to trust a valid
cert - even if the OS won't be able to verify it  - yes I still have to
answer questions - why it prompts -"you guys should order certs via godaddy
- my web server never asks me..."
*sigh*



-Travis

On Tue, Mar 14, 2017 at 6:40 AM Jethro R Binks 
wrote:

> On Mon, 13 Mar 2017, Oakes, Carl W wrote:
>
> > This one hits home for me, going through this now on a certificate
> > expiring and battling on what to do next.
> >
> > Most clients don't trust any certificate, even if the device is set to
> > trust them OS wide (web browser, etc).  The wireless / supplicant
> > configuration needs to be setup to trust specific certs or CA's.
> >
> > Onboarding tools can be used like SecureW2, Aruba , Cloudpath,
> > eduroam CAT to load and enable the RADIUS cert and set it
> > active/trusted.
> >
> > If clients onboard themselves, just by manually attaching to the
> > network, they trust the immediate certificate, and I think in some
> > cases, just the digest of the cert, making future cert updates
> > "eventful".
> >
> > Clients when authenticating can't check the CRL or OCSP for certificate
> > revocation, since they aren't on the network yet while trying to
> > authenticate.
> >
> > So, with all that, I really don't want to get another 3 or 4 year cert
> > and deal with the expiring cert again.  Not a pretty scenario. Last time
> > this happened, it hit us by surprise since we couldn't get a new cert
> > based on the previously trusted CA.  E
> >
> > I'm tempted to create a self-signed local CA just for the RADIUS server
> > validation, and a then generate a single cert off that CA.  Then have
> > SecureW2 (what we have) provide that CA and mark it as trusted. Since
> > it's our own CA, was going to make it good for 20 years (just shy of the
> > 2038 unix time clock issue).  Avoids the problem until after I retire.
> > :)
> >
> > In testing, so far this seems to work great.  But test is very different
> > than thousands of random student devices.
> >
> > In theory it could be just a single self-signed cert, but I liked have
> > the added bonus / flexibility / futures of the self-signed CA just in
> > case.
> >
> > Either way, if the private key of the RAIDUS cert gets compromised
> > (commercial or self-signed), it's a world of hurt to get folks moved
> > over in a secure way.
> >
> > Has anyone done this?  Good or bad? Am I missing anything key?
> >
> > Next up will be client based certs, but that doesn't fix/resolve the
> > above issue.
>
> (Not at all a cert expert, but this is a dump of my experience from a
> while back).
>
> This is what we did, in advance of our commercial cert expiry about 18
> months ago.
>
> Create local root cert with a looong life.  Allow it to issues certs.
>
> Create cert in the name of the radius server.  Doesn't have to relate to
> the DNS name of the server or anything else, just as long as the server
> presents it, and the client is configured to trust the name in it.
>
> You can share the single cert amongst the radius servers.
>
> Use eduroam CAT onboarding to install root cert (and intermediates if you
> have them).
>
> So then, as long as the client knows the (long lived) root, and is
> configured to trust the 

RE: [WIRELESS-LAN] Android 7.1.1 and DHCP issues?

[Danny Eaton]

Oddly enough, the student was out of town for the past weekend, came back 
today, and it’s working just fine.  

 

By “OK”, that is what the freeradius logs were showing; for our two 802.1X 
SSID’s, our freeradius server checks our AD for username/password, and then 
returns to the WiSM-2 clusters “staff”, “student” or “visitor”.  It was 
authenticating and authorizing the student previously, but I never saw a 
DHCPDISCOVER for his phone’s MAC address.  Today, I am.  No changes were made 
on my WiSM-2’s, SSID’s, radius servers, or DHCP servers.  And, like I said, it 
wasn’t even doing DHCP on the OPEN (captive portal) SSID.  Very strange.  

 

 

 

From: Jeremy Mooney [mailto:j-moo...@bethel.edu] 
Sent: Tuesday, March 14, 2017 1:00 PM
To: dannyea...@rice.edu
Cc: The EDUCAUSE Wireless Issues Constituent Group Listserv 

Subject: Re: [WIRELESS-LAN] Android 7.1.1 and DHCP issues?

 

By OK do you mean a Radius access-accept? That is an authorization, but doesn't 
necessarily imply any additional access parameters are appropriately set (or 
not sent). We've seen this cause issues with eduroam roaming before, but this 
can happen both on 802.1x and open (captive portal is often implemented with 
AAA via MAC). Are you able have the dump what the wireless controller sees for 
parameters and compare with a successful authentication? Or test on a wireless 
lan without AAA overrides?

 

FWIW, I'm running a Nexus 6P on 7.1.1 and no issues on our 802.1x (eduroam) or 
open captive portal SSIDs. We have Cisco WLCs against ISE.

 

 

 

 

 

On Mon, Mar 13, 2017 at 2:30 PM, Danny Eaton  > wrote:

I’m looking at the DHCP server for the DHCPDISCOVER conversation, and never see 
his MAC address show up.

 

I do see the “Login OK” appear in our freeradius logs, and his credentials work 
on his laptop, and the laptop gets an IP address without any issues.  The phone 
doesn’t work on our Open (captive portal) either, and I’ve checked both sets of 
WiSM-2 HA Clusters, his MAC address is not quarantined (if it was, it wouldn’t 
ever appear in the radius logs as “Login OK”).  

 

From: Jeremy Mooney [mailto:  j-moo...@bethel.edu] 
Sent: Monday, March 13, 2017 2:13 PM
To:   dannyea...@rice.edu
Cc: The EDUCAUSE Wireless Issues Constituent Group Listserv < 
 WIRELESS-LAN@listserv.educause.edu>
Subject: Re: [WIRELESS-LAN] Android 7.1.1 and DHCP issues?

 

Ar e you only looking on the DHCP server for the discover? Could a radius 
server be returning an option setting an incorrect VLAN or specific ACL for the 
client causing it to be dropped at the AP/WLC level? If it's happening on an 
open network it'd probably have to be hitting a MAC-based rather than 
user-based access rule (or possibly profiled and put in a blocked group).

 

On Mon, Mar 13, 2017 at 12:40 PM, Danny Eaton  > wrote:

It’s set to not validate the radius-server certificate; and like I said, it’s 
authenticating, just not doing the DHCPDISCOVER; I never see it in the DHCP 
server logs.

 

 

 

From: Shayne Ghere [mailto:sgh...@fsmail.bradley.edu 
 ] 
Sent: Monday, March 13, 2017 12:36 PM
To: dannyea...@rice.edu  ; 
WIRELESS-LAN@listserv.educause.edu  
Subject: RE: [WIRELESS-LAN] Android 7.1.1 and DHCP issues?

 

If you’re using certs, there’s a setting under CA Certificate that you have to 
set as “Do not validate” and it will then DHCP.

 

I have a Pixel XL and that’s the only way I can get 802.1x working on my phone. 
  

 

Shayne

 

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
 ] On Behalf Of Danny Eaton
Sent: Monday, March 13, 2017 12:20 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Android 7.1.1 and DHCP issues?

 

 

So, I’ve got one client (1!) who is running Android 7.1.1 and no matter which 
network (our 802.1X, eduroam, or even the “open” captive portal SSID) the user 
tries to connect into, he gets authenticated (on eduroam and our 802.1X SSID), 
but we never see a DHCPDISCOVER from his phone; it passes the AAA (802.1X), but 
will just not get an IP.  Thoughts?  (other devices work just fine).  

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

wbr >58c6d86b151612066850947! 

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





 

-- 

Jeremy Mooney

ITS - Bethel University

wbr>58c6ef36151611738848632! 





 

-- 

Jeremy Mooney

Re: [WIRELESS-LAN] Cisco WLC code recommendations

[Ian Lyons]

Yes it is, with a few extras, that will be part of MR6.  It's good.

Our engineering version is solid. MR6 should be even better.

Ian Lyons
Rollins College

Get Outlook for Android


From: Entwistle, Bruce
Sent: Tuesday, March 14, 13:51
Subject: Re: [WIRELESS-LAN] Cisco WLC code recommendations
To: The EDUCAUSE Wireless Issues Constituent Group Listserv

Is the engineering code you are running, the same MR5 code that is due to be 
released soon?



Bruce Entwistle

Network Manager

University of Redlands





From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Ian Lyons
Sent: Tuesday, March 14, 2017 8:03 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Cisco WLC code recommendations



Ken



Short answer is it is a bug.  A “Kernel Panic”.  AP loses its mind.Very 
prevalent on the new stuff, to a much lesser degree affects “older” stuff.



Sometimes the reset fixes it.  Sometimes not.  We doubled down on 1810’s and 
2802’s.  Bugs galore.  Which are actively being fixed-to be fair.



We are running on engineering code and HUGE improvements have been made. Soon, 
I think/hope, it will be rock solid.



Ian Lyons

Network Engineer

Rollins College









From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Ken LeCompte
Sent: Monday, March 13, 2017 3:36 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Cisco WLC code recommendations



We are currently running a handful of 5508s with 8.0.133.0 and have been stable 
for some time with around 400 APs and upwards of 1.5k clients. We also run a 
half dozen 5520s with 8.2.141.0 and they have been running solid with around 1k 
APs each and upwards of 10k clients. We do not however run anything but 2600, 
3600, 2700 and 3700 APs.



The only issue I have seen that I don’t understand well yet is related to some 
APs losing the minds during network interruptions. The APs will appear up from 
CDP neighbor information, but will have lost their name and will not connect to 
their configured primary or secondary controllers. A power cycle will often 
recover the AP, but not always. I believe that issue started with 8.2.



Thank you.



Ken



--
Ken LeCompte - Consulting Telecommunications Analyst
Telecommunications Division

Office of Information Technology
Rutgers, The State University of New Jersey
Office ~ (848) 445-4823



On Mar 10, 2017, at 1:52 PM, Entwistle, Bruce 
> wrote:



We are currently running version 8.0.133.0 on our Cisco 5508 controllers, as 
our current access points are primarily 3500s and 3600s. However we have 
recently purchased a batch of 2802i access points whose minimum supported 
version is 8.2.110.0.  I was looking to the group for their recommendations on 
a stable version of code which will support our new 2802i access points.



Thank you

Bruce Entwistle

Network Manager

University of Redlands



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



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

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

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


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

Re: [WIRELESS-LAN] Android 7.1.1 and DHCP issues?

[Jeremy Mooney]

By OK do you mean a Radius access-accept? That is an authorization, but
doesn't necessarily imply any additional access parameters are
appropriately set (or not sent). We've seen this cause issues with eduroam
roaming before, but this can happen both on 802.1x and open (captive portal
is often implemented with AAA via MAC). Are you able have the dump what the
wireless controller sees for parameters and compare with a successful
authentication? Or test on a wireless lan without AAA overrides?

FWIW, I'm running a Nexus 6P on 7.1.1 and no issues on our 802.1x (eduroam)
or open captive portal SSIDs. We have Cisco WLCs against ISE.





On Mon, Mar 13, 2017 at 2:30 PM, Danny Eaton  wrote:

> I’m looking at the DHCP server for the DHCPDISCOVER conversation, and
> never see his MAC address show up.
>
>
>
> I do see the “Login OK” appear in our freeradius logs, and his credentials
> work on his laptop, and the laptop gets an IP address without any issues.
> The phone doesn’t work on our Open (captive portal) either, and I’ve
> checked both sets of WiSM-2 HA Clusters, his MAC address is not quarantined
> (if it was, it wouldn’t ever appear in the radius logs as “Login OK”).
>
>
>
> *From:* Jeremy Mooney [mailto:j-moo...@bethel.edu]
> *Sent:* Monday, March 13, 2017 2:13 PM
> *To:* dannyea...@rice.edu
> *Cc:* The EDUCAUSE Wireless Issues Constituent Group Listserv <
> WIRELESS-LAN@listserv.educause.edu>
> *Subject:* Re: [WIRELESS-LAN] Android 7.1.1 and DHCP issues?
>
>
>
> Are you only looking on the DHCP server for the discover? Could a radius
> server be returning an option setting an incorrect VLAN or specific ACL for
> the client causing it to be dropped at the AP/WLC level? If it's happening
> on an open network it'd probably have to be hitting a MAC-based rather than
> user-based access rule (or possibly profiled and put in a blocked group).
>
>
>
> On Mon, Mar 13, 2017 at 12:40 PM, Danny Eaton  wrote:
>
> It’s set to not validate the radius-server certificate; and like I said,
> it’s authenticating, just not doing the DHCPDISCOVER; I never see it in the
> DHCP server logs.
>
>
>
>
>
>
>
> *From:* Shayne Ghere [mailto:sgh...@fsmail.bradley.edu]
> *Sent:* Monday, March 13, 2017 12:36 PM
> *To:* dannyea...@rice.edu; WIRELESS-LAN@listserv.educause.edu
> *Subject:* RE: [WIRELESS-LAN] Android 7.1.1 and DHCP issues?
>
>
>
> If you’re using certs, there’s a setting under CA Certificate that you
> have to set as “Do not validate” and it will then DHCP.
>
>
>
> I have a Pixel XL and that’s the only way I can get 802.1x working on my
> phone.
>
>
>
> Shayne
>
>
>
> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Danny Eaton
> *Sent:* Monday, March 13, 2017 12:20 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* [WIRELESS-LAN] Android 7.1.1 and DHCP issues?
>
>
>
>
>
> So, I’ve got one client (1!) who is running Android 7.1.1 and no matter
> which network (our 802.1X, eduroam, or even the “open” captive portal SSID)
> the user tries to connect into, he gets authenticated (on eduroam and our
> 802.1X SSID), but we never see a DHCPDISCOVER from his phone; it passes the
> AAA (802.1X), but will just not get an IP.  Thoughts?  (other devices work
> just fine).
>
> ** Participation and subscription information for this EDUCAUSE
> Constituent Group discussion list can be found at http://www.educ
> ause.edu/discuss .
>
> wbr>58c6d86b151612066850947!
>
> ** Participation and subscription information for this EDUCAUSE
> Constituent Group discussion list can be found at http://www.educause.edu/
> discuss.
>
>
>
>
>
> --
>
> Jeremy Mooney
>
> ITS - Bethel University
>
> !DSPAM:109,58c6ef36151611738848632!
>



-- 
Jeremy Mooney
ITS - Bethel University

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

RE: [WIRELESS-LAN] Cisco WLC code recommendations

[Entwistle, Bruce]

Is the engineering code you are running, the same MR5 code that is due to be 
released soon?

Bruce Entwistle
Network Manager
University of Redlands


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Ian Lyons
Sent: Tuesday, March 14, 2017 8:03 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Cisco WLC code recommendations

Ken

Short answer is it is a bug.  A "Kernel Panic".  AP loses its mind.Very 
prevalent on the new stuff, to a much lesser degree affects "older" stuff.

Sometimes the reset fixes it.  Sometimes not.  We doubled down on 1810's and 
2802's.  Bugs galore.  Which are actively being fixed-to be fair.

We are running on engineering code and HUGE improvements have been made. Soon, 
I think/hope, it will be rock solid.

Ian Lyons
Network Engineer
Rollins College




From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Ken LeCompte
Sent: Monday, March 13, 2017 3:36 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Cisco WLC code recommendations

We are currently running a handful of 5508s with 8.0.133.0 and have been stable 
for some time with around 400 APs and upwards of 1.5k clients. We also run a 
half dozen 5520s with 8.2.141.0 and they have been running solid with around 1k 
APs each and upwards of 10k clients. We do not however run anything but 2600, 
3600, 2700 and 3700 APs.

The only issue I have seen that I don't understand well yet is related to some 
APs losing the minds during network interruptions. The APs will appear up from 
CDP neighbor information, but will have lost their name and will not connect to 
their configured primary or secondary controllers. A power cycle will often 
recover the AP, but not always. I believe that issue started with 8.2.

Thank you.

Ken

--
Ken LeCompte - Consulting Telecommunications Analyst
Telecommunications Division
Office of Information Technology
Rutgers, The State University of New Jersey
Office ~ (848) 445-4823

On Mar 10, 2017, at 1:52 PM, Entwistle, Bruce 
> wrote:

We are currently running version 8.0.133.0 on our Cisco 5508 controllers, as 
our current access points are primarily 3500s and 3600s. However we have 
recently purchased a batch of 2802i access points whose minimum supported 
version is 8.2.110.0.  I was looking to the group for their recommendations on 
a stable version of code which will support our new 2802i access points.

Thank you
Bruce Entwistle
Network Manager
University of Redlands

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

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

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

RE: [WIRELESS-LAN] Wireless Door lock systems

[Victoria Poncini]

Hi Thomas,
I'm interested to understand how you reduced the interference issues in 2.4GHz 
between the Stanley 802.15.4 and 802.11 systems? 

Victoria Poncini
UW-IT/ MOB
4545 15th Ave NE
Seattle, WA 98105
vponc...@uw.edu
Wk Phone: 206 685-8456


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Thomas Carter
Sent: Monday, March 13, 2017 6:46 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Wireless Door lock systems

We have a small deployment of Stanley locks for special needs students; they 
aren't 802.11 wireless, but are 802.15.4 (on 2.4GHz) wireless. I only bring 
this up as it uses dedicated Stanly gateways, and we had to work to minimize 
the cross-interference between the two systems.

Thomas Carter
Network & Operations Manager / IT
Austin College
900 North Grand Avenue 
Sherman, TX 75090
Phone: 903-813-2564
www.austincollege.edu



-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brian David
Sent: Saturday, March 11, 2017 5:59 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Wireless Door lock systems

All,

I was wondering what other Universities experience with wireless door locks?

How have the door locks been working? Is there a lot of maintenance with your 
systems?

For example battery life, wifi connection problems, broken locks.


Brian

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

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


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

RE: [WIRELESS-LAN] Android 7.1.1 and DHCP issues?

[Danny Eaton]

We have 2 DHCP servers that load-balance.  They are ISC (currently, we're
going to move to Infoblox, hopefully over the summer).

 

The phone (per the user): It is a Google Nexus 6P.

 

 

 

From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Kanan E Simpson
Sent: Monday, March 13, 2017 9:00 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Android 7.1.1 and DHCP issues?

 

How many dhcp servers do you have and do you have multiple routes? Let us
know what you find.

Thanks,

Kanan

  _  

From: The EDUCAUSE Wireless Issues Constituent Group Listserv
 > on behalf of Danny Eaton
 >
Sent: Monday, March 13, 2017 4:45:14 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
 
Subject: Re: [WIRELESS-LAN] Android 7.1.1 and DHCP issues? 

 

Yup; that's my next plan.  Was just hoping someone else had seen something.
The phone works on a personal wireless (hot spot), but just doesn't seem to
want to do DHCP here on campus.  

 

From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Kanan E Simpson
Sent: Monday, March 13, 2017 2:59 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
 
Subject: Re: [WIRELESS-LAN] Android 7.1.1 and DHCP issues?

 

Are you sure the phone is sending DHCP Discover packets? You mentioned it's
not working on the open SSID, you may want to try connecting the phone to
the open SSID and capture OTA packets to see what it's doing and start from
there and move towards the DHCP server. 

 

-Kanan

 

From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of McClintic, Thomas
Sent: Monday, March 13, 2017 3:31 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
 
Subject: Re: [WIRELESS-LAN] Android 7.1.1 and DHCP issues?

 

Danny,

 

Try adding the domain in the profile for which the cert was issued

 

From: The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Danny Eaton
Sent: Monday, March 13, 2017 12:20 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
 
Subject: [WIRELESS-LAN] Android 7.1.1 and DHCP issues?

 

 

So, I've got one client (1!) who is running Android 7.1.1 and no matter
which network (our 802.1X, eduroam, or even the "open" captive portal SSID)
the user tries to connect into, he gets authenticated (on eduroam and our
802.1X SSID), but we never see a DHCPDISCOVER from his phone; it passes the
AAA (802.1X), but will just not get an IP.  Thoughts?  (other devices work
just fine).  

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

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

 

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

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

!DSPAM:109,58c74efa151611249487339! 

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


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

RE: [WIRELESS-LAN] Cisco WLC code recommendations

[Ian Lyons]

Ken

Short answer is it is a bug.  A "Kernel Panic".  AP loses its mind.Very 
prevalent on the new stuff, to a much lesser degree affects "older" stuff.

Sometimes the reset fixes it.  Sometimes not.  We doubled down on 1810's and 
2802's.  Bugs galore.  Which are actively being fixed-to be fair.

We are running on engineering code and HUGE improvements have been made. Soon, 
I think/hope, it will be rock solid.

Ian Lyons
Network Engineer
Rollins College




From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Ken LeCompte
Sent: Monday, March 13, 2017 3:36 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Cisco WLC code recommendations

We are currently running a handful of 5508s with 8.0.133.0 and have been stable 
for some time with around 400 APs and upwards of 1.5k clients. We also run a 
half dozen 5520s with 8.2.141.0 and they have been running solid with around 1k 
APs each and upwards of 10k clients. We do not however run anything but 2600, 
3600, 2700 and 3700 APs.

The only issue I have seen that I don't understand well yet is related to some 
APs losing the minds during network interruptions. The APs will appear up from 
CDP neighbor information, but will have lost their name and will not connect to 
their configured primary or secondary controllers. A power cycle will often 
recover the AP, but not always. I believe that issue started with 8.2.

Thank you.

Ken

--
Ken LeCompte - Consulting Telecommunications Analyst
Telecommunications Division
Office of Information Technology
Rutgers, The State University of New Jersey
Office ~ (848) 445-4823

On Mar 10, 2017, at 1:52 PM, Entwistle, Bruce 
> wrote:


We are currently running version 8.0.133.0 on our Cisco 5508 controllers, as 
our current access points are primarily 3500s and 3600s. However we have 
recently purchased a batch of 2802i access points whose minimum supported 
version is 8.2.110.0.  I was looking to the group for their recommendations on 
a stable version of code which will support our new 2802i access points.

Thank you
Bruce Entwistle
Network Manager
University of Redlands

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

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

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

Re: [WIRELESS-LAN] Wireless Door lock systems

[Robert Ellison]

We have Stanley wireless locks in two dorms (802.15.4 not 802.11) .  One
dorm things worked very well in and the other was a bit of a nightmare. We
had issues with interference especially from student wireless devices
especially Zigbee devices.  The locks dropped offline and batteries died
frequently.  Due to the limited bandwidth in this spectrum if too many
locks are communicating with a gateway at a time, downloads would be
aborted and the lock would have to try again.  Unfortunately these locks
purge their database before downloading.  So when a download is aborted,
the locks lose all credentials and students lose access to their rooms
until the lock is able to complete a successful download.  Poor design in
my opinion.

We found that turning the beacon time up so that the locks communicated
less frequently resolved most of these issues, but at the cost of
individual locks taking longer to receive new badges unless a download was
forced.  Since making this change we have not had the issue of students
being locked out of their rooms and have gone from changing batteries once
a month on some locks to lasting the entire year.  Beacon times were
originally configured at 60 seconds by Stanley and we increased the beacon
to one hour.



*Robert J. Ellison*

*Systems Architect – Computing, Telecommunications, and Media Services
Adjunct Professor – Computer Information Systems & Technology*
*University of Pittsburgh at Bradford & Titusville Campuses*
office +1 814-362-7666 fax +1
814-362-5279



On Mon, Mar 13, 2017 at 9:23 AM Brian J David  wrote:

> Thanks for the information Bruce. We have the same locks. about 1800 of
> them. Some of the batteries are dying quickly. Mostly Bathrooms because
> they get the most use. Do you find the Lock antenna to be very powerful?
>
> Brian
>
> On 3/13/17 7:55 AM, Osborne, Bruce W (Network Operations) wrote:
>
> We have been using Assa Abloy wireless locks in our newest residences on our 
> 802.1X SSID. The AA batteries do not last as long as advertised. We place Aps 
> in rooms and the lock wireless antenna is on the insode of the door. 
> Obviously, rekeying maintenance is reduced. The locks update once a day. If 
> they see an unknown badge, they check toe server to get a new badge list.
>
> Other than that, be sure to stagger the regular lock scanning times. When we 
> first deployed, they has 600+ locks all trying to hit our management VM-based 
> server at the same time. The server was overwhelmed. With times staggered, 
> the server now handles the load.
>
>
> Bruce Osborne
> Senior Network Engineer
> Network Operations - Wireless
>
>  (434) 592-4229
>
> LIBERTY UNIVERSITY
> Training Champions for Christ since 1971
>
> -Original Message-
> From: Brian David [mailto:davi...@bc.edu ]
> Sent: Saturday, March 11, 2017 6:59 AM
> Subject: Wireless Door lock systems
>
> All,
>
> I was wondering what other Universities experience with wireless door locks?
>
> How have the door locks been working? Is there a lot of maintenance with your 
> systems?
>
> For example battery life, wifi connection problems, broken locks.
>
>
> Brian
>
> **
> Participation and subscription information for this EDUCAUSE Constituent 
> Group discussion list can be found at http://www.educause.edu/discuss.
>
> **
> Participation and subscription information for this EDUCAUSE Constituent 
> Group discussion list can be found at http://www.educause.edu/discuss.
>
>
>
> --
>
> *Brian J David*
>
> *Senior Network Systems Engineer*
>
> *Boston College*
>
> ** Participation and subscription information for this EDUCAUSE
> Constituent Group discussion list can be found at
> http://www.educause.edu/discuss.
>
> --

*Robert J. Ellison*
*Systems Architect - Computing, Telecommunications, and Media Services*
*Adjunct Professor – Computer Information Systems & Technology*
*University of Pittsburgh at Bradford & **Titusville** Campuses*
office +1814-362-7666 <%2B1%20814-362-7666>
fax +1 814-362-5279

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

Re: [WIRELESS-LAN] Certificate for 802.1x

[Jethro R Binks]

On Mon, 13 Mar 2017, Oakes, Carl W wrote:

> This one hits home for me, going through this now on a certificate 
> expiring and battling on what to do next.
> 
> Most clients don't trust any certificate, even if the device is set to 
> trust them OS wide (web browser, etc).  The wireless / supplicant 
> configuration needs to be setup to trust specific certs or CA's.
> 
> Onboarding tools can be used like SecureW2, Aruba , Cloudpath, 
> eduroam CAT to load and enable the RADIUS cert and set it 
> active/trusted.
> 
> If clients onboard themselves, just by manually attaching to the 
> network, they trust the immediate certificate, and I think in some 
> cases, just the digest of the cert, making future cert updates 
> "eventful".
> 
> Clients when authenticating can't check the CRL or OCSP for certificate 
> revocation, since they aren't on the network yet while trying to 
> authenticate.
> 
> So, with all that, I really don't want to get another 3 or 4 year cert 
> and deal with the expiring cert again.  Not a pretty scenario. Last time 
> this happened, it hit us by surprise since we couldn't get a new cert 
> based on the previously trusted CA.  E
> 
> I'm tempted to create a self-signed local CA just for the RADIUS server 
> validation, and a then generate a single cert off that CA.  Then have 
> SecureW2 (what we have) provide that CA and mark it as trusted. Since 
> it's our own CA, was going to make it good for 20 years (just shy of the 
> 2038 unix time clock issue).  Avoids the problem until after I retire. 
> :)
> 
> In testing, so far this seems to work great.  But test is very different 
> than thousands of random student devices.
> 
> In theory it could be just a single self-signed cert, but I liked have 
> the added bonus / flexibility / futures of the self-signed CA just in 
> case.
> 
> Either way, if the private key of the RAIDUS cert gets compromised 
> (commercial or self-signed), it's a world of hurt to get folks moved 
> over in a secure way.
> 
> Has anyone done this?  Good or bad? Am I missing anything key?
> 
> Next up will be client based certs, but that doesn't fix/resolve the 
> above issue.

(Not at all a cert expert, but this is a dump of my experience from a 
while back).

This is what we did, in advance of our commercial cert expiry about 18 
months ago.

Create local root cert with a looong life.  Allow it to issues certs.

Create cert in the name of the radius server.  Doesn't have to relate to 
the DNS name of the server or anything else, just as long as the server 
presents it, and the client is configured to trust the name in it.

You can share the single cert amongst the radius servers.

Use eduroam CAT onboarding to install root cert (and intermediates if you 
have them).

So then, as long as the client knows the (long lived) root, and is 
configured to trust the server name, and the server presents a certificate 
featuring that name (in both CN and subjectAltName), future cert rollovers 
are trivial (modulo your comment about client storing a digest). But if 
you're self-signing, you can make it as long as you like I guess.

We tested in our RADIUS server by having a separate clause based on 
calling-station MAC to divert to the "new" cert.

In advance of the changeover, we created a new CAT profile that had both 
the current cert and the new ones, so we were seeding the new certs for 
some time before (not long enough to be honest - if you know you have a 
cert changeover to perform, plan early early early!).  Android was a pain 
as it didn't like that and wouldn't install both so they had to be left 
until cert-change-D-day to reconfigure.

Sometimes Windows machines wouldn't take it directly either and you had to 
manually do it (vague memories).

You do have to be careful setting some of the parameters on the certs/etc 
and follow good recommendations for key lengths and ciphers and so on. 
There's some information on the eduroam site I think.

I used openssl.  The following was useful, according to my notes, and 
possibly other pages off that:  
https://www.phildev.net/ssl/creating_ca.html

I still have the bits of scripts and openssl.cnf files somewhere.

To recap what might have already been said here and certainly elsewhere: a 
commercial cert for radius servers provides no additional benefit, since 
there is no way for the client to verify the cert other than by how you're 
going to configure it anyway.  In the web browser case, the server is 
comparing the name in the cert with the domain name in the https://, and 
considering if they match up, to provide an assurance you are talking to 
the correct end point and aren't being MITM'd.  In the Radius case, you 
have to onboard the clients anyway to put the certs in there, and (if 
following best practices) tell them which radius servers to trust.  Since 
you're doing that anyway, you can install a matching cert to your own 
specification so why pay $$$ for something that's going to give you pain 

Re: Certificate for 802.1x

[Osborne, Bruce W (Network Operations)]

Then onboarding, we just have the client trust our certificate chain, not the 
server certificate directly, except by server name. This permits us to renew 
our server certificate without causing client trust issues.


Bruce Osborne
Senior Network Engineer
Network Operations - Wireless

 (434) 592-4229

LIBERTY UNIVERSITY
Training Champions for Christ since 1971




From: Oakes, Carl W 
Sent: Monday, March 13, 2017 3:42 PM
Subject: Re: Certificate for 802.1x


This one hits home for me, going through this now on a certificate expiring and 
battling on what to do next.



Most clients don't trust any certificate, even if the device is set to trust 
them OS wide (web browser, etc).  The wireless / supplicant configuration needs 
to be setup to trust specific certs or CA's.



Onboarding tools can be used like SecureW2, Aruba , Cloudpath, eduroam CAT 
to load and enable the RADIUS cert and set it active/trusted.



If clients onboard themselves, just by manually attaching to the network, they 
trust the immediate certificate, and I think in some cases, just the digest of 
the cert, making future cert updates "eventful".



Clients when authenticating can't check the CRL or OCSP for certificate 
revocation, since they aren't on the network yet while trying to authenticate.



So, with all that, I really don't want to get another 3 or 4 year cert and deal 
with the expiring cert again.Not a pretty scenario.

Last time this happened, it hit us by surprise since we couldn't get a new cert 
based on the previously trusted CA.  E



I'm tempted to create a self-signed local CA just for the RADIUS server 
validation, and a then generate a single cert off that CA.   Then have SecureW2 
(what we have) provide that CA and mark it as trusted.

Since it's our own CA, was going to make it good for 20 years (just shy of the 
2038 unix time clock issue).Avoids the problem until after I retire. :)



In testing, so far this seems to work great.But test is very different than 
thousands of random student devices.



In theory it could be just a single self-signed cert, but I liked have the 
added bonus / flexibility / futures of the self-signed CA just in case.



Either way, if the private key of the RAIDUS cert gets compromised (commercial 
or self-signed), it's a world of hurt to get folks moved over in a secure way.



Has anyone done this?  Good or bad? Am I missing anything key?



Next up will be client based certs, but that doesn't fix/resolve the above 
issue.



Carl Oakes

California State University Sacramento









From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Eric Glinsky
Sent: Monday, March 13, 2017 12:11 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Certificate for 802.1x



Hi everyone,



I’m looking for thoughts/opinions/experiences on 802.1x and security 
certificates. I dug through the archives from a few years ago, and from what I 
gather it isn’t even possible to use a 3rd-party cert so devices (iOS, OS X, 
Windows, Android) trust it automatically, but maybe someone has succeeded with 
this by now? If so, which CA would you recommend?



For us, our GoDaddy wildcard cert failed to authenticate clients, so we went 
with DigiCert. That isn’t trusted by clients by default, offering no benefit 
over our domain-generated cert, with which all Apple and Windows 8/10 devices 
must be told to “trust,” Windows 7 fails to authenticate entirely, and Android 
just works. We have a Cisco WLC and Windows NPS.



Thanks for any pointers you can give!



- Eric

This e-mail message is intended only for the person or entity to which it is 
addressed and may contain CONFIDENTIAL or PRIVILEGED material. Any unauthorized 
review, use, disclosure or distribution is prohibited. If you are not the 
intended recipient, please contact the sender and destroy all copies of the 
original message. If you are the intended recipient but do not wish to receive 
communications through this medium, please so advise the sender immediately.

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

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

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

Re: Wireless Door lock systems

[Osborne, Bruce W (Network Operations)]

We have found no issues but are just using them on the rooms and that is where 
we are targeting our wireless usage..


Bruce Osborne
Senior Network Engineer
Network Operations - Wireless

 (434) 592-4229

LIBERTY UNIVERSITY
Training Champions for Christ since 1971




From: Brian J David 
Sent: Monday, March 13, 2017 9:22 AM
Subject: Re: Wireless Door lock systems


Thanks for the information Bruce. We have the same locks. about 1800 of them. 
Some of the batteries are dying quickly. Mostly Bathrooms because they get the 
most use. Do you find the Lock antenna to be very powerful?

Brian

On 3/13/17 7:55 AM, Osborne, Bruce W (Network Operations) wrote:

We have been using Assa Abloy wireless locks in our newest residences on our 
802.1X SSID. The AA batteries do not last as long as advertised. We place Aps 
in rooms and the lock wireless antenna is on the insode of the door. Obviously, 
rekeying maintenance is reduced. The locks update once a day. If they see an 
unknown badge, they check toe server to get a new badge list.

Other than that, be sure to stagger the regular lock scanning times. When we 
first deployed, they has 600+ locks all trying to hit our management VM-based 
server at the same time. The server was overwhelmed. With times staggered, the 
server now handles the load.


Bruce Osborne
Senior Network Engineer
Network Operations - Wireless

 (434) 592-4229

LIBERTY UNIVERSITY
Training Champions for Christ since 1971

-Original Message-
From: Brian David [mailto:davi...@bc.edu]
Sent: Saturday, March 11, 2017 6:59 AM
Subject: Wireless Door lock systems

All,

I was wondering what other Universities experience with wireless door locks?

How have the door locks been working? Is there a lot of maintenance with your 
systems?

For example battery life, wifi connection problems, broken locks.


Brian

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

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



--
Brian J David
Senior Network Systems Engineer
Boston College
[X]
** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/discuss.

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