You said: "You should not put such release on public download and upgrade sections until…"
For what it’s worth, I don’t agree. This software was developed and tested in the private beta group with lots of early private beta revisions, and then also tested through release candidates in the public beta group. Regardless of how much testing in a small group, there will always something that goes undetected until a wider release is done.
I’m sure Cambium wants to be as sure as possible, but that has to be ‘reasonably’ sure. Telling them not to release new firmwares unless they are 100% certain… would mean no new firmware ever.
4 Likes
Hello Fedor and Cambium Support Team
When is expected the resolution of the QOS feature in the ePMP3000 ?
This is really delaying our Deployment Plan ..thanks
there is no smart antenna support? Is it planed?
@David_8 wrote:
there is no smart antenna support? Is it planed?
Yes. Firmware supporting Uplink BSA (Smart Antenna) should come out sometime early June.
1 Like
@leocallec wrote:
Hello Fedor and Cambium Support Team
When is expected the resolution of the QOS feature in the ePMP3000 ?
This is really delaying our Deployment Plan ..thanks
Hi,
We are working righ now to deliver it as quickly as possible.
QoS for PTP solutions is scheduled to be introduced in 4.4 FW.
And QoS for ePMP3000 is scheduled to 4.5.
Thank you.
1 Like
@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.
Hi Richard,
We are unable to reproduce the issue in the Lab.
Could you please let us know if the issue still persists for you?
Thank you.
Dear colleague,
I think you know what I am saying. Only death is 100% guaranteed sou you should not take my sentence for granted.
What I am saying is that this firmware ver. 4.3.2 is as buggy as any other beta firmwares from past months. We don't see any bigger improvements from that period of use, no hard feelings. ;-)
Some of us make mistake of any upgrade immediately after releasing new version hoping to be something more stable, better and so on. Obviously, this is wrong way. I hope some of next releases will be better than this one.
@Fedor wrote:
@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.
Hi Richard,
We are unable to reproduce the issue in the Lab.
Could you please let us know if the issue still persists for you?
Thank you.
Fedor,
Well....., I was able to reach all SM's on this sector from behind my SM which is also on this sector 5 minutes ago. I -just- rebooted AP and can not reach my SM's GUI or any other SM's GUI on this sector. I can ping all SM's on the sector, but can not pull up the GUI. I -can- pull up the AP's GUI. Basically I am right back where I was when I upgraded from 4.3.1-RC21 to 4.3.2 last weekend. We have 7 other sectors (1000's and 2000's ) on this tower with management and data vlans set up the exact same way, and -none- of them display this issue. Using Tik router and Netonix switch. None of our 1000/2000 AP's on other towers display this issue either.
I tried with 3 different browsers (chrome, FF, and IE) on 2 pc's, and with 2 phones and 1 tablet. Same issue on all.
I do notice a descrepancy. In all of our 1000/2000 AP's, the Monitor-Network-Bridge Table shows MAC addresses in the "Subrscriber Module MAC" column. The 3000 AP does not. It shows N/A in every block in that column.
Check to make sure you have management access on the ap set to ethernet and wireless. Also check to see if cpe isolation is off and try that.
@accelwireless wrote:
Check to make sure you have management access on the ap set to ethernet and wireless. Also check to see if cpe isolation is off and try that.
When we had the same problem with 4.x.x. It made no difference (I tried it). 4.3.1-RC21 fixed things so I had not thought about it again.
I just changed mgmnt access to eth and wireless and cpe isolation was already set to off. Still no access. Rebooted AP to clear things out and possibly force changes, still no access to any SM when attempting to access SM's while behind one of the AP's SM's. Back to the drawing board.
> 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.
Would we have a bandwidth increase?
What percentage?
How does this new mechanism work on a practical level?
@CWB wrote:
@Fedor wrote:
@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.
Hi Richard,
We are unable to reproduce the issue in the Lab.
Could you please let us know if the issue still persists for you?
Thank you.
Fedor,
Well....., I was able to reach all SM's on this sector from behind my SM which is also on this sector 5 minutes ago. I -just- rebooted AP and can not reach my SM's GUI or any other SM's GUI on this sector. I can ping all SM's on the sector, but can not pull up the GUI. I -can- pull up the AP's GUI. Basically I am right back where I was when I upgraded from 4.3.1-RC21 to 4.3.2 last weekend. We have 7 other sectors (1000's and 2000's ) on this tower with management and data vlans set up the exact same way, and -none- of them display this issue. Using Tik router and Netonix switch. None of our 1000/2000 AP's on other towers display this issue either.
I tried with 3 different browsers (chrome, FF, and IE) on 2 pc's, and with 2 phones and 1 tablet. Same issue on all.
I do notice a descrepancy. In all of our 1000/2000 AP's, the Monitor-Network-Bridge Table shows MAC addresses in the "Subrscriber Module MAC" column. The 3000 AP does not. It shows N/A in every block in that column.
Ok, so today I was once again able to access the GUI's of SM's while behind one of the SMs. I then logged into the Monitor-Network-ARP and Bridge Tables and found some unexpected results. Some SM's would show it's own address in bridge table but not the SOHO router. Others would show the SOHO router but not it's own address. Some displayed everything properly.
I rebooted each SM and all their tables displayed the proper and expected information in the proper places. Everything looked good. I then rebooted AP, and sure enough, SM's could no longer be accessed. Could ping them, but not GUI access.
A pc was connected directly to the SM, and it drew a dhcp address from the data vlan. I was, but should have not been able to, reach the GUI of that SM using 169.254.1.1 -without- configuring the lan card of the pc for the 169.254 subnet. We can not reach the GUI of our N radios that are pulling a dhcp address from the data vlan using 169.254.1.1 without having our devices (pc's, tablets, etc) set for a static 169.254.x.x address. At least we have not been able to in the past. I do not think we have tried for quite some time.
Next, I made some calls and asked customers to unplug their power bricks from the AC power to kill their SM's leaving only my SM active on that AP. I then changed the data vlan in my SM to a data vlan that has been in use since this tower was erected 2 years ago and has always worked perfectly. I still could not reach the GUI of my SM using the management address. I then typed in the management address of the very first customer on this AP/vlan and it pulled right up. I was able to log in and pull up any page I wanted in his GUI. His unit is a force 200 connected to a 2.4ghz ePMP 1000gps AP. I was able to do the same with 2 other customers on this vlan/AP.
While still using the dhcp address issued from another AP/vlan, I then rebooted the 3000 AP and my SM, still no go getting into my SM with the management address. I then called one of the customers and asked them to plug their power brick back into their AC power. I tried to access their GUI using it's management address once they connected back to the AP, once again no go. I finally configured SM back to the original vlan for this AP and still no access to SM GUI.
I just can not see this being a network issue on my end. This has to be some kind of bug in the 3000 platform, and it seems to be at the AP. When all is working, it dies as soon as AP is rebooted. A few days later, all it is back working. Reboot AP and repeat wait time. Plus, the rest of my network works as expected to work 100% of the time.
Richard,
Sending the letter to you.
I woukd be grateful if you could provide configuration files.
Thank you.
@Fedor wrote:
Richard,
Sending the letter to you.
I woukd be grateful if you could provide configuration files.
Thank you.
Just received the email via my phone. Will get you the config files you have requested and any other config information you may need...router, switch, etc. Thanks Fedor
@CWB wrote:
@Fedor wrote:
Richard,
Sending the letter to you.
I woukd be grateful if you could provide configuration files.
Thank you.Just received the email via my phone. Will get you the config files you have requested and any other config information you may need...router, switch, etc. Thanks Fedor
And....for fun, I just attempted to log into SM's. As suspected, I can log into them now. There seems to be a 36-48 hour delay from rebooting AP until I can reach SM's again. AP has been up 2days, 0 hours, and 41 minutes since last reboot. I can log into every SM on this AP. Very strange.
For anyone who may experience the same issue/s, Fedor and Andrii worked with me to fix my problems. Andrii had me enter some lines via CLI, and everything is working as expected now. Thanks guys!!!!
1 Like
We are testing one 3000 sector and a lot of my epmp N are randomly disconnecting
SM disassociated from AP[00:04:56:] F=5835 11naht20. Reason: 33 (GPFs MISS)
Once again this is a known issue they are working on please read other posts.
@jlkz wrote:
We are testing one 3000 sector and a lot of my epmp N are randomly disconnecting
SM disassociated from AP[00:04:56:] F=5835 11naht20. Reason: 33 (GPFs MISS)
Hi,
We are working now on the issue with the highest priority to address it asap.
Thnak you.
1 Like
@Mirko wrote:
> 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.
Would we have a bandwidth increase?
What percentage?
How does this new mechanism work on a practical level?
Hi Mirko,
New coding gives ~+3 dB Sensitivity, and Short Guard Interval gives ~+10% Throughput increase.
Please find test results attached.
Thnak you.