這是一個救火的案子，前陣子釋出個資安漏洞消息，如果要解決漏洞，需要將控制器版本升至8.10.0.5以上，而我那漏洞消息公佈的前一陣子，也做了不少升級到8.10.0.5版本，所以漏洞發佈後，我其實沒做升級的。
那陣子，也不少把控制器升級到8.10.0.6版本，不過都沒有發生啥異常。如果說升級就會導致某型號完全不能用，那肯定是個大事件，OS發表前早就該被測出了，發表後公測也早該被測出了，畢竟8.10.0.6發佈到這次客戶升級控制器也過了快一個月，因此我推測是個案，但也無法驗證是不是通例。
基於救火，就教客戶重置AP，再從IAP網頁管理介面去轉換。原負責同事是這麼想得，但是失敗了。
跳出錯誤訊息「圖像驗證失敗…」，我就知道是使用機器中翻英，原本英文詞是「image」，也就是我們常說的韌體。
從log可以看出來，從客戶的Aruba7205 8.10.0.6版本下載的OS，是無法通過驗證的。要怎麽知道檔案有沒有被篡改？有些下載網站會提供檔案的HASH值，像是以SHA去HASH整個檔案得出來的值，只要檔案被改一個bit，產出的HASH值就完全不同，只要將下載來的檔案比對網站上提供的HASH值，若一樣就代表可信任，如果不一樣就要當心了！
因此，我覺得問題是出在控制器的apimages中。
身為Aruba 4個P的我，因此又更深掘那些電子書跟討論都不會寫的基礎運作。
如果AP要被納管的話，AP使用的image是從控制器身上下載的。而且「檢查版本，下載iamge」這個步驟是AP被納管過程中第一次重開機部分，也就是最優先檢查的部分。如果AP的OS跟控制器的OS版本不一致，AP就會從控制器上下載OS，如此一來達到AP會主動跟控制器版本對齊。
AP在同版本不同型號的控制器上切換，是不需要重新下載OS的。實測也證實，AP沒有再重新下載OS。
藉此，我去比較客戶的Aruba7205跟其他的VMC或是70xx系列的AP image，發現客戶出問題的apimage跟VMC與70xx系列同AP型號的apimage是不同大小的，而VMC與70xx系列的apimage是相同大小的，所以是客戶控制器中的apimage有問題，這也跟AP的Log對得上。如果是實體控制器，可使用「dir flash」去檢查apimages內的檔案大小。
解決狀況遠比找出造成狀況的原因還重要。
接下來就要知道，到底AP去檢查跟控制器版本時，條件是以檢查apimage檔案大小一致？還是檢查版本訊息一致？
「我只是想知道解決方法可不可行。」我拿到一顆504測試，因為都是用同樣的image所以可以替代。
答案是，檢查版本訊息一致即可。
所以幫AP刷正常的韌體，就能讓AP正常被客戶的控制器納管。然而幫AP刷IAP韌體是新手境界，而刷成Thin AP韌體就是高手境界，想刷，要先有個Thin AP的韌體，這沒有放在ASP可供下載呢。
想想之後，我覺得大概只有我出馬才能解決了。
在公司使用AP-504測試可以過，方法就是讓AP先刷到正常的AOS 8.10.0.6，接著再去跟客戶的控制器報到，避免AP更新錯誤的image，避免image檢驗失敗而失聯。
到客戶端，很快，我就讓五顆505，能被控制器控管，提供正常穩定的無線服務。然後發現565也是同樣的image，只是這一段就快不起了😂。