Been running 20.0.1 for several weeks now with no issues and then inexplicably about 30 minutes ago we lost connectivity to all the SMs on one of the AP’s simultaneously. The AP still showed the SMs as registered in the link status but we were unable to access them via proxy or direct IP… Rebooted the AP and everything reconnected. I’ll be opening a ticket and will try to capture the engineering file if it occurs again. Once I figure out how to do that on a 450, LOL.
1 Like
@Riverrat Have this same issue.
Please get 169.254.1.1/engineering.cgi and 169.254.1.1/field_diags.cgi
Grab this from a few SM’s and then from the AP and send it all off in a zip file, I’m sure they’ll find it.
1 Like
@Riverrat and @Ryan_Ray thanks for posting. Sorry for the slow reply, but we have confirmed an issue on 20.0.1 where the Broadcast Data Channel stops getting scheduled for transmissions on 450/450i/MicroPoP APs. We are working on the fix now and will report back soon. The fix is targeted to release 20.1.
1 Like
Thanks Charlie, sorry I couldn’t help more but it was a pretty impacting problem and couldn’t have it on the network at this time, will definitely be getting on 20.1 though.
ETA on that? Another month? We’ve been seeing good results from the expanded modulation levels so we’re itching to get this onto our legacy 2.4 gear.
So we haven’t noticed this issue, but then again, we have broadcast repeat count set to zero on every AP. Maybe you could try this out and see if it works for you?
Checked one of the AP’s that was having the issue and “Broadcast Downlink CIR :” is set to 200kbps. Reading online it doesn’t seem to be useful so I’m willing to try putting this back to 0 and giving it a try.
@Charlie any negative things you can think with this plan?
We have the broadcast MIR set to 0 as well… but I think the main thing you need to disable is the broadcast repeat count under the radio tab. Set that to 0.
Understood. Will do both, you seem to have been using this config since 2017 and if you haven’t seen anything negative it’s probably time for a change.
There’s a chance that setting Broadcast Repeat Count to zero could have this happen less often. But not sure that the chance is zero. So I’d say just wait till 20.1 BETA load comes out and I’d love some feedback and verification of the fix. That beta load should be available soon.
I don’t like to give dates on releases, because I never know what issue we’ll find next and how long it will take to solve. 
But after saying that, the current plan of record is to have 20.1 in the next month or so. We do have a few other bug fixes we want to get in as well, but this is a big one.
2 Likes
Oh and regarding Broadcast CIR set to 200 kbps: I don’t think will cause the issue more or less, but I’d have to think about that.
In general, Broadcast traffic is scheduled at the absolute lowest priority, so if there’s no CIR scheduled, it will only go out if there is room in the frame. Generally this 200 kbps is very little Broadcast isn’t a load on the RF, and the rest of the Broadcast will be sent if/when there is room. Again all this only matters if the Frame is full with traffic, so busy hours. If you don’t mind all your Broadcast going out dead last priority, then setting to zero CIR is perfectly fine.
Hi,
we had the same issue:
SM with 20.0.1, AP 450/450i with 20.0.1 after some time (hours? days?) SM’S stop to respond either to vlan mgmt IP or via proxy. Only for NATted SM’s.
We have Broadcast Repeat Count se to zero, but didn’t help.
Hi Charlie, I think this is a serious issue (we already rolled back to 16.2.3) and a 20.0.1.1 is needed ASAP, thank you.
So yeah those changes didn’t work. Upgraded a couple 2.4 AP’s with everything at 0 and Traffic is halted until AP is rebooted twice so far today.
You can check Ticket 246711 for updated captures. Maybe it’s not the same issue.
Thanks for confirming Broadcast Repeat Count of zero doesn’t stop the issue. Agreed very important to fix and we are working on it. When we have a fix available, I’d love verification with a beta load.
In the meantime, on 20.0.1 if you see your Frame Utilization Broadcast count go to zero, then have to reboot the AP. 
@Ryan_Ray Thanks for opening the ticket with the captures. (I don’t have permissions to mail you through the ticket.) I looked at the AP’s log and yes this is the same issue where the Broadcast stops getting transmitted. You can see over last 15 minutes the Broadcast count is zero. Fix coming ASAP.
I appreciate you guys helping us through this.
FYI I would recommend 16.2.3.1 over 16.2.3.
1 Like
Hi Charlie,
any news on this? Thank you.
We are delayed a bit as we found a few issues:
- Broadcast VC stops getting scheduled
- 450 AP and SM memory controller fix
- Proportional Scheduler was broken in R20 on 450/450i/MicroPoP.
- IPv6 Memory Leak
So we held up beta for these fixes so as not to post too many beta loads. We now have them fixed and I expect a open beta next week (unless we find more to fix urgently in the meantime). I would appreciate trying that out when it available.
The current release target is March for 20.1.
@MW_WISP, not much more to share. We found a small issue with the memory controller that runs on the 450 that has been there for many releases that could lead to random issues on the 450 AP and 450 SM. One way this manifested was the Web Auto Refresh stopped working until next reboot.
Once 20.1 is out, I recommend upgrading to this release to get this fix.