背景
今天遇到一个诡异的现象,当接口附加一个IP时,主IP业务正常,附加IP死活不行,tcpdump抓包确可以正常抓到到业务的报文,但是在PREROUTING raw添加规则确没有命中,说明报文没有到netfilter框架内,Scapy打流测试,通过bpftrace 跟踪kfree_skb,没有捕获大量的kfree_skb 调用,才引发今天的问题,数据报文去哪儿了?
结论
由于上层设备发送报文时,将附加IP的MAC地址填错导致,但是tcpdump可以明确报文已经到了主机,但是为什么却没有往netfilter框架递送,bpftrace 为什么没有捕获大量的kfree_skb? 简单的讲错误的MAC地址,正确的IP 是否可以正常通信?为什么?
内核源码分析
本文使用内核版本 5.10, 网卡驱动 e1000e
我们知道当网卡工作在直接模式(Direct Model)时,网卡只接收自己MAC地址的帧,此模式下通过scapy打流不匹配的目的mac地址时,数据帧直接被网卡层面丢弃,bpftrace 此时无法捕获kfree_skb事件。
当使用tcpdump工具时会将网卡设置为混杂模式(Promiscuous Model),不匹配自己的MAC地址也会接收交给网卡驱动处理。
/*** e1000_receive_skb - helper function to handle Rx indications* @adapter: board private structure* @netdev: pointer to netdev struct* @staterr: descriptor extended error and status field as written by hardware* @vlan: descriptor vlan field as written by hardware (no le/be conversion)* @skb: pointer to sk_buff to be indicated to stack**/
static void e1000_receive_skb(struct e1000_adapter *adapter,struct net_device *netdev, struct sk_buff *skb,u32 staterr, __le16 vlan)
{u16 tag = le16_to_cpu(vlan);e1000e_rx_hwtstamp(adapter, staterr, skb);skb->protocol = eth_type_trans(skb, netdev);if (staterr & E1000_RXD_STAT_VP)__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), tag);napi_gro_receive(&adapter->napi, skb);
}
这里e1000e网卡驱动接收报文,此处注意eth_type_trans(skb, netdev)方法
/*** eth_type_trans - determine the packet's protocol ID.* @skb: received socket data* @dev: receiving network device** The rule here is that we* assume 802.3 if the type field is short enough to be a length.* This is normal practice and works for any 'now in use' protocol.*/
__be16 eth_type_trans(struct sk_buff *skb, struct net_device *dev)
{unsigned short _service_access_point;const unsigned short *sap;const struct ethhdr *eth;skb->dev = dev;skb_reset_mac_header(skb);eth = (struct ethhdr *)skb->data;skb_pull_inline(skb, ETH_HLEN);/* 此处目的MAC不是设备DEV地址时,命中条件 */if (unlikely(!ether_addr_equal_64bits(eth->h_dest,dev->dev_addr))) {/* 检测目的MAC是否为多播或者组播 */if (unlikely(is_multicast_ether_addr_64bits(eth->h_dest))) {if (ether_addr_equal_64bits(eth->h_dest, dev->broadcast))skb->pkt_type = PACKET_BROADCAST;elseskb->pkt_type = PACKET_MULTICAST;} else {skb->pkt_type = PACKET_OTHERHOST;}}if (likely(eth_proto_is_802_3(eth->h_proto)))return eth->h_proto;.....
}
当我们的目的MAC地址与自身dev地址不匹配时,会将pkt_type = PACKET_OTHERHOST 然后返回eth->proto, 这里我们使用的IP报文,也就是将来会使用ip_rcv()处理。
然后通过NAPI接口,__netif_receive_skb_core,等一系列调用最终调用到ip_rcv_core()
/** Main IP Receive routine.*/
static struct sk_buff *ip_rcv_core(struct sk_buff *skb, struct net *net)
{const struct iphdr *iph;u32 len;/* When the interface is in promisc. mode, drop all the crap* that it receives, do not try to analyse it.*/if (skb->pkt_type == PACKET_OTHERHOST)goto drop;......drop:kfree_skb(skb);
out:return NULL;
}
这里有明确的注释说明,混杂模式的报文即pkt_type为PACKET_OTHERHOST值,直接丢弃,并且此处的drop,内核协议栈层面并没有做任何的丢包统计。
总结
经过分析我们可以总结我们遇到的问题,
1,通过scapy打流测试,为什么bpftrace没有捕获到大量的kfree_skb事件?
这是因为网卡工作在直接模式(Direct Model)网卡将目的MAC不是自己的直接丢弃,验证这个想象,可以直接使用tcpdump 工具抓包,此时bpftrace 可以捕获大量的kfree_skb事件。
2,tcpdump 捕获到去往自己IP的报文,为什么没有到netfilter框架?
这是因为tcpdump将网卡设置为混杂模式(Promiscuous Model)网卡驱动接收报文并将报文类型置为PACKET_OTHERHOST,当ip_rcv_core()接收后直接丢弃,并且没有在任何地方做丢包统计的动作。
感受
工作中遇到的每个小问题,背后都蕴藏着大量知识,只有平时多积累总结,才能游刃有余解决所面对的问题。