大发体育娱乐在线-大发体育娱乐官方网站-大发体育娱乐登录网址
做最好的网站

网络数据包收发流程,LibPcap丢包问题

来源:http://www.dfwstonefabricators.com 作者:关于计算机 人气:98 发布时间:2019-10-30
摘要:这段时间查看了下LibPcap丢包率高的问题。网上也有不少朋友提及,但自己总怀疑自己的问题与他人不一样,所以钻进去看了看。 进入函数netif_receive_skb()后,skb正式开始协议栈之旅。

  这段时间查看了下LibPcap丢包率高的问题。网上也有不少朋友提及,但自己总怀疑自己的问题与他人不一样,所以钻进去看了看。

进入函数netif_receive_skb()后,skb正式开始协议栈之旅。
先上图,协议栈大致过程如下所示:
图片 1
跟OSI七层模型不同,linux根据包结构对网络进行分层。
比如,arp头和ip头都是紧跟在以太网头后面的,所以在linux协议栈中arp和ip地位相同(如上图)
但是在OSI七层模型中,arp属于链路层,ip属于网络层.....
这里就不死抠概念,我们就说arp,ip都属于第二层。下面是网络第二层的处理流程

  环境描述:Snapgear-3.5.0 / kernel: linux-2.6.x / uClibc / Module: XSCALE/Intel IXP400 / LibPcap-0.9.2 / Snort-2.6.1.1

一、相关数据结构
内核处理网络第二层,有下面2个重要list_head变量 (文件linux_2_6_24/net/core/dev.c)
list_head 链表上挂了很多packet_type数据结构

  测试过程:先将板子设置成透明网桥模式,再让Snort工作在日志记录模式下(snort –A none -N),然后由eth1(PC1)->eth2(PC2)跑Chariot TCP/High_Performance,此时平均速度约为93Mbps,最后跑完整个脚本中断Snort,显示Dropped: ≈86%。丢包率如此骇人,于是我不得不踏上调查征程。

static struct list_head ptype_base[16] __read_mostly;   /* 16 way hashed list */
static struct list_head ptype_all __read_mostly;        /* Taps */

  进入snapgear/user/snort/src,打开until.c找到Dropped出处DropStats(),发现“Snort received”和“Dropped”均通过pcap_stats()得来,因此我觉得事情有些不妙了。

