Wireshark看到Ethernet frame check sequence incorrect??

wangcm
個人積分：1626分
文章編號：67584079

1626分

樓主

2018-02-28 20:57

鵝有user反映mail server連不到後端的Exchange,連過去一看小封包是Ok的,但大封包會看到一坨Ethernet frame check sequence incorrect(L2都過不了,那L3/L4不work也是天經地義的

)....

Wireshark看到Ethernet frame check sequence incorrect??

鵝直覺的反應是把NIC(BCM5719)的offloading關掉,關掉後狀況的確是消失了(未使用到的bge1 RXCSUM/TXCSUM/TSO4 default是on的,bge0的RXCSUM/TXCSUM/TSO4是被鵝關掉的)....
Wireshark看到Ethernet frame check sequence incorrect??

可是仔細一想,現代的Ethernet MAC/switch在遇到bad frame時應該會直接drop掉才對(i.e. Wireshark理論上是看不到L2的bad frame的),那為啥鵝會看到那些Ethernet frame check sequence incorrect,而且offloading關掉之後,問題也消失了(誤打誤撞

)....

後來鵝試著在lab重建現場,最方便而且還算精確的方式是在ESXi上透過DirectPath I/O讓VM直接控制Ethernet MAC,然後產生大量traffic,看能不能重現一樣的狀況,如果看到一樣的狀況就是OS/driver相容性之類的問題,沒有的話就是user site的問題,建了兩個Linux VM測了半天,傳了上TB的garbage,就是看不到一樣的狀況,問題是鵝家的產品是based on BSD的,BSD VM卻無法透過DirectPath I/O直接控制NIC(VM的kernel boot起來時有看到BCM5719,但要initial PHY時失敗,所以不work

),換插另一張I社的I340-T4時Linux和BSD就都可以work,不過這樣就失去重建現場的意義了,請問一下有朋友做過類似的測試嗎

....

2018-02-28 20:57 發佈

文章關鍵字 Wireshark ETHERNET

hikaruu

hikaruu
個人積分：63分
文章編號：67584481

63分

2樓

2018-02-28 21:33

1. L2是全硬體實作,SW只可關L3以上,若關L3但L2卻修正,很明顯是L3 offloading的bug影響到L2,
因為LSO為省成本等實作都不會用store and forward實作,也不算誤打誤撞

2. I340只是顯示intel的還是比較優,沒有bug,
switch理因會discard這類封包,但若沒drop其實也沒必要去太在乎,因為上層還有l3/l4/l7

3.這類bug原始原因可能太多,不是ic廠實無必要花時間去找問題

wangcm

wangcm
個人積分：1626分
文章編號：67597564

1626分

樓主

2018-03-01 22:14

hikaruu wrote:
1. L2是全硬體實作,SW只可關L3以上,若關L3但L2卻修正,很明顯是L3 offloading的bug影響到L2,
因為LSO為省成本等實作都不會用store and forward實作,也不算誤打誤撞

2. I340只是顯示intel的還是比較優,沒有bug,
switch理因會discard這類封包,但若沒drop其實也沒必要去太在乎,因為上層還有l3/l4/l7

謝了,鵝只是想搞清楚這類bug是在怎樣的scenario下會被觸發出來的

....

hikaruu wrote:
3.這類bug原始原因可能太多,不是ic廠實無必要花時間去找問題

其實鵝的重點是以BCM5719這麼常見的Ethernet MAC而言,不想辦法釐清相容性的問題,接下來就有擦不完的屁股了(雖然以現代的CPU而言,預設把GbE的offloading關掉也算不痛不癢,只是不太符合鵝的原則就是了

)....

chiouss

chiouss
個人積分：118分
文章編號：68319447

118分

4樓

2018-04-28 13:08

wangcm wrote:
鵝有user反映ma...(恕刪)

1. 這問題看起來是 bge 的 TSO 有問題，所以當然拿 i340 (em) 複製不出問題囉

2. 你 wireshark 抓到的是 driver 處理過的封包，所以開 TSO 會看到 RX 有問題應該就是 TSO 的問題

TSO 是做 tcp segment offloading，代表封包的大小是交給 driver 去切的 (所以可以預期的是大封包才會有問題，因為小封包不需要切)，如果 driver 切錯了或是切完 checksum 填錯，那就可能送出去就被 switch 或是 client 丟掉了。我的猜測是 TSO 在組 RX 封包的時候沒有改 checksum 或是 checksum 錯誤，所以對方收不到封包 (或是收到又丟掉了)。但是 TX 有沒有正確，那就要看 client 送出去的封包才知道了。

wangcm

wangcm
個人積分：1626分
文章編號：68321242

1626分

樓主

2018-04-28 16:10

chiouss wrote:
1. 這問題看起來是 bge 的 TSO 有問題，所以當然拿 i340 (em) 複製不出問題囉

2. 你 wireshark 抓到的是 driver 處理過的封包，所以開 TSO 會看到 RX 有問題應該就是 TSO 的問題

謝了,那些Ethernet frame check sequence incorrect看來是本機發出的封包(48.53->48.169),不是收到的封包,而且鵝確定Wireshark中Validate Ethernet checksum if possible是enable的(不然不會顯示那些錯誤

),就算driver層有bug造成TSO/TXCSUM不work,MAC層產生的Ethernet checksum通常還是對的,而不會有看到checksum error的機會(libpcap capture的點不同的話,是有可能看到checksum還是0x0的封包,但在此checksum是已經填了,只是填錯了

),不過事隔這一段期間,鵝已經從那個職位畢業了,所以也看不到現場了

....