We recently purchased a SideKick 2 and iPad Pro to make site surveying faster. I tested it at the office a few times with great success. Then, the worst thing happened, my iPad was updated to iOS 26 and Ekahau stopped working. I finally got around to troubleshooting the issue, and it appears that when you upgrade to iOS 26, “Local Network” is disabled for the Survey app.
Settings>APPS>Survey, enable Local Network.
After re-enabling it, everything worked perfectly and as intended.
I had a post related to Chromebooks as a draft for quite a while and due to my writing over time it got confusing.
The issue was that since the implementation of our Aruba network, we’ve had nothing but problems with the Chromebooks. At first it was the missing ghz network, then the lack of coverage (which is ongoing), and now the slowness and random networking drops when doing the most basic things.
First up was to find out if that was a Chromebook exclusive issue. Thankfully it was, as we could not replicate it on any other device. So we then moved onto the Chromebooks themselves.
We confirmed they were running the most recent ChromeOS, with updated NIC firmware, adequate storage space, we even power washed them to make sure no pre-existing config would affect them. Once that was investigated, we moved onto network configurations.
We started with removing all Fast Roaming options, 802.11k, Quiet RRM IE (knowing that these are something that often affects devices with low quality NICs). No changes.
Removed 802.11be and ax, still no change.
We then enabled DMO and MTO and set a threshold of 30 and based on my understanding of some reading, I set the Beacon Rate to 12. After that change was made, we have a previously very problematic Chromebook cart start working (24 out of 25). Import to note they were all Lenovo 100e Gen4.
After establishing that it now seemingly worked, I waited and tried re-enabling roaming, and it all fell apart again. So for now we will stick with the current configuration.
Found a cart of laptops that were not working they were all Lenovo 100e Gen 2 devices, which cannot upgrade past 137.0.7151.137. A huge problem as ChromeOS 137 has a known Wi-Fi issue that causes high latency and poor throughput. The permanent fix is to update to ChromeOS 138 or newer. Looks like for now we need to roll back many Chromebooks to 136.
But for all Chromebooks running the proper ChromeOS the issue has seemingly been solved.
One of my major complains about linkedin is the above style of content. While the gist of the message isn’t false, it’s also not entirely accurate. The random font/alphabet type in the word is not something that would commonly be a giveaway as to something being amiss (to be pedantic,in this case the “a” in the latter being from the cyrillic alphabet is false, it’s from the greek alphabet as can be seen below. Though frankly, that’s one of the least important parts).
While many have commonly seen links from micr0soft.com instead of microsoft.com, it’s also very common to have addresses that look valid. You can have both of the exact same link go to different URLs. Example of an email I sent myself, from a basic overview they are the exact same address.
But by simply highlighting the link with your cursor the bottom of your page should display where the link will send you to if you choose to click on it.
It gets worse, often enough the URL they’ll redirect to with start with a valid looking URL that is long enough that you don’t see it end with something like a .ru domain. Example, microsoft-accounts.ru.
A few things to stay safe would be to
Hover on the links before clicking, ideally check the full link to confirm its validity.
Use a secure browser.
Don’t trust links from unknown senders, heck, be suspicious of ones sent by people you know, you never know if their accounts were compromised.
When in doubt, type it out. You can always type in the URL manually.
Provisioning Aruba APs has been drastically different then the Cisco ones. With Cisco I would just have to SSH in and point them to the WLC and it was done. With Aruba Central it’s a bit more convoluted.
We start in HPE GreenLake where we “Add Device”, provide it with a SN and MAC, on the next page, you select the Require Subscriptions button/tab then select the AP and assign it a license.
Now onward into Aruba Central, under Maintain>Organization we have to apply the APs to the proper Group and Site.
For the Sites, find your newly licensed AP (under the unassigned Site Name), and click and drag the AP to its new site.
Do the same with the Group.
Now go to Maintain>Firmware while under the Group or Site you have sent the AP to and find the AP and click the upgrade button.
Select the version of the firmware you wish to update to, here you can set it up to upgrade now or at a later time.
At this point we navigate to the Group or Site, find the AP and confirm it is in fact online and broadcasting. We make sure the Country Code is set, your network port is up and your radios are up.
We’ve encountered a substantial issue with our Aruba deployment, I suppose one of the major faults of using many of the default settings/profiles with the AP615 devices we are using (thankfully it is not affecting the AP635). The flaw is that the Flexible Dual Band: Automatic profile for the APs has been making it that we have no 5Ghz network being broadcast on ANY of our 1000+ AP615 devices. While troubleshooting I pieced together that manually setting it to 5GHz and 2.4GHz the APs then broadcast the bands they are supposed to.
After spending a bit of time reading about the settings, it is my understanding that this issue of the ghost 5GHz may have been of our own doing as it is meant to broadcast 2.5 and 5 OR 6G based on user “requests/ability”. I believe that when we disabled 6GHz in our WLAN configurations it may have caused a conflict with the Flexible Dual Band settings
We currently have a ticket in to rectify this as disabling 6GHz from the WLAN ssid SHOULD remove it from the options provided by the “Automatic” Flexible Dual Band.
This is just meant to be blog for me to document our transition from Cisco to Aruba, and kind of like a working notebook and place for me to think out loud.
We’ve very recently, in the span of 2 months, transitioned 80+ sites from being a Cisco/Dell network, wireless and wired respectively. 1300+ AP, and roughly 600 switches. While the transition has been done in record speed, tons of speed bumps have been hit at that same speed. From missed AP installs, misconfiguration of AP, lack of foresight on our MSPs behalf.
The first complaints we got was how poor the coverage was compared to our previous 2702i APs. That was temporarily alleviated by increasing the radio output. By default the Aruba was broadcasting at around 8-12dbm. Previously (due to poor/sparse AP coverage)our Cisco APs were broadcasting between 16-22dbm. As such, we’ve increased to match what we previously had. Over the course of the year we will be deploying another 2000+ APs to our sites with the goal of removing 2.4Ghz altogether. But as we deploy the APs per school, we can lower the minimum and maximum dbm output.