10-23-2017 01:52 AM - edited 03-20-2019 09:38 PM
Why has the bug CSCvf47808 been replaced by CSCvg42682?
For CSCvf47808 there was already a fix in 8.3.130.0 and for CSCvg10793 there was a fix in 8.3.131.0. But now there is a 8.3.132.0 that fixes CSCvg42682. Why did something had to be fixed twice?
10-30-2017 07:38 AM
10-31-2017 12:16 PM
11-01-2017 12:55 AM
Yes and CSCvg42682 should have been fixed by 8.3.132.0, but TAC has issued a warning not to install it, because the controller might crash. So, there are two releases that don't fix the problem completely and one that has another bug, but now there is 8.3.133.0. Would you rely on it?
11-01-2017 07:23 AM
Yes I would. But I don't know your environment, so why does it matter if I do? Read through the release notes and bugs and make the decision.
11-01-2017 07:34 AM
You are missing the point here. We have a customer who was at the point of installing 8.3.131.0 after we/he noticed that 8.3.130.0 didn't fix the problem for his 2802 AP's. Then we had to tell him it was better to go for 8.3.132.0. The upgrade is planned, but now we have to say NO don't do that. There is a new bug and install 8.3.133.0. What do you think is going through this customer's mind? I'm out of answers if this customer asks me: Are you sure about this upgrade?
11-02-2017 01:12 PM
I wouldn't say that I'm missing the point. While it is unfortunate that the version they were planning to upgrade to didn't fully resolve the issue, code upgrades are and will always be part of maintaining a system such as this. This isn't the last oil change. It sounds like Cisco realized and announced the issue with that version of code pretty quickly. It seems it may even have been in time to ensure that you still only have to do a single downtime to upgrade the code. But a month from now, when the next researcher discovers an issue with the WLC or there is another bug is OpenSSH or OpenSSL which will require a code upgrade, you'll have to go through this process again.
We as engineers/admins are limited to the information that is provided to us from the vendor. It sucks at times, but in this case, I think Cisco identified and communicated the issue with the 8.3 train fairly quickly. The initial public report about the KRACK issue came from Cisco on 10/16. "Fixed" code was made available about a week later. We are currently about 2 1/2 weeks post vulnerability announcement, and they have made fixed versions available for almost every code base (8.6 still didn't have one that I could find).
I can appreciate you have concerns about how this is perceived by the customer, but it's not like you had better information at the time and provided them bad information. Also, keep in mind, there are 10 parts to the KRACK vulnerability, and 9 of them are client side. Microsoft already patched the windows side stuff in the October updates before the issue was made public. There is a reason that it has been assigned a Cisco assigned it a base CVSS of 4.3.
KRACK is high profile and a concern, but depending on your environment, doesn't need immediate remediation. Arguably it could wait until a regular maintenance window/upgrade cycle.
There is no guarantee with any upgrade. Look at the release notes for ANY software. The only thing you can do is validate the source of the information as much as possible, do some research, read the release notes, evaluate the issue, make a decision, test it if possible, and have a backup.
Good luck whatever you decide.
11-03-2017 01:24 AM
As a closing thought. Aruba had the software updates online on the same Monday of the vulnerability announcement. As did Cisco Meraki.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide