现象，使用tcpdump命令可以抓到进来的包，但是使用strace看程序，却没有在socket上收到数据。
通过 nstat/netstat/ip-s/ethtoo-S/看各种计数，发现没有错误的包。
也没看到iptables的设置；
也没有防火墙的设置；
根据这个现象，如果一开始不知道答案的话，只能通过一下步骤来分析问题。
https://mzhan017.blog.csdn.net/article/details/126438658 ；这里有记录一些分析的大体步骤。
- 看内核代码，找到三层的入口函数：netif_receive_skb
- 使用ftrace，打开上面这个入口函数的：function_graph, https://mzhan017.blog.csdn.net/article/details/122283614；这个功能还是非常的强大，可以分析函数执行的时间，也可以查看余下函数的整体执行过程。非常易于理解代码。
- 获取如下的结果：
2) | netif_receive_skb() {2) | netif_receive_skb_internal() {2) | skb_defer_rx_timestamp() {2) 0.119 us | classify();2) 0.623 us | }2) | __netif_receive_skb() {2) | __netif_receive_skb_core() {2) | /* netif_receive_skb: dev=ens224 skbaddr=ffff8bdfee5a7c00 len=535 */2) | ip_rcv() {2) | ip_rcv_finish() {2) 0.295 us | udp_v4_early_demux();2) | ip_route_input_noref() {2) | ip_route_input_slow() {2) 0.466 us | fib_table_lookup();2) | fib_validate_source() {2) | __fib_validate_source.isra.13() {2) 0.250 us | fib_table_lookup();2) 0.738 us | }2) 1.117 us | }2) 0.050 us | ip_handle_martian_source.isra.37();2) 2.788 us | }2) 3.111 us | }2) | kfree_skb() {2) | skb_release_all() {2) 0.048 us | skb_release_head_state();2) | skb_release_data() {2) 0.224 us | page_frag_free();2) 0.574 us | }2) 1.226 us | }2) | kfree_skbmem() {2) | kmem_cache_free() {2) 0.071 us | __slab_free();2) 0.447 us | }2) 0.776 us | }2) 2.633 us | }- 根据上面的执行步骤，大体上可以看到ip_handle_martian_source.isra.37(); 走到了火星包的处理过程。 根据下面这个链接，可以打开火星包日志打印开关：https://mzhan017.blog.csdn.net/article/details/120923977
- 下面主要是看，为什么归到火星包去了，这个和rp_filter 这个功能相关。
- 为了安全，systemd的安装包里有这么一个配置，将这个rp_filter的功能打开了，所以就会出现标题里的现象。
