原始引用地址: 記錄一個海思TOE的BUG
time: 2020.5.3 17:57
發現的過程
最近在做onvif開發時，有x86的驗證的功能沒有問題，移動到海思Hi3536上簡單運行貌視也很正常。但是多次測試後，發現有時在接收一些onvif數據時，不能正常接收，直到超時。一些雜牌的相機頻繁出問題，海康大華的幾乎不出問題，很是奇怪。
分析測試
- 同樣的程序，在x86上正常，arm版很容易復現問題
- 通過在交換機上通過tcpdump抓包，發現攝像頭已把所有數據返回；但是調試arm程序程序發現，arm程序只能接收一個mtu長度的數據（就是第一包數據），後續數據一直是阻塞等待，直到超時也沒有接收到。
- 測試時發現確實是海康的幾乎不復現此問題，抓包時發現海康的數據包明顯比較出問題的數據少。
- 經過比較長時間的苦惱的debug，，，，，，沒有一點頭緒！數據到了網卡，但是程序中接口沒有接收到tcp數據。突然想到了海思裏面有個TOE的功能，如果開啓與正常的編程有些區別。於是查看了手冊等相關文檔，好像關係不大。於是禁用TOE功能，很神奇，在海思上測試好多次，與X86相同，沒有復現問題。
經過上面的分析測試，確認是TOE的問題。但是怎麼解決問題？難道是gsoap的問題，因爲出問題的地方是gsoap生成代碼！！！試了另外的老的版本，新的版本，，問題依舊！！！！google各種錯誤信息，無解。
又是一個較長時間的苦惱的debug，，，，，，
分析下問題的原因好像與數據包的長度有關。短的數據不易出問題，長的數據容易出問題。再看下gsoap生成的代碼，緩衝buf是64k，這個64k與TOE中默認的相同！
估計就是TOE一個攢的着數據，直到足夠大才往上返回！！但是onvif的數據一個沒有到足夠大的條件。所以直到數據超時了，數據也沒返回來。
好吧過程就不多說了，我現在也忘的差不多了。直接說結果吧
結論
如果想讓ONVIF的SOAP接口在TOE狀態下正常使用，應該把onvif/stdsoap2.h 中SOAP_BUFLEN（默認爲65536， 也就是64k）改爲一個比較小的值，我改爲20*1024，多次測試後認爲問題解決。