I will write it again, but I know that you will ignore it.
The latest 6.4.2.1-r1.
Mesh network, only 2 devices. Network roaming does not work when switching to a mesh-connected hotspot, although it says in the Release Notes that it works.
In 4.2.2.1-r3 no problems
I will say it again and I stick to it:
a) somehow the software is getting worse since last November!
b) you don’t test anything before putting it into production
c) there are still no test scenarios
d) on the software 4.2.2.1-r3 mesh RSSI -62 SNR 32 dbm, on the software 6.4.2.1-r1 RSSI -67 SNR -27 - what a miracle? Since the same equipment?
e) do you upload this soft as recommended with a ton of bugs as usual?
f) it is not possible to properly upgrade the system in MESH.
It is not known which side to start with, because the mesh from 4.2.2.1 does not connect to 6.4.2.1 - think that everyone will plug the devices to the switches?
Maybe your bars go up on the stock exchange, but the quality and losing customers has become your norm.
I don’t know who is writing the roadmap, but it is written for investors, not customers. But what is surprising since the main KPI on Nasdaq is the number of partners.
Hi Pshemo,
I have used your techsupport files that you have provided me previously for some mesh issue in that I don’t see 11r feature is enabled on AP profiles, used same configuration and enabled 11r in AP profiles. Roaming is working without any issue in mesh network(please refer below image for your reference)
It will be helpful if you can share us the techsupport files of the APs or remote access to your setup when the issue is seen, so that it will be helpful in debugging.
Also, if there is any issue from AP side, then we will definitely help you in solving the issue as early as possible.
I had a call with support the other day. we were talking about an issue I am having with VLANs and EPSK not working.
I reported it a few weeks ago and how to reproduce it.
I gave them support files.
I gave them access to my cloud controller.
“We can’t find it on our end.”
During a screen share, conference call, and allowing direct access to the Radio via WEB and SSH… I showed them and reproduced the problem repeatedly.
Someone on the call recommended turning off some setting. I wasn’t sure who said it. Or exactly what he said. @GaryHans disabled it on my radio via SSH and VIOLA… problem vanished.
There was some back and forth about how the test engineer “ALWAYS HAS THAT SETTING TURNED OFF”.
There was some more back and forth about how “IF THATS THE DEFAULT SETTING THAT A CUSTOMER CAN’T SEE… WHY ARE YOU TESTING WITH IT OFF???”
Turned setting back on. Issue returned. Gary turned it off on my AP to leave me in a “Useable state.”
I was pretty disappointed when I got off the phone. I was assured that they would “get back to me soon”.
But it just really drove home the point…
Don’t bother with sending files. Don’t bother with writing detailed explanations. Make them remote access it and SHOW THEM THE PROBLEM IN LIVE TIME. Otherwise bugs will stay in the system for years at a time.
And yes… after 7+ months of having my NFR gear… I have yet to make a DOLLAR OFF CAMBIUM. But I sure spend a lot of time bug hunting FOR THEM.
Maybe slightly off-topic, but I’ve got an interest in playing with ePSK, so I would be interested to know what particular setting you/they are talking about…
I use EPSK on my bars and restaurants Staff network.
Waiters, and cooks are standard password, and blocked from everything.
Managers get on the same SSID with an EPSK. That changes their VLAN tag. Allowing them to talk to everything in the building. And jump subnets to reach the point of sales.
Example:
Staff = VLAN 69
Manager = VLAN 10
Fire a manager, and you delete his key. Don’t have to run around changing passwords on everything else. Or worry about managers handing out their passwords.
Well… I do this in DPSK with Ruckus. My plan is to do the Same Thing in Cambium, with EPSK.
The EPSK devices got an IP from the right DHCP. But they have limited connectivity and drop on and off. Ruining calls and making some pages not load in browsers… Amongst other things.
Yes, I get the concept. My question was what setting did your Cambium contact need to disable in order to work around the problem(s) you were experiencing with EPSK?
Why is this version still as recommended when it has so many problems?
You can’t really leave 4.2.3?
Clients say that it shows them that they have old software.
For now, I tell them that I am testing it, but someday I will have to say that the new one is so broken that we stay with the old one shining yellow
Curious what exactly is showing your clients that they are running “old” software? Are you giving them access to Cambium’s cnMaestro in the cloud?
Fortunately, we run our own cnMaestro on-premises with MSP enabled, and then give our clients access to that. Then we can control what firmware versions are showing as recommended & available for upgrade.
The point / suggestion is, you host your own cnMaestro on a public server that you control. (It’s called “on-premises”, but you can run it wherever you want. It doesn’t HAVE to be LITERALLY on the premises!)
On cnMaestro “on-premises”, only the firmware images that you upload to your instance of cnMaestro will show up as options for upgrades. And you can even pick WHICH version you want as the “recommended” one! Even if it is “old”!
@PFR here is example. Note how 4.2.2.1-r3 is CLEARLY marked as “recommended” EVEN THOUGH “newer” version (strictly considered by version #) of 6.4.2.1-r1 is available on the server. Because I can select whichever version I WANT to be “recommended”.
Thank you very much for making me aware of cnmaestro.
I know which version is for what and I still don’t see any point in putting on-premiss since I have a free cloud.
So what if the marking is 4.2.2.1 as recommended, since it shows devices with this version of the software as “below recommended”. The mess in the cloud cnMaestro continues.
Apparently it does this only if you use the cloud version. Which is what I have been trying to explain to you.
With on-premises version, it honors whatever version you select as “recommended”. And even if there is “newer” version, it will not “recommend” it. (And if it did, it wouldn’t matter anyway, since you could simply delete the 6.x version from your on-premises Maestro server. Then Maestro would not even be aware that 6.x firmware existed.)
Tell me, what are you trying to prove to me? Indicates that there is still an error in cnMaestro cloud, and you are writing to me about the installation outside the cloud. It not interests me.
You complained that “clients say that it shows them that they have old software”.
I was telling you one strategy to avoid that problem. With cnMaestro instance under your control, your clients won’t be told they are running “old software” when you keep them on the more stable 4.2.3.
If you aren’t interested? Then sorry I wasted my time trying to help you.
