原始引用地址: 記錄一個海思TOE的BUG
time: 2020.5.3 17:57

發(fā)現(xiàn)的過程

? 最近在做onvif開發(fā)時，有x86的驗證的功能沒有問題，移動到海思Hi3536上簡單運行貌視也很正常。但是多次測試后，發(fā)現(xiàn)有時在接收一些onvif數(shù)據(jù)時，不能正常接收，直到超時。一些雜牌的相機頻繁出問題，海康大華的幾乎不出問題，很是奇怪。

分析測試

同樣的程序，在x86上正常，arm版很容易復現(xiàn)問題

通過在交換機上通過tcpdump抓包，發(fā)現(xiàn)攝像頭已把所有數(shù)據(jù)返回；但是調(diào)試arm程序程序發(fā)現(xiàn)，arm程序只能接收一個mtu長度的數(shù)據(jù)（就是第一包數(shù)據(jù)），后續(xù)數(shù)據(jù)一直是阻塞等待，直到超時也沒有接收到。

測試時發(fā)現(xiàn)確實是海康的幾乎不復現(xiàn)此問題，抓包時發(fā)現(xiàn)海康的數(shù)據(jù)包明顯比較出問題的數(shù)據(jù)少。

經(jīng)過比較長時間的苦惱的debug，，，，，，沒有一點頭緒！數(shù)據(jù)到了網(wǎng)卡，但是程序中接口沒有接收到tcp數(shù)據(jù)。突然想到了海思里面有個TOE的功能，如果開啟與正常的編程有些區(qū)別。于是查看了手冊等相關文檔，好像關系不大。于是禁用TOE功能，很神奇，在海思上測試好多次，與X86相同，沒有復現(xiàn)問題。

經(jīng)過上面的分析測試，確認是TOE的問題。但是怎么解決問題？難道是gsoap的問題，因為出問題的地方是gsoap生成代碼！！！試了另外的老的版本，新的版本，，問題依舊！！！！google各種錯誤信息，無解。

又是一個較長時間的苦惱的debug，，，，，，

分析下問題的原因好像與數(shù)據(jù)包的長度有關。短的數(shù)據(jù)不易出問題，長的數(shù)據(jù)容易出問題。再看下gsoap生成的代碼，緩沖buf是64k，這個64k與TOE中默認的相同！

估計就是TOE一個攢的著數(shù)據(jù)，直到足夠大才往上返回！！但是onvif的數(shù)據(jù)一個沒有到足夠大的條件。所以直到數(shù)據(jù)超時了，數(shù)據(jù)也沒返回來。

好吧過程就不多說了，我現(xiàn)在也忘的差不多了。直接說結(jié)果吧

結(jié)論

如果想讓ONVIF的SOAP接口在TOE狀態(tài)下正常使用，應該把onvif/stdsoap2.h 中SOAP_BUFLEN（默認為65536， 也就是64k）改為一個比較小的值，我改為20*1024，多次測試后認為問題解決。

首頁

總結(jié)

以上是生活随笔為你收集整理的记录一个海思TOE的BUG的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。