Re: [WIRELESS-LAN] WLC 5508 logging authentications

[Joachim Tingvold]

On 3 Mar 2016, at 18:12, Matthew Newton wrote:

I’ve found some posts that indicate that info is only available
through SNMP traps, but I haven’t been able to find the OIDs.
Has anyone been able to log auths without using PI?

I feed the whole lot to snmptrapd which just syslogs them, then
push them via logstash into elasticsearch, which makes it easy to
see what is happening (and also tie up with RADIUS logs, DHCP
logs, etc). If you tell snmptrapd where the MIBs ar then it'll
decode them for you - just make sure it's got the whole Cisco-v2
bundle (including the AIRESPACE and CISCO-LWAPP mibs).


I ended up doing this brute-force style a few years back. I started out 
by using the Cisco MIB's, but I experienced that the traps where corrupt 
(or at least the packets where mangled), so I had to do a different 
approach that at least did _some_ error-handling;




It's really ugly, but it did the trick. I believe it should still work.

--
Joachim

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

Re: [WIRELESS-LAN] 5 GHz 20 vs 40 MHz; and, have you tried DFS channels? (annual update)

[Joachim Tingvold]

On 15 Mar 2016, at 15:55, Steve Bohrer wrote:
So, that sounds like a "no" vote on DFS, though we don't have wifi 
VoIP phones. Does any one have field experience and recommendations? 
Any guesses if DFS channels will ever be useable with a student BYO 
client base?


If you have Cisco, I believe you can do RF-profiles per SSID in 8.0MR3 
(due soon). Then you’d be able to do 20MHz for VoIP if you have a 
separate SSID for that (with DFS disabled), and 40/80MHz for the rest 
(with DFS enabled). Best of both worlds, kinda.


--
Joachim

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

Re: [WIRELESS-LAN] Wireless Mobility

[Joachim Tingvold]

On 11 Aug 2016, at 13:39, Osborne, Bruce W (Network Services) wrote:

Perhaps you should consider Aruba Networks / HP Enterprise.

They eliminated "burned-in" licenses on controllers but if you replace 
one of them, they will generate licenses for your replacement, at 
least in our experience.


Regarding Cisco, this “issue” has been eliminated with the new 
SmartLicense system, which makes licenses not tied to the physical 
hardware, meaning you can use the licenses on 8540’s, 5520’s, and on 
whatever new WLC’s that show up in the future. They also recently had 
a campaign where you could do trade-in/upgrade from existing licenses 
(e.g. from WiSM2’s or 5508’s) to the new SmartLicense system (the 
only “downside” with this is that the SmartLicense for AP’s are 
only eligible on SmartLicense enabled hardware, so if you upgrade, you 
couldn’t technically use them on the WiSM2’s anymore, since they are 
not SmartLicense compliant).



We do not purchase support on most of our APs since they have a 
lifetime warranty anyway. For some unusual or mission-critical 
applications (point-to-point for instance) we purchase the hardware 
support to get quicker replacements. We *do* pay support the licenses 
(AP & other) on our controllers but central licensing helps us 
maximize the value of our licenses.


This is also the case for Cisco AP’s. Last few years we’ve bought 
them without support, and utilize the limited lifetime warranty if we 
need to replace broken AP’s (the only downside being that the 
“lifetime warranty” replacement usually takes longer time than 
normal RMA’s -- but this is easily solved by having a small pool of 
AP’s acting as a “buffer” until you receive the replacement).


--
Joachim

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

Re: [WIRELESS-LAN] Cisco Prime Alternatives

[Joachim Tingvold]

On 31 Aug 2016, at 9:50, Jason Cook wrote:
It is good to know though that more people are getting happier with PI 
though, might be worth a bit more effort again on our behalf.