struct packet_type {
    __be16 type;                /* This is really htons(ether_type).*/
    struct net_device   *dev;   /* NULL is wildcarded here       */
    int     (*func) (struct sk_buff *,
                     struct net_device *,
                     struct packet_type *,
                     struct net_device *);
    struct sk_buff    *(*gso_segment)(struct sk_buff *skb, int features);
    int    (*gso_send_check)(struct sk_buff *skb);
    void   *af_packet_priv;
    struct list_head    list;
};

  上网查找资料,有不少叙述关于LibPcap丢包问题的文章,其中《Improving Passive Packet Capture: Beyond Device Polling》(可在

type 成员保存了二层协议类型,ETH_P_IP、ETH_P_ARP等等
func 成员就是钩子函数了,如 ip_rcv()、arp_rcv()等等

  接着我注释掉了snapgear/user/snort/src/snort.c/OpenPcap()中的pcap_setfilter(),再次测试,结果一样。于是我再让snapgear/user/snort/src/snort.c/PcapProcessPacket()直接return,再测试,结果并无改观。我失望了,难道非得让我去看LibPcap吗?没办法,看就看吧。

二、操作packet_type的API
//把packet_type结构挂在与type对应的list_head上面
void dev_add_pack(struct packet_type *pt){
    int hash;
    spin_lock_bh(&ptype_lock);
    if (pt->type == htons(ETH_P_ALL))        //type为ETH_P_ALL时,挂在ptype_all上面
        list_add_rcu(&pt->list, &ptype_all);
    else {
        hash = ntohs(pt->type) & 15;         //否则,挂在ptype_base[type&15]上面
        list_add_rcu(&pt->list, &ptype_base[hash]);
    }
    spin_unlock_bh(&ptype_lock);
}

  进入snapgear/lib/libpcap/一路查找,终于发现pcap_stats()链着下面pcap-linux.c中的pcap_stats_linux(),阅读了下面一大段注释,再debugging确定,天呀,难道要我去看kernel吗?“投之亡地而后存,陷之死地然后生”,我已经走上这条路了。

//把packet_type从list_head上删除
void dev_remove_pack(struct packet_type *pt){
    __dev_remove_pack(pt);
    synchronize_net();
}
void __dev_remove_pack(struct packet_type *pt){
    struct list_head *head;
    struct packet_type *pt1;
    spin_lock_bh(&ptype_lock);
    if (pt->type == htons(ETH_P_ALL))
        head = &ptype_all;                        //找到链表头
    else
        head = &ptype_base[ntohs(pt->type) & 15]; //

  没有多想,按注释直接全文通缉“tp_drops”,在snapgear/linux-2.6.x/net/packet/af_packet.c packet_rcv()中抓住了它。怀疑问题出在:

    list_for_each_entry(pt1, head, list) {
        if (pt == pt1) {
            list_del_rcu(&pt->list);
            goto out;
        }
    }
    printk(KERN_WARNING "dev_remove_pack: %p not found.n", pt);
out:
    spin_unlock_bh(&ptype_lock);
}

  if (atomic_read(&sk->sk_rmem_alloc) + skb->truesize >=
    (Unsigned)sk->sk_rcvbuf)
    goto drop_n_acct;

三、进入二层协议处理函数
int netif_receive_skb(struct sk_buff *skb)
{
   //略去一些代码
    rcu_read_lock();
    //第一步:先处理 ptype_all 上所有的 packet_type->func()           
    //所有包都会调func,对性能影响严重!内核默认没挂任何钩子函数
    list_for_each_entry_rcu(ptype, &ptype_all, list) {  //遍历ptye_all链表
        if (!ptype->dev || ptype->dev == skb->dev) {    //上面的paket_type.type 为 ETH_P_ALL
            if (pt_prev)                                //对所有包调用paket_type.func()
                ret = deliver_skb(skb, pt_prev, orig_dev); //此函数最终调用paket_type.func()
            pt_prev = ptype;
        }
    }
    //第二步:若编译内核时选上BRIDGE,下面会执行网桥模块
    //调用函数指针 br_handle_frame_hook(skb), 在动态模块 linux_2_6_24/net/bridge/br.c中
    //br_handle_frame_hook = br_handle_frame;
    //所以实际函数 br_handle_frame。
    //注意:在此网桥模块里初始化 skb->pkt_type 为 PACKET_HOST、PACKET_OTHERHOST
    skb = handle_bridge(skb, &pt_prev, &ret, orig_dev);
    if (!skb) goto out;

  debugging证明了怀疑的正确性,并发现sk_rmem_alloc会突然降为零。那么为什么会出现sk_rmem_alloc不够用呢?为此,我不得不弄清楚正常情况下sk_rmem_alloc是怎么被释放的。atomic_read()该死的原子操作,我还不得不感谢它,因为在查看它的时候发现了它的兄弟atomic_sub()并最终找到了sock_rfree()大人,debugging证明sk_rmem_alloc确实是由这位大人释放的。那什么时候这位大人才会露面呢?我真的对Linux认识太少了,惭愧呀!

    //第三步:编译内核时选上MAC_VLAN模块,下面才会执行
    //调用 macvlan_handle_frame_hook(skb), 在动态模块linux_2_6_24/drivers/net/macvlan.c中
    //macvlan_handle_frame_hook = macvlan_handle_frame;
    //所以实际函数为 macvlan_handle_frame。
    //注意:此函数里会初始化 skb->pkt_type 为 PACKET_BROADCAST、PACKET_MULTICAST、PACKET_HOST
    skb = handle_macvlan(skb, &pt_prev, &ret, orig_dev);
    if (!skb)  goto out;

  正因为见识少,所以才容易才发现许多惊奇:天呀,原来这么多内联函数都被定义在了头文件中呀。sock_rfree()便是通过snapgear/linux-2.6.x/include/net/sock.h中的static inline void skb_set_owner_r(struct sk_buff *skb, struct sock *sk)挂在了skb->destructor上。通过最笨拙的办法,继续查找destructor,终于确定了__kfree_skb()并踩到了更浅的支点kfree_skb(),事实证明,愚蠢的人自作聪明的后果往往令人惨不忍睹——可爱的kfree_skb()漫山遍野。我该怎么办呀?甚至有点后悔自己潜水太深了。冷静冷静,再找新的突破口吧。

    //第四步:最后 type = skb->protocol; &ptype_base[ntohs(type)&15]
    //处理ptype_base[ntohs(type)&15]上的所有的 packet_type->func()
    //根据第二层不同协议来进入不同的钩子函数,重要的有:ip_rcv() arp_rcv()
    type = skb->protocol;
    list_for_each_entry_rcu(ptype, &ptype_base[ntohs(type)&15], list) {
        if (ptype->type == type &&                      //遍历包type所对应的链表
            (!ptype->dev || ptype->dev == skb->dev)) {  //调用链表上所有pakcet_type.func()
            if (pt_prev)
                ret = deliver_skb(skb, pt_prev, orig_dev); //就这里!arp包会调arp_rcv()
            pt_prev = ptype;                               //        ip包会调ip_rcv()
        }
    }
    if (pt_prev) {
        ret = pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
    } else {               //下面就是数据包从协议栈返回来了
        kfree_skb(skb);    //注意这句,若skb没进入socket的接收队列,则在这里被释放
        ret = NET_RX_DROP; //若skb进入接收队列,则系统调用取包时skb释放,这里skb引用数减一而已
    }
out:
    rcu_read_unlock();
    return ret;
}

  干脆由pcap_open_live()出发,看看这个handle怎么得来,socket如何被创建的。碰到了socket(),于是我再次冲进kernel,可是找来找去都没socket()的原型,我再次迷惑——坦白,此前我根本不知道系统调用这档子事。查找资料,又是他——九贱,真真感谢这位大哥,在此推荐下他的论坛

int deliver_skb(struct sk_buff *skb,struct packet_type *pt_prev, struct net_device *orig_dev){
   atomic_inc(&skb->users); //这句不容忽视,与后面流程的kfree_skb()相呼应
    return pt_prev->func(skb, skb->dev, pt_prev, orig_dev);//调函数ip_rcv() arp_rcv()等
}

  既然pcap_open_live()巷子太深,那么我再从pcap_dispatch()突破。追踪到snapgear/lib/libpcap/pcap-linux.c中的pcap_read_packet(),发现在callback()调用用户程序前是通过recvfrom()取得包的。郁闷,又找不到原型,又是系统调用。再次感谢九贱,还有《UDP Socket Creation》的作者,正是看了他们的文章,sk->sk_prot->recvmsg才被锁定。遍地找寻了recvmsg,再根据LibPcap创建Socket时选用的类型SOCK_RAW,snapgear/linux-2.6.x/net/ipv4/raw.c中的raw_recvmsg()被相中了,因为它的老家struct proto raw_prot[]所在的老窝snapgear/linux-2.6.x/net/ipv4/af_inet.c中static struct inet_protosw inetsw_array[]的.ops所指向的inet_dgram_ops.recvmsg正好等于sock_common_recvmsg。欢呼——高兴得太早了,debugging确认时令我失望了,snapgear/linux-2.6.x/net/socket.c sys_recvfrom()调用sock_recvmsg()调用__sock_recvmsg()时,sock->ops->recvmsg更多时候并不等于sock_common_recvmsg,一团迷雾骤然升起——天呀!

这里只是将大致流程,arp_rcv(), ip_rcv() 什么的具体流程,以后再写。

  我深切地观望着packet_rcv()。我找不到更好的突破口了,就拿recvmsg当救命稻草了,再次搜寻recvmsg,终于,终于在snapgear/linux-2.6.x/net/packet/af_packet.c中发现了.recvmsg=packet_recvmsg。Debugging,打印函数地址,确认!更喜人的是在packet_recvmsg()中发现了最终出口skb_free_datagram(),snapgear/linux-2.6.x/net/core/datagram.c中的它显示它直接返回kfree_skb()。Debugging确认!

四、网络抓包tcpdump
tcpdump也是在二层抓包的,用的是libpcap库,它的基本原理是
1.先创建socket,内核dev_add_packet()挂上自己的钩子函数
2.然后在钩子函数中,把skb放到自己的接收队列中,
3.接着系统调用recv取出skb来,把数据包skb->data拷贝到用户空间
4.最后关闭socket,内核dev_remove_packet()删除自己的钩子函数

  至此,LibPcap捕获数据包的出入口已经找到了,之前赘述,无非是展现本人在寻找这两扇大门时的经过,以及犯下的愚蠢错误,旨在告诫与我一样还不了解Linux的朋友不要重蹈我的覆辙,也希望广大高手能够不吝赐教。

下面是一些重要的数据结构,用到的钩子函数都在这里初始化好了
static const struct proto_ops packet_ops = {
    .family =    PF_PACKET,
    .owner =    THIS_MODULE,
    .release =    packet_release,    //关闭socket的时候调这个
    .bind =        packet_bind,
    .connect =    sock_no_connect,
    .socketpair =    sock_no_socketpair,
    .accept =    sock_no_accept,
    .getname =    packet_getname,
    .poll =        packet_poll,
    .ioctl =    packet_ioctl,
    .listen =    sock_no_listen,
    .shutdown =    sock_no_shutdown,
    .setsockopt =    packet_setsockopt,
    .getsockopt =    packet_getsockopt,
    .sendmsg =    packet_sendmsg,
    .recvmsg =    packet_recvmsg,   //socket收包的时候调这个
    .mmap =        packet_mmap,
    .sendpage =    sock_no_sendpage,
};

  总结:LibPcap通过pcap_open_live()系统调用socket()创建一个socket.而系统调用socket()则是通过sys_socketcall()这个入口找到sys_socket()->sock_create()->__sock_create()->rcu_dereference(net_families[family])根据协议簇执行create。LibPcap选用的协议簇PF_PACKET通过af_packet.c中的packet_init()调用snapgear/linux-2.6.x/net/socket.c中的sock_register()被初始化注册进net_families[],其.create=packet create。因此LibPcap创建socket最终调用了packet_create(),在packet_create()中创建了sk并有sock->ops = &packet_ops; po->prot_hook.func=packet_rcv;而static const struct proto_ops packet_ops.recvmsg=packet_recvmsg,这便是用户程序通过LibPcap从socket取得数据包的入口。因此用户程序通过LibPcap获取数据包的整个过程可以简易描述为:由packet_rcv()接收来自底层的包(具体什么位置,我没有搞明白),并分配出一段buffer,在sk_receive_queue资源不足以再容纳下一段数据时,直接将数据丢弃kfree_skb(),并记录tp_drops(即我们通过pcap_stats()得到的ps_drop);而用户程序则是不时调用packet_recvmsg()从队列中一次性获取数据,并最后释放资源skb_free_datagram()。

static struct net_proto_family packet_family_ops = {
    .family =    PF_PACKET,
    .create =    packet_create,     //创建socket的时候调这个
    .owner    =    THIS_MODULE,
};

  其实到这里,我还未交代主题,那么导致LibPcap丢包的原因在哪里呢?了解了LibPcap捕获数据包的过程再来查找就没那么茫然了,debugging发现packet_recvmsg()的执行频度远小于packet_rcv(),所以在packet_rcv()接收数据并充盈sk_rmem_alloc后,packet_recvmsg()并不能及时将其清空,在这个时间差中只能丢包了。那么为什么packet_recvmsg()执行的频度不够呢?这可能是更底层的问题,限于能力,我在此无法给出解释。

至于系统调用 socket、recv、close是如何调到这些内核钩子函数的,以后再讲。这里只关注packet_type

4.1 系统调用socket

libpcap系统调用socket,内核最终调用 packet_create
static int packet_create(struct net *net, struct socket *sock, int protocol){
    po->prot_hook.func = packet_rcv;   //初始化钩子函数指针
    po->prot_hook.af_packet_priv = sk;
    if (protocol) {
        po->prot_hook.type = protocol;  //类型是系统调用socket形参指定的
        dev_add_pack(&po->prot_hook);//关键!!
        sock_hold(sk);
        po->running = 1;
    }
    return(0);
}

  再谈谈怎么解决这个问题。由于底层的原因我不得而知,所以我只能对我所了解的做出调整了——加大sk_rmem_alloc,利用其空间来容纳packet_rcv()的积极动作,但这个做法是以牺牲速度为代价的。在本人的测试环境中,启用snort中提供的所有rule,将sk_rmem_alloc扩至10M(echo 10485760 > /proc/sys/net/core/rmem_default && echo 10485760 > /proc/sys/net/core/rmem_max)能保证Dropped: 0.00%,但此时平均速度降至≈16Mbps。

4.2 钩子函数 packet_rcv 将skb放入到接收队列
文件 linux_2_6_24/net/packet/af_packet.c
简单来说,packet_rcv中,skb越过了整个协议栈,直接进入队列

  结束语:此文是本人对此问题进行查寻的笔记,走了很多弯路,如果有朋友也在关心此问题,那么不妨以本人为一反面材料,并希望读者能对文中谬误之处提出批评并指正。既然走了这么多弯路,当然浪费了大量宝贵时间,十分感谢我们老大在此过程中对我提供的大量帮助和对我所持的极大耐心。这些都是我决定写下本文的原因。 

4.3 系统调用recv
系统调用recv、read、recvmsg,内核最终会调用packet_recvmsg
从接收队列中取出skb,将数据包内容skb->data拷贝到用户空间

图片 2

4.4 系统调用close
内核最终会调用packet_release
static int packet_release(struct socket *sock){
    struct sock *sk = sock->sk;
    struct packet_sock *po;
    if (!sk)  return 0;
    po = pkt_sk(sk);
    write_lock_bh(&packet_sklist_lock);
    sk_del_node_init(sk);
    write_unlock_bh(&packet_sklist_lock);
    // Unhook packet receive handler.
    if (po->running) {
        dev_remove_pack(&po->prot_hook);   //就是这句!!把packet_type从链表中删除
        po->running = 0;
        po->num = 0;
        __sock_put(sk);
    }
    packet_flush_mclist(sk);
     // Now the socket is dead. No more input will appear.
    sock_orphan(sk);
    sock->sk = NULL;
    /* Purge queues */
    skb_queue_purge(&sk->sk_receive_queue);
    sk_refcnt_debug_release(sk);
    sock_put(sk);
    return 0;
}


搜一下内核源代码,二层协议还真是多。。。
drivers/net/wan/hdlc.c: dev_add_pack(&hdlc_packet_type);  //ETH_P_HDLC    hdlc_rcv
drivers/net/wan/lapbether.c:
            dev_add_pack(&lapbeth_packet_type);         //ETH_P_DEC       lapbeth_rcv
drivers/net/wan/syncppp.c:
            dev_add_pack(&sppp_packet_type);            //ETH_P_WAN_PPP   sppp_rcv
drivers/net/bonding/bond_alb.c:  dev_add_pack(pk_type); //ETH_P_ARP       rlb_arp_recv
drivers/net/bonding/bond_main.c:dev_add_pack(pk_type);  //PKT_TYPE_LACPDU bond_3ad_lacpdu_recv
drivers/net/bonding/bond_main.c:dev_add_pack(pt);       //ETH_P_ARP       bond_arp_rcv
drivers/net/pppoe.c: dev_add_pack(&pppoes_ptype);       //ETH_P_PPP_SES   pppoe_rcv
drivers/net/pppoe.c: dev_add_pack(&pppoed_ptype);       //ETH_P_PPP_DISC  pppoe_disc_rcv
drivers/net/hamradio/bpqether.c:
                    dev_add_pack(&bpq_packet_type);     //ETH_P_BPQ       bpq_rcv
net/ipv4/af_inet.c:  dev_add_pack(&ip_packet_type);     //ETH_P_IP       ip_rcv
net/ipv4/arp.c:    dev_add_pack(&arp_packet_type);      //ETH_P_ARP       arp_rcv
net/ipv4/ipconfig.c:  dev_add_pack(&rarp_packet_type);  //ETH_P_RARP      ic_rarp_recv
net/ipv4/ipconfig.c:  dev_add_pack(&bootp_packet_type); //ETH_P_IP        ic_bootp_recv
net/llc/llc_core.c: dev_add_pack(&llc_packet_type);     //ETH_P_802_2     llc_rcv
net/llc/llc_core.c: dev_add_pack(&llc_tr_packet_type);  //ETH_P_TR_802_2  llc_rcv
net/x25/af_x25.c:  dev_add_pack(&x25_packet_type);    //ETH_P_X25      x25_lapb_receive_frame
net/8021q/vlan.c:  dev_add_pack(&vlan_packet_type);     //ETH_P_8021Q     vlan_skb_recv

这些不同协议的packet_type,有些是linux系统启动时挂上去的
比如处理ip协议的pakcet_type,就是在 inet_init()时挂上去的
还有些驱动模块加载的时候才加上去的。

转载自

本文由大发体育娱乐在线发布于关于计算机,转载请注明出处:网络数据包收发流程,LibPcap丢包问题

关键词:

上一篇:java框架之struts2简要介绍,java框架struts2

下一篇:没有了

最火资讯