利用systemtap定位ifconfig dropped數據包的原因

http://blog.chinaunix.net/uid-20662820-id-3842431.html

 

 

 

歡迎轉載，轉載請保留文章的完整性!
Author: Tony <[e-mail]>
Date: 2013年8月10日周六 @青島


最近在將內核從2.6.32升級到3.0后，通過ifconfig發現dropped數據包明顯增多，但是測試上層應用，並不會影響應用的正常工作。其實問題到這里就可以結束了，但作為一個內核愛好者，這只是一個開始。
於是決定通過systemtap來分析內核，找到dropped數據包增多的真正原因。關於systemtap的介紹可以參考我的另一篇博文 http://blog.chinaunix.net/uid-20662820-id-3799149.html。
1.問題的表面現象如下圖所示：（dropped字段非常大，且一直增加）

2.分析內核代碼，在dropped字段可能增加的地方，添加kprobe探測點。

3.運行腳本，定位出數據包dropped的代碼邏輯

從上面輸出可以看出，數據包dropped是因為skb->protocol=0x0004(802.2)，linux內核並沒有加載該協議的處理函數，導致dropped字段增加。
問題原因找到了，dropped的數據包是cisco交換機發送的802.2協議數據包，內核不支持該協議導致，對系統無影響。

但是另一個問題就出來了，為什么之前的內核就沒有顯示這么多dropped呢？？？
其實看一下2.6.32內核代碼，你會發現netif_receive_skb函數中，當出現不支持的protocol的時候，內核只是簡單的drop，並不會增加dev->stat.dropped字段，但在3.0內核中，將這種數據包也統計到dev->stat.dropped中。

check一下代碼的改動記錄，不難發現從2.6.37內核開始，該部分進行了改動
commit caf586e5f23cebb2a68cbaf288d59dbbf2d74052
Author: Eric Dumazet <[e-mail]>
Date:   Thu Sep 30 21:06:55 2010 +0000
    net: add a core netdev->rx_dropped counter

    In various situations, a device provides a packet to our stack and we
    drop it before it enters protocol stack :
    - softnet backlog full (accounted in /proc/net/softnet_stat)
    - bad vlan tag (not accounted)
    - unknown/unregistered protocol (not accounted)

    We can handle a per-device counter of such dropped frames at core level,
    and automatically adds it to the device provided stats (rx_dropped), so
    that standard tools can be used (ifconfig, ip link, cat /proc/net/dev)

    This is a generalization of commit 8990f468a (net: rx_dropped
    accounting), thus reverting it.

    Signed-off-by: Eric Dumazet <[e-mail]>
    Signed-off-by: David S. Miller <[e-mail]>

世界又清靜了。。。。