That’s the one. Have you reported it to them? I didn’t pull the word rare out
of thin air... That’s what I’ve been told and that it affected roughly 0.0001%
of deployed 515s. I guess I’m just being naive.
Thanks for waking me up!
Regards,
Keith
M: (803) 464-2397 O: (919) 962-6564
Sent from my
We upgraded from ArubaOS 8.5.0.9 to 8.6.0.6 last Sunday (12/13). No major
issues so far. We have 6500+ APs (135s, 2xx, 3xx, and AP-5xx). Only one AP
didn’t come back on its own but it only required a power cycle. It did take a
while though. Seemed like longer than previous upgrades. Plan
We went from 8.3.0.13>8.5.0.11 this week and (knock on wood), no issues so far.
(Controllers - Running VMM, 7280s.)
Of roughly 7,250 aps (mostly 315,365,367 and 303H), we had to power cycle/nudge
a total of 3. The 303h’s taking a while is normal experience (even as CAP) for
us.
This was our
That's what I was thinking too. But we would have to have a spare
controller for that to work :) Maybe Aruba should give us a free license
for a virtual controller for our troubles.
--Dan
On Fri, Dec 18, 2020 at 12:04 PM Michael Davis wrote:
> I believe the only way would be to downgrade a
We upgraded to 8.6.0.6 this past Sunday, no issues. All ~6600 APs came back,
not a single one dead. Usually we have about a dozen that need to be replaced.
Only been running a week and we haven’t seen any issues thus far. We have a
wide variety of AP models, 204s, 205Hs, 214s, 215s, 224s, 225s,
We also are not using clustering. Our initial roll out was a clustered,
however, after experiencing a “very rare” STM memory leak that heavily affected
users in clusters with an odd number of controllers, we moved away from that.
Chris
From: The EDUCAUSE Wireless Issues Community Group
I believe the only way would be to downgrade a lab controller to the old
version and use
DHCP options to tell the looping AP to connect to that downgraded
controller. From
there a remote factory reset and DHCP options pointing back to the new
version..
Easy Peasy ;)
On 12/18/20 10:32 AM,
We just upgraded to 8.6.0.6 last night from 8.5.x. Too soon to tell how
everything will behave, but testing last night looked good and of the 2700 APs
upgraded (103s, 205s, 215s, 305s, 315s, 345s, 515s, 275s, 375s) all came back
up.
Fingers crossed.
Chris
From: The EDUCAUSE Wireless Issues
Yep, we have an AP-205h that failed to upgrade. I think it was from
8.7.0.0 to 8.7.1.0 this fall. That AP is in quarantine space and is still
broken as none of us are willing to go replace it yet. Luckily there was
enough coverage from neighboring AP's, but it is less than ideal for sure.
If
There’s no way that I’m aware of to fix the issue if it’s already occurring.
You cannot telnet into the AP remotely because the AP doesn’t have a config
that could enable telnet so you must console into the AP to get access to the
APboot environment and then change the os_partition to whatever
We have been running 8.7.1.0 since shortly after it came out. Seems no
more or less buggy than any other release so far :)
--Dan
On Fri, Dec 18, 2020 at 8:16 AM Gary French wrote:
> Hi,
> We have been on 8.3.0.7 for a while now and things have been fine. There
> are some CVEs that came out
I reported to them last Fall and was working with a tier 2 or 3 engineer
on the issue,
but the only resolve was to console in and change the boot partition
flag manually.
Since that was a work around and I ran out of example failed APs to
test, the case was
closed with the workaround.
On
We're scheduled to upgrade our 7220 Cluster from 8.5.0.9 to 8.5.0.11 per
HP/Aruba's recommendation to patch some CVEs.
https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-hpesbnw04072en_
us
We have not been happy with 8.5.0.9 since our upgrade to it this past fall.
I am
We have a few customers on 8.6.0.6 (and similar) code and have seen some issues
that sound similar to what you're describing below. One college case has been
open for 2 months now, with the issue being some weirdness with a config that
was applied to MM but didn't get pushed down correctly to
Keith, I tried the things you mentioned on one of our physical controllers:
I was able to see the file names listed on the physical controllers from the
web UI (they appear as a dropdown).
I can SCP from the CLI of the physical controller (this is normally how I back
things up); it worked just
That's not a bad idea in general, but in this case it's not only student
housing in the midst of a COVID crisis, it's student housing partially reserved
as isolation housing for anyone who tests positive. Advance RMA absolutely
makes sense as far as wasting less time perched on the ladder, but
I really struggle with the notion of ever actually visiting deployed APs to do
console work- regardless of vendor. If the bug is that bad, I'd seriously
consider demanding an advance RMA for each of them. That way the site visit is
a replacement rather than a tech monkeying around with file
Hi,
We have been on 8.3.0.7 for a while now and things have been fine.
There are some CVEs that came out creating the need to
upgradeLooking to upgrade to 8.7.0.1. Has any one tried looking at
that?
Gary D. French
Network Administrator, Wireless
Abilene Christian University
--
I recently performed an upgrade that included about 90 505s, and strongly
suspect I hit the same bug on the entire batch - except, of course, for the one
that I kept and put in the lab environment. That one stubbornly refused to
fail, upgrading flawlessly every time.
Has anyone ever heard if
> We just went to 8.5.0.11 from 8.5.0.8 and .9 this week and I’ll be honest,
> I’m not thrilled with it.
We just ran an update to 8.5.0.11 for 3am this morning, and woke up to read
your message as I was getting ready to check on everything... yikes!
I'm glad to report that we aren't seeing any
Hi Jason,
I’m glad things seem to be going well for your upgrade, I would never wish or
hope that someone experienced bugs or issues.
In saying that, have you noticed any flakiness in the web UI? Dashboard not
loading, files not visible when going to Diagnostics -> Technical Support ->
Copy
21 matches
Mail list logo
