I have had three truck rolls for 3 separate SMs since upgrading my entire epmp network to 3.4.1. The symptom has been the same for each incident. Each affected SM fails to connect after scanning for an AP - it finds the AP but underreports/miscalculates the RSSI at startup and then it gives up. Across the board, I have configured all SMs to have a Network Entry RSSI Threshold of -84. For today's latest incident, I went to the customer's location to find the RSSI was reported as -86, but this customer has been solidly online for 2 years at a -72 with perfect LOS to the tower 4.5 miles away. The other two incidents were similar, although they failed to reconnect to the AP immediately following the upgrade to 3.4.1 about two weeks ago. This 3rd incident today happened a couple weeks into running 3.4.1 after the customer power cycled the SM. As a temporary workaround, I bump the Network Entry RSSI Threshold to -90, and then the SMs will connect and calculate and report the expected RSSI. I'm worried that my other SMs will start to fall offline if I don't bump the Network Entry RSSI Threshold across the board.
As a troubleshooting approach, I tried upgrading this SM today to 3.5 before bumping the threshold as I normally would. The SM still reported the -86 and would not connect after booting up with 3.5 firmware. I snapped a picture before and after the 3.5 upgrade and the -90 threshold bump. It is worth noting that the incidents have been spread across 2 APs that are back-to-back on the same tower. 1 SM on the "front" AP, and 2SMs on the "back" AP. I have been running a CMM4 with this GPS sync setup for almost three years without any problems - 10 Mhz channel widths with frequency reuse.
Could there have been a change with how the RSSI is calculated in the firmware at startup?
- RSSI-before.png (459 KB)
- RSSI-After.png (1.05 MB)
