潍坊网站制作保定公司,广西城乡和建设厅网站,营销策划公司,wordpress实惠主机背景 今天遇到一个诡异的现象#xff0c;当接口附加一个IP时#xff0c;主IP业务正常#xff0c;附加IP死活不行#xff0c;tcpdump抓包确可以正常抓到到业务的报文#xff0c;但是在PREROUTING raw添加规则确没有命中#xff0c;说明报文没有到netfilter框架内#xff…背景 今天遇到一个诡异的现象当接口附加一个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 packets 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事件。
2tcpdump 捕获到去往自己IP的报文为什么没有到netfilter框架 这是因为tcpdump将网卡设置为混杂模式Promiscuous Model网卡驱动接收报文并将报文类型置为PACKET_OTHERHOST当ip_rcv_core()接收后直接丢弃并且没有在任何地方做丢包统计的动作。 感受 工作中遇到的每个小问题背后都蕴藏着大量知识只有平时多积累总结才能游刃有余解决所面对的问题。