My impression is also that it’s “going the right way” (i.e. 
getting better). However, I still expect to do 3+ TAC-cases for each 
upgrade (-:


--
Joachim

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

Re: [WIRELESS-LAN] Wireless to Wired Bridge

[Joachim Tingvold]

On 15 Sep 2016, at 14:49, Adam Forsyth wrote:
Does anyone have a good wireless to wired bridge that they recommend 
to
students to purchase when they have a wired only device that they wish 
they

could connect in a wireless only residence hall?


For wired-to-wireless, we’ve had great success with “HP 501 Wireless 
Client Bridge” [1][2]. It has 802.11ac and supports 802.1X (including 
EAP-TLS). It can also be powered via PoE, but since we usually connect 
it directly to wired devices, we usually just power it with the included 
PSU. Not relevant for your use case, but it also has RS232-to-IP, which 
is useful for technical and/or medical equipment.


It’s a bit pricey, but totally worth it for our use case.


[1] 

[2] 



--
Joachim

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

Re: [WIRELESS-LAN] WLC Association Failures with reason code 105 and 107

[Joachim Tingvold]

On 21 Oct 2016, at 15:12, Dennis Xu wrote:

You may be hitting this bug for the 105:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuw34201
Fixed in 8.0.135 and later.
107 seems like it may be similarly related to APs hitting a max limit 
as well.
I would consult Tac before upgrading, but seems like there are a 
couple active bugs that could be triggering this.  8.0.140 has a long 
list of resolved caveats that might be worth exploring.
We see the same issue (code 105) here. Upgraded from 8.0.120 to 
8.0.133 with no help. With "show client ap 802.11b AP_name" command, I 
see a lots of clients in idle state, also these idle clients will not 
be cleared out by the idle or ARP timeout. I noticed all these clients 
are inter-controller roaming clients. Then I shuffled some APs among 
controllers to minimize inter-controller roaming and also use 
scheduled job from PI to reboot some APs weekly to clear out the idle 
clients. Now I do not see this error anymore in our environment.


If you have inter-controller roaming with AAA override enabled, please 
also be aware of this bug;

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvb21254

We hit it when upgrading to 8.0.140.0, and it only happens when the 
client roams back the first AP on it’s anchor controller after having 
roamed to a foreign one. If the client roams further to a new AP on the 
same anchor controller, it works again (it can even roam back to the 
first AP it joined, and it will work, so it’s only when hitting that 
first AP when coming back to your anchor controller).


TAC told us that the bug was introduced in versions after 8.0.133.0, and 
is fixed in escalation build 8.0.140.3. They couldn’t tell us if the 
bug is affecting other platforms than 5508/WiSM2, so I guess we’ll 
have to try&fail with our 8540s (-:


--
Joachim

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

Cisco 8540/5520 HA-upgrade - soft reload?

[Joachim Tingvold]

Hi,

Has anyone pursued why soft-reload after an image upgrade actually 
hard-reloads the HA-pair? Normally it doesn't, but it seems to be doing 
that when a new version is involved.


I can't find any documentation regarding the matter -- actually, I 
barely find any documentation regarding soft-reload in general (I know 
that it only reloads the AireOS code, rather than the whole server, but, 
yeah, some details would be nice).


When you soft-reload without a new version, it only takes about 90-100 
seconds, whilst a full, hard restart takes 220-230 seconds. Would be 
nice to actually do upgrades in the "sub 2 minutes" area, rather than 
"almost 5 minutes".


--
Joachim

**
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 'flash' bug

[Joachim Tingvold]

On 19 Jan 2017, at 21:46, McClintic, Thomas wrote:
Next time you have this issue, try connecting a console to the AP and 
run the following:


ap: fsck flash:
Are you sure you want to fsck "flash:" (could take some time) (y/n)?y
flashfs[0]: …
ap: boot

This works for us on the failed to reload properly APs.


We've had this issue as well, and we've solved it by doing the exact 
same (the "fsck flash:" command).


I've always wondered why the AP doesn't do this automatically, as the 
error shown during boot (when it fails over to rommon) actually 
references that command. At least it's been doing that in our case.


--
Joachim

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

Re: [WIRELESS-LAN] Aruba AP Models - 315 vs 325

[Joachim Tingvold]

On 2 May 2017, at 15:58, Norman Mourtada wrote:
If these are for dorm rooms, did you take a look at the new aruba 303H 
APs for hospitality. At Suffolk university we are planning to install 
these in our dorm rooms this summer, wall mount using existing cat6 
cables.
Price is affordable at list of $495. See datasheet 
http://www.arubanetworks.com/assets/ds/DS_AP303H.pdf


Hi,

Does these do any kind of “give network to the three local ethernet 
ports via the WLCs”? (i.e. that traffic from clients, connected to the 
wired ports, isn’t terminated locally?). And does it do some kind of 
802.1x on those wired ports? Couldn’t find anything in the data sheet 
or on Google confirming/denying such features.


--
Joachim

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

Re: [WIRELESS-LAN] ArubaOS 8.X Experiences

[Joachim Tingvold]

On 8 Jun 2017, at 19:11, Sweetser, Frank E wrote:
[…] and from there I'm really looking forward to seeing how well the 
live upgrades work!


Hi,

Do you know how that works in detail? All I can find is the sales 
mumbo-jumbo that over-promises (as usual); "[…] allows customers to 
upgrade their wireless network in real time without any impact to user 
connectivity. Upgrade process is simplified, no maintenance downtime 
[…]".


Looking at the installation manual of 8.1.0, it doesn't say how it's 
done, but I managed to find a "dumbed down" non-official explanation 
that went something along the lines of "[…] move all APs to secondary 
controller, then upgrade the primary controller. After primary is 
upgraded, APs are gradually upgraded/moved to the primary controller 
(i.e. not all at once). Once all APs is upgraded, the secondary 
controller is upgraded, and then the redundancy is restored".


How are those APs selected? Just random order? If so, that doesn't 
really mean "no downtime" or "no impact on users", as you could risk 
neighboring APs to be upgraded at the same time, causing smaller or 
larger blindspots. Of course it sounds better than to "take it all 
down", but, yeah, not really ISSU…


--
Joachim

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

Re: [WIRELESS-LAN] Cisco Code Version

[Joachim Tingvold]

On 1 Aug 2017, at 17:33, Ciesinski, Nick wrote:
While WLC 8.5 did add IPSK it is probably safe to say its rather 
worthless for most at this time.  For those who have used ISE if you 
watch the video on how they make IPSK work it isn’t feasible to give 
each of your users their own PSK key to connect to wireless.  The 
current implementation within ISE required no feature additions to ISE 
to make it work.  All they do is have a rule to classify a device 
and/or user and then send a particular PSK value that it should be 
using.  This is a 100% manual process  for each device and/or user as 
nothing is baked into ISE to have a user register their account or 
device(s) and be presented a PSK to use.


IPSK *and* ISE might be "worthless" when combined, but IPSK in it self 
is not (even in it's current implementation). The limitations you're 
talking about is purely with ISE, and not IPSK.


We use ClearPass, and we can easily query an SQL-server with MAC<->PSK 
mappings, yielding unique PSKs based on MAC-adresses. This SQL DB could 
be fed via whatever systems that already exists (CMDB or whatnot), or 
you could spend an hour making a simple web-frontend.


The only thing holding us back upgrading to 8.5 "right away" (only to 
get IPSK) is the same concern Lee has; not touching it until MR3 or 
similar, purely for stability reasons (-:


--
Joachim

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

Re: [WIRELESS-LAN] AAA Override Bug?

[Joachim Tingvold]

On 15 Sep 2017, at 20:52, Hector J Rios wrote:

80MR4:AAA override VLAN lost on inter-controller roaming
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvb21254
That definitely sounds like it could be our problem. I’ll look into 
it. Thanks!


Even if you're hitting this bug, we've encountered similar behavior 
before (not related to roaming); we use AAA override for all clients, 
and never actually let clients fall into the default WLAN interface. 
Regardless, we've seen clients in this default WLAN interface (and even 
getting IP addresses). It's been somewhat random, and with a very low 
number of clients, but not a behavior we want (since clients potentially 
might get access to resources they shouldn't).


To mitigate this we set the default WLAN interfaces to a VLAN not even 
present on the trunk towards the WLC, so that clients that might end up 
there won't be able to reach anything. We probably should've filed a bug 
when we first noticed this behavior, but the fix was quicker than going 
through the TAC-dance, and has worked ever since (-:


--
Joachim

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

Re: [WIRELESS-LAN] Wi-Fi Request for University Conference event

[Joachim Tingvold]

On 27 Sep 2017, at 14:17, Yahya M. Jaber wrote:
- Would give up my guest SSID through ISE. As still there is no 
feature to increase the idle timeout on the WLC “like the sleeping 
client” which will stop users from complaining about the constant 
login once they go idle “”especially iPhone that turns off WiFi 
after sometime when its on the lock screen!!””…I know that I can 
increase the idle timeout, but that would prevent getting real client 
count from the WLC and PI and might affect the client WLC DB.
- Would use simple AUP guest SSID with sleeping client timer of 1-4 
days.


Hi,

You should look into CWA (Central Web Authentication), if that’s not 
already what you’re looking into. Then you can use MAC-caching, where 
you can set the time for how long they should he allowed into the 
network before needing to re-enter the username/password. Hence, you can 
set the idle-timeout to a more sane value. CWA works with most RADIUS 
servers (i.e. you don’t specifically need ISE).


--
Joachim

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

Re: [WIRELESS-LAN] Wi-Fi Request for University Conference event

[Joachim Tingvold]

On 27 Sep 2017, at 14:50, Yahya M. Jaber wrote:

I do use CWA with ISE.
The issue is not with the ISE, its with the WLC that by nature has the 
idle timeout for 5 minutes.


Hi,

As I tried to express; the idle-timeout becomes irrelevant if you 
implement MAC-caching. Then the user only need to log on once per device 
(based on the MAC), and they will automatically be logged 
on/authenticated (MAC-auth) during the timeframe configured in your 
RADIUS server.


--
Joachim

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

Re: [WIRELESS-LAN] Clearpass Bug - Posture and Profile Data update

[Joachim Tingvold]

On 11 Oct 2017, at 19:01, Ferguson, Michael wrote:
I didn’t see any (until Chad posted later) and so we thought our 
issue was more isolated. We wasted 20 minutes of valuable MTTR time 
collecting Server Logs when all we needed to do was start the 
“Policy server” service.


"Only start the Policy Server" was not the case for most of us. The bad 
update came, followed by failure of the "Policy Server". CPPM tried to 
restart it (entries in event viewer), but seems to only try that for a 
pre-defined number of times before "giving up", at which point the 
"Policy Server" becomes "permanently" stopped (regardless of updates, 
unless manually started).


In our case, the bad update came in at around 09:03 CEST, we discovered 
it a few minutes later, went on call with Aruba/HPE support (which after 
about 10-15 minutes could tell us that "the whole world has the same 
issue", more or less). At about 10:10 CEST a new update came, followed 
by yet another update at 10:50 CEST or so. At this point we had an 
Aruba-engineer on the phone, but even when starting "Policy Server" 
manually, it shut down after a few seconds. It wasn't until a third 
update, at around 11:23 CEST, that the service remained running after a 
manual start. We had to manually start it on all members in the cluster, 
for all our clusters.


Fun times (-:

--
Joachim

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

Managing static power/channel assignments?

[Joachim Tingvold]

Hi,

How are people managing their static assignments of channel and power?

We’ve used DCA/TPC on all our deployments, and any tweaking/fine 
tuning has been done in either of those. However, we probably need to 
have some static assignments now that we’re deploying APs in our 
elevators (to limit cascading). I know the current DCA/TPC algorithms 
somewhat mitigates cascading, but there will still be some that we hope 
to avoid by having static assignments on the APs in the elevators (and 
maybe the closest AP outside the elevators on each floor). There should 
be no scenarios where the APs in the elevators ever needs to change 
their power level, nor their channels, so it makes no sense to have TPC 
or DCA on them.


I haven’t had time to test this yet, but I’m thinking of using RF 
Profiles;


 * Specify TPC max/min power levels in such a way that it essentially 
is a static power level assignment
 * Specify DCA with only one channel available, essentially making it a 
static channel assignment


We have two APs in each elevator, so we’d create two RF Profiles; the 
TPC would be configured equally, but the DCA would have two different 
channels between the two profiles.


The plan is then to assign these RF Profiles to AP Groups, and then we 
can just assign APs to those AP Groups. This would make it easy to 
change APs in the future, without having to manually configure each AP.


My only concern thus far, is that it seems as if the WLCs will consider 
APs with different RF Profiles as “rogues”. Is that the case, even 
if the APs are on the same WLC? I cannot find anything in the 
documentation that confirms nor denies this.


--
Joachim

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

Re: [WIRELESS-LAN] Managing static power/channel assignments?

[Joachim Tingvold]

On 1 Dec 2017, at 15:31, McClintic, Thomas wrote:
It won't see them as rogues so you need not be concerned there. It is 
common practice to create a RF Profile variant for multiple AP Groups 
and those groups be within RF range of each other on the same 
controller.


Yeah, that was my assumption on the matter as well, but this [1] 
document might disagree with that, as it states the following;


“[…] the access points will then select the beacon/probe-response 
frames in neighboring access point messages to see if they contain an 
authentication information element (IE) that matches that of the RF 
group. If the select is successful, the frames are authenticated. 
Otherwise, the authorized access point reports the neighboring access 
point as a rogue, records its BSSID in a rogue table, and sends the 
table to the Cisco WLC […]”.


[1] 




I'm confused on the DCA being one channel, you may want to reevaluate 
that. It would cause you to have separate RF Profiles per channel 
which sounds daunting. May want to just set the channel statically or 
change the DCA interval/time.


The point was to avoid having to fiddle with manually configuring 
several static parameters per AP, that essentially would be identical 
for each deployment. Hence the idea to “simulate” static assignments 
via the RF Profiles, solely so that we can assign such static 
configurations through just AP Groups assignment. This is easier than 
manual configuration of each parameter (less things to configure), and 
also less prone to human errors (compared to manual assignments).


I’m not entirely convinced yet; it was more of a shower thought (-:

--
Joachim

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

Re: [WIRELESS-LAN] Managing static power/channel assignments?

[Joachim Tingvold]

On 1 Dec 2017, at 16:18, McClintic, Thomas wrote:
> RF Group and RF Profile are different.
> Group is a controller thing and Profile is an AP thing.

Ah, of course. Now I just feel stupid; thanks for clearing that up (-:

-- 
Joachim

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

Re: [WIRELESS-LAN] Managing static power/channel assignments?

[Joachim Tingvold]

On 1 Dec 2017, at 16:16, Jeffrey D. Sessler wrote:
I'm curious about what's driving the need for two AP's in each 
elevator, or to have them there in the first place? Even in 
medical/hospital settings, I typically see an AP placed on each floor 
in the elevator lobby. Given how sticky clients are today, it seems to 
work very well even for latency sensitive services like VoIP.


Hospital, where each floor is almost double the height of normal floors 
(where almost half of it is above the ceiling, containing nothing but 
metal, pipes, and other non-RF-friendly stuff). Each elevator has it's 
own shaft of concrete, and then you can add all the metal in the 
elevator cab on top of that. We did some tests, and there's no way 
clients will be able to have a stable connection going between floors; 
at least not when traversing multiple floors in rapid succession (i.e. 
going from 1st to 8th floor without stopping in the other floors). We 
have APs outside the elevators on each floor, but that's not enough.


The reasoning behind two APs is merely for redundancy when an AP or the 
Cat6/6A elevator cable fails (they /will/ fail, eventually); the 
elevators are in high traffic, making it hard to "just stop one" for 
hours to fix a broken cable or exchange a broken AP. We also try to 
cable "every other AP" to different IDFs, giving redundancy in case of 
outage of a single IDF, or for maintenance cases (where we can software 
upgrade all equipment in an IDF, without affecting wireless coverage).



It also reduces problems with location-based services because the AP 
isn't changing elevation all the time.


Yeah, I'm not really looking forward to that part. But coverage > 
location-based services for this particular scenario.



--
Joachim

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

Re: [WIRELESS-LAN] Another Cisco WLC Code Thread

[Joachim Tingvold]

On 19 Dec 2017, at 21:46, Alan D Wang wrote:
We have been running 8.3.133.0 on several pairs of 5520s and 8540s 
without

an issue.


We're running 8.3.133.0 on our 5520s and 8540s as well. We're running 
almost 3700s exclusively (about ~7k of them), with a few old models 
soon-to-be-replaced (mix of 1142s, 2600s, 3500s and 3600s). It's been 
running rock solid for us.


We've hit bug CSCve70752, which is confirmed to be present in all 
flavors of 8.3MR3. Causes outdated information in Prime, due to 
incomplete snmpwalks on the WLCs. Confirmed to be fixed in 8.3MR4 
(scheduled to be released mid-January). I've asked if the bug is present 
in 8.5/8.6, and if it is, ETA on the fix for those.


We're also having some troubles with AP802s (within 891 ISRs), that has 
been extremely unstable after moving them off our WiSM2s (running 
8.0.140.0), and onto our 5520s/8540s. Moving them back does not help, so 
the culprit seems to be something that is upgraded, but never 
downgraded. We're still working with TAC on this one (6 months, still 
going strong), where the latest status is that we've shipped some of the 
faulty units to a lab in Netherlands for further analysis.


Probably going for 8.6 very soon, as we're starting to buy 3800s, and we 
need the dot1x supplicant support (that was added in 8.6). Not really 
looking forward to it, for two reasons (so far);


 1) AP802s are not supported after 8.5… (inside 891 ISRs; they are 
still for sale, and no EoL/EoS announcement is done… good job, Cisco 
(-: ).


 2) Upgrading 1700/2700/3700s to 8.5 (or any release after 8.5) 
requires downloading the software twice from the WLC (due to the 
filename being renamed). Pre-download will only work for the first of 
the two downloads. Since only 1k APs can pre-download at the same time 
(on 5520/8520s at least), you'll get a queue for any AP above 1k (we 
have 8540s with 3.5k+ APs), causing our downtime window to go from the 
usual ~400s for software upgrades, to 30-60 minutes or more. YAY!


--
Joachim

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

Re: [WIRELESS-LAN] Another Cisco WLC Code Thread

[Joachim Tingvold]

On 20 Dec 2017, at 5:06, Jeffrey D. Sessler wrote:
[…] I have three releases to choose from, or four if I wanted to run 
8.6 beta! ;-)


FYI; 8.6 was released on CCO 6 days ago (14th).

--
Joachim

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

Re: [WIRELESS-LAN] Cisco 8.3MR4 Interim Availability

[Joachim Tingvold]

On 10 Jan 2018, at 15:18, Mccormick, Kevin wrote:

Looks like Cisco has 8.3MR4 available for testing.


From what I’ve heard, it’s scheduled to be released end of January, 
or beginning of February.


--
Joachim

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

CCKM timestamp tolerance

[Joachim Tingvold]

Hi,

We’ve encountered some clients on our wireless network that seems to 
handle roaming worse than other clients. Our WLC (Cisco 8540) responds 
by excluding the client after some failed attempts (which, of course, 
works as it should).


The culprit seems to be that the clients uses old CCKM-data when 
re-associating/roaming;


  “Received Timestamp deviation > 1 sec in REASSOC REQ IE from 
mobile”


I know this can be tuned (“config wlan security wpa akm cckm 
timestamp-tolerance”), but that also increases the chance of replay 
attacks (the WLC even warns about this). However, I’m not sure if this 
is a “real” security issue in practice? (e.g. raising the tolerance 
from 1000ms to 5000ms).


Since these are the first clients we’ve observed with this issue, 
I’m more inclined to ask the vendor to fix the issue on their end, but 
I know that will be a “fight” (that I’m not sure if I want to 
have). The “easiest” solution is of course just to increase the 
tolerance (if that helps, that is).


What is the BCP on this matter?

--
Joachim

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

Re: [WIRELESS-LAN] More client weirdness

[Joachim Tingvold]

On 12 Apr 2018, at 9:17, Jason Cook wrote:
If you want to cut straight to flash issues (and a download link for 
the poller)

54:50


Or just go to page 59 on the PDF/PowerPoint-slides (-:

--
Joachim

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

Re: [WIRELESS-LAN] Cisco 8540 WLC random reboots

[Joachim Tingvold]

On 9 Jul 2018, at 19:09, Matthew Craig wrote:

Is anybody else seeing this issue?

Yes, we ran into this, as did other schools from what I hear.
After working with TAC for quite awhile, they came out with 8.5.131.0 
and that seems to fix the issue, as well as some other issues.


You probably hit bug CSCvi38017 (as did we). Fixed in 8.5MR3. 8.5.131.0 
has since been released, due to the ETSI-thingie.


--
Joachim

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

Re: [WIRELESS-LAN] Cisco - Field Notice - 70253 - Wireless Client Fails to Associate: AID Error

[Joachim Tingvold]

On 23 Aug 2018, at 13:33, Osborne, Bruce W (Network Operations) wrote:
We just moved to Aruba 8.2.x this summer and are impressed with the 
automated RF management capabilities. We can now upgrade all or part 
of our wireless network with zero downtime.


You say “zero downtime”. Aruba says “hitless”. None of those are 
true.


Don’t misunderstand; it’s far better than what Cisco has, but the 
system disconnects the clients from the AP side of things, and hence, 
from a client perspective, it’s not “hitless” or “no 
downtime”. They just suddenly get disconnected, and they have to 
reconnect. It’s not the clients decision to move to a new AP.


Would I like this on Cisco; absolutely. I’m not holding my breath, 
though.


--
Joachim

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

Re: [WIRELESS-LAN] Site Survey Tool (laptop/tablet/2-in-1)

[Joachim Tingvold]

On 23 Aug 2018, at 12:59, Lee H Badman wrote:
I’m frequently an Apple skeptic but love the dual-boot Mac paradigm. 
Run Ekahau on Windows side, native packet capture etc on OS X side.


You can run ESS natively on OS X nowadays, so theres that.

--
Joachim

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

Re: [WIRELESS-LAN] Cisco - Field Notice - 70253 - Wireless Client Fails to Associate: AID Error

[Joachim Tingvold]

On 23 Aug 2018, at 15:48, Jeffrey D. Sessler wrote:
It’s great to hear Aruba is adding features such as “automated RF 
management” that Cisco has had for over a decade.


My understanding of the “automated RF management” part is directly 
related to the upgrade process (and not DCA/TPC, as you’re suggesting, 
which Aruba has had for some time).


It splits the APs automatically into groups based on their channel 
assignment (since, given similar approach as DCA, this gives a rough 
estimation on “APs that are overlapping each other” — could also 
be improved in the future using signal strength an AP sees other APs). 
It then moves clients off of one of those groups (making them join 
other, adjacent APs), reloading those clientless APs into the new 
software version, and then moves clients back when it moves onto the 
next “channel group”. Cleanse and repeat until all groups are done, 
giving you “zero downtime”.


This is at least how it was last time I read about it, and is by far 
superior to the way Cisco does it (where you manually have to fiddle 
with groups within Prime — and that’s without talking about Prime 
itself…).


The Cisco-solution also requires a separate controller to do this, 
whilst Aruba uses it’s redundant controller by automatically handling 
“splitting” the HA-pair (by upgrading one of them, moving the APs 
according to the “channel groups”, and then finally upgrading the 
last controller).


The “equivalent” with Cisco would be to split your HA pair manually, 
move all APs to one of them, upgrade the other, move them using the 
rolling-AP-group-thingie in Prime, then upgrade the last, and finally 
join them back as a HA, causing significantly more downtime than a 
normal Cisco upgrade process. Or you could buy a completely separate WLC 
to achieve this, but that’s somewhat a waste of money if you already 
do HA/SSO (and buy WLCs in pairs).


In all seriousness,. if you’re talking specifically about AP 
updates, cisco has had AP code pre-download for years, resulting in 
between 2 to 4 minutes downtime when rebooting a multi-thousand AP 
controller. Not hitless, but low impact for sure.


I’ve never managed to do less than ~400 seconds on HA/SSO-enabled 
8540s with 3k+ APs. That’s “a lot of time” many places (maybe not 
edu, but for sure in healthcare or other mission-critical businesses), 
which would be reduced to whatever time it takes for a client to 
re-associate after being “kicked” off the network (so time depends 
on the client, but would probably be sub-1s in many cases).


--
Joachim

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

Re: [WIRELESS-LAN] Sickness for rf (802.11)

[Joachim Tingvold]

On 31 Aug 2013, at 16:40, Hurt,Trenton W. wrote:
So I had to turn off aps for a person on my campus for areas they 
where visiting due to rf sickness.  They provided a dr note too.  Has 
anyone every had a request for something like this?


Not heard of RF-sickness with a doctors note, but we have similar 
scenarios.


I work in the healthcare sector, and it's quite common that we have 
episodes where people want to turn off our AP's (and some people just 
unplug them without asking -- often repeatedly even if they're told to 
not do it). Both patients and employes do this, and especially of the 
previous generation (i.e. older people).


The ironic part is that some of these are doctors and/or professors 
within the field of radiation, and they have pagers and mobile phones on 
them while standing there pointing towards the AP they would like to 
have turned off. (-:


In any case, NRPA (Norwegian Radiation Protection Authority) has some 
reports they've made that we throw in the faces of people trying to 
argue to have the AP's turned off (which uses approximately the same 
numbers as ICNIRP, which again is approximately the same numbers as you 
guys use in the US).


In some scenarios where they keep unplugging the AP, or if it's on a 
psych ward, we use external antennas (with the AP mounted above the 
ceiling), or if that's not possible (due to fixed sealing, etc), we use 
Oberon enclosures to limit the physical access to the AP (which also 
have the added effect of not showing the LED).


--
Joachim

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

Re: [WIRELESS-LAN] cisco custom webauth email field

[Joachim Tingvold]

On 12 Dec 2013, at 19:32, Matthew Ballard wrote:
I’m setting up a custom webauth with email input required for a 
test wlan.  The problem I keep having is that on the webauth page if 
you place your cursor in the email address field and press 
enter/return on your keyboard it takes you to the default wlc 
internal webpage.
I don't have personal experience with the issue, but that is a common 
web issue when JavaScript is used for the submission. A web person who 
knows some JavaScript should be able to fix it pretty easily.


Matthew is right. The HTML-files supplied by Cisco uses 'BUTTON' as the 
form type (and not 'SUBMIT'). It then uses the JavaScript onclick-event, 
which puts values into the form fields, and calls 'submit()'. Using 'Go' 
(on iOS/Android) or 'Enter' (on normal keyboards), simulates a 'SUBMIT', 
hence 'BUTTON' won't be triggered, and you get the behavior you're 
explaining.


So, changing 'BUTTON' to 'SUBMIT' should do the trick.

--
Joachim

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

Re: [WIRELESS-LAN] Cisco WiSM-2 HA?

[Joachim Tingvold]

On 5 Feb 2015, at 9:27, Oliver Elliott wrote:
We have some strange issues with the 6500 VSS at the moment so that 
could relate.


If the issues we've seen up to now have been caused by this VSS issue,
8.0.110 seems to have been good so far, still have an ongoing TAC case 
so

we'll see what happens.


You had the VSS-issue before you upgraded your WiSM2's to 8.x? What are 
the symptom(s)/issue(s)?


I've got 6 WiSM2's waiting to be paired with their HA's. I heard about 
the ping-failover-issue with 7.6, and I've been holding off HA until I 
could upgrade to 8.x. We were on PI1.4 due to 7.6 due to 3702's, so had 
to wait for PI2.2 before we could upgrade to 8.x. Just finished 
upgrading to PI2.2, so 8.x and HA is next on our WiSM2 in the lab.


--
Joachim

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

Re: [WIRELESS-LAN] LAP/WLC MIC lifetime expiration causes DTLS failure

[Joachim Tingvold]

On 25 Mar 2015, at 3:30, Trent Hurt wrote:




A quick way to list this information via the Prime API;



It doesn't do pagination (because I was lazy), so you need to bump 
limitPageSize to something more than your total number of AP's (f.ex. 
10k by adding 'nbi.rateLimit.limitPageSize=1' to 
/opt/CSCOlumos/conf/nbi.properties).


It lists the number of AP's expiring per year and week, including the 
AP-name, model and map location;


## 2015:
Week 48: 1
		AP-- (AIR-LAP1131AG-E-K9): Somecampus > Somebld1 > 1st 
floor

Week 49: 1
		AP-- (AIR-LAP1131AG-E-K9): Somecampus > Somebld2 > 2nd 
floor

## 2016:
Week 03: 1
		AP-- (AIR-LAP1131AG-E-K9): Somecampus > Somebld3 > 1st 
floor

Week 14: 2
AP-- (AIR-LAP1131AG-E-K9): Root Area
AP-- (AIR-LAP1131AG-E-K9): Root Area
Week 15: 1
		AP-- (AIR-LAP1131AG-E-K9): Somecampus > Somebld4 > 2nd 
floor


--
Joachim

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

Re: [WIRELESS-LAN] Eduroam and AUP acceptance?

[Joachim Tingvold]

On 25 Feb 2013, at 22:08, Kern, Paul wrote:
I'm looking for advice.  We are interested in using Eduroam, but we 
require our users to agree to an AUP before accessing any university 
networks.  Eduroam does not allow the use of captive portals with 
their service, so this puts us in a bind.


Hi,

Authentication on eduroam is done using 802.1X, which again requires a 
username and password. Couldn't you just include the AUP when the user 
account is given to the user? This might not cover users visiting, but 
at least it covers your own users.


--
Joachim

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