Please make sure to refer to the release notes and the appropriate packages. AC products should have .img as an extension while 11n tar.gz.
ok Thanks the .img loaded.
I can see the change in software is up to date. However, I still cannot manage the
broadband profiles using Radius. Is there a fix for that?
Dave
@dcshobby wrote:
This is even with 1k and 2k ap's that we'll see some improvement? I'm talking about complete N based AP and Sm's.
Then no... I'd avoid using 4.3.2 with a strictly N system. You'll lose QoS on all your radios and IIRC you'll lose support for the BSA on the 2000.
1 Like
@David Bukowski wrote:ok Thanks the .img loaded.
I can see the change in software is up to date. However, I still cannot manage the
broadband profiles using Radius. Is there a fix for that?
Dave
There's no QoS in the 4.X firmware line yet. If you need QoS, you'll have to stay with 3.5.6 for now.
We are using Radius, so there are no QoS settings used.
@Brad-A wrote:Why is there no Total Frame Time Used metric on the 3000 AP like there is on the 2000 AP in 4.3.2?
It was not working properly, so it was disabled temporarily on the UI. In the next firmware, it will be fixed and working.
Is there a timeline for when QoS will be added? This is holding us up from large scale roll out.
@Ben Backus wrote:Is there a timeline for when QoS will be added? This is holding us up from large scale roll out.
We've been told sometime this coming May.
MAJOR ISSUE
I do not know if anyone else has had this issue. We started rolling 4.3.2 through CNMaestro, however within an hour of rolling it out we started having ePMP1000 2ghz APs dead end dropping all SMs and no one ever re-registering until rebooted. However it will do it again 20m-3h later. I finally started rolling 2g APs back to 3.5.6.
1 Like
@Skullzaflare wrote:MAJOR ISSUE
I do not know if anyone else has had this issue. We started rolling 4.3.2 through CNMaestro, however within an hour of rolling it out we started having ePMP1000 2ghz APs dead end dropping all SMs and no one ever re-registering until rebooted. However it will do it again 20m-3h later. I finally started rolling 2g APs back to 3.5.6.
Why are you using the 4.3.2 firmware build on 2.4 ePMP? That's a bad idea IMHO.
Why am i using epmp1000 2g/5g firmware on a 2g radio that is it partly made for?
The firmware does not say it is only for 5g, and CNMaestro didnt say DO NOT USE on 2g?
I have a network consultant here that needs radios updated relating to passing vlan data, said update to the latest. Well he didnt know 4.3.2 was just released.
If you look at cnMaestro cloud, it actually says that 3.5.6 is the 'Recommended' release for ePMP. Again, don't use 4.3.2 on your 2.4 gear or strictly N 5GHz systems. Only use 4.3.2 if you're trying to do backwards or forwards compatibility between legacy N and AC series. There's a bunch of features missing in 4.3.2 that a lot of people need/use on legacy equipment that it doesn't have yet.
I think cambium needs to be clear on what version they recommend for 1k/2k gear if we don’t have any 3k.
I’m still curious if we see any RF performance improvements with an all N based network going to 4.3.2 or not?
Can a cambium employee clarify please? If they don’t recommend going to 4.3.2 except in the case of 3k or force 300, they should really specify that in writing somewhere on the download site or release notes.
Thank you
2 Likes
@dcshobby wrote:
I think cambium needs to be clear on what version they recommend for 1k/2k gear if we don't have any 3k.
I'm still curious if we see any RF performance improvements with an all N based network going to 4.3.2 or not?
Can a cambium employee clarify please? If they don't recommend going to 4.3.2 except in the case of 3k or force 300, they should really specify that in writing somewhere on the download site or release notes.
Thank you
Darin,
QOS/MIR are one key feature that is not supported on e3K just yet. Given that, we are now recommending that 4.3.2 is used in mixed backwards/forwards compatibility networks only. For pure legacy networks please continue to use 3.5.6 release.
Once the feature set is caught up, a pure 11n network will see some improvements in performance due to tweaks around guard interval and new coding rate support.
3 Likes
Before I complain, let me say I do like some things with this update. We see more real world upload speeds compared to 4.3.1-RC21 that we were previously using. Also like the the throughput graph.
But...we are having management vlan problems....-again-...with 4.3.2 with the 3000/300 radios.
We had this same problem a few updates back and 4.3.1-RC21 fixed it.
We -do not have- this problem with ANY of our 11n radios configured the same way.
We use management and data vlans. With 4.3.2 if we have a managment vlan turned on in the SM's, we can not access the GUI of that SM using the managment vlan address while we are behind the SM. We can only access GUI using 169.254.1.1. If we disable the managment vlan in the SM/SM's all is good.
A little flow chart may help better explain. SM's are in bridge mode.
Tablet/phone/pc (pulling data vlan dhcp address) > SM (with mgmnt vlan) > AP; SM can not be reached using management vlan (can ping SM management IP, but can not connect to GUI )
Tablet/phone/pc (pulling data vlan dhcp address) > SM (without mgmnt vlan) > AP; SM GUI can be accessed using data or native vlan dhcp issued to SM.
Ok, so this is extremely weird. We can now access the GUI of SM's from behind the SM while a management vlan is active in SM. Software was upgraded Sunday and we have had this issue until today. Not sure when this changed today, as we have been out working all day, but it is working properly now.
There has been absolutely -no- changes to anything in our network. I know this because either I make changes, or the network engineer we have contracted with makes changes. Neither of us has made any changes to the network today.
When we had this issue with previous software versions, the issue did not go away until we upgraded to 4.3.1-RC21.
The way I know it is working is because I have a 300 SM at my home. I just came in working, hit refresh for the SM GUI management address, and it loaded this time and allowed me to log into the SM. The GUIl has not loaded while behind a management vlan since I updated the software Sunday.
We have never had this issue with any of our N radios.
@CWB wrote:
Ok, so this is extremely weird. We can now access the GUI of SM's from behind the SM while a management vlan is active in SM. Software was upgraded Sunday and we have had this issue until today. Not sure when this changed today, as we have been out working all day, but it is working properly now.
There has been absolutely -no- changes to anything in our network. I know this because either I make changes, or the network engineer we have contracted with makes changes. Neither of us has made any changes to the network today.
When we had this issue with previous software versions, the issue did not go away until we upgraded to 4.3.1-RC21.
The way I know it is working is because I have a 300 SM at my home. I just came in working, hit refresh for the SM GUI management address, and it loaded this time and allowed me to log into the SM. The GUIl has not loaded while behind a management vlan since I updated the software Sunday.
We have never had this issue with any of our N radios.
We will reproduce this in our lab based on your feedback and see if we can root cause the issue and fix it.
1 Like
@Sakid Ahmed wrote:We will reproduce this in our lab based on your feedback and see if we can root cause the issue and fix it.
Thanks Sakid. The first time I had this issue was with the PTP550. I opened ticket 175330. We also had some DNS issues. Andril helped me with the management vlan and DNS issues with modified software.
Then, You should not put such release on public download and upgrade sections until you do your job done. This is not serious at all. You produced the buggiest firmware on public download as final and stable. Too many people have a lot of different problems and the only thing we hear from you is "this WILL BE done during this month". If you are unable to produce stable and reliable version, you might consider to note that precisely and clearly in your download section because some of us are not your beta testers of the firmwares you publish but serious WISPs who need to have extremely stable and reliable service.
This is not right at all.
1 Like
I'd like to point out that we did an upgrade of approx 500 radios all Force 200, 180, and all sorts of ubiquiti elevated and other than some ubnt radios dying we haven't seen any issue. We don't use QoS. We use data vlans and management vlans. So I'm not sure if these issues you're seeing are widespread. Just to put in some context.
3 Likes