ping本机网口的IP地址，tcpdump在lo口才能抓到对应报文
0.0.1. 问题背景Q1：ping 本机eth1口的ip地址时，对应的ICMP报文会被发送到eth1口上吗？ 0.0.1.1. 实验： ping本机网口地址 通过tcpdump抓包命令，我们发现报文被发送到lo上，而不是对应的物理口 eth1。虽然ip 地址被配在本机的物理口上，但是报文并没有被发送到物理口。为了理解这个问题，我们需要先看下下面这个问题。 Q2： 当一个IP地址被添加到一个网口后
Kernel Study Notes
fib_unmerge：把local路由从main表里切割出来
fib_unmerge 是内核路由子系统中一个精巧的按需优化设计： 默认状态下，local 表只是 main 表的别名，所有路由合并在一张表里，fib_lookup 只需查一次表，性能最优 添加策略路由时，fib_unmerge 将 local 路由从 main 表中切割出来，放入独立的 local 表，确保策略路由能正确匹配 切割四步走：创建新 local 表 → 复制 local 路由 →
lo口与local路由表
0.0.1. 小实验接上篇文章 ping本机网口的IP地址，tcpdump在lo口才能抓到对应报文，我们知道在网口eth1上增加一个IP地址192.168.8.8/24后，内核会生成3条路由： local表：增加192.168.8.8/32的主机路由（RTN_LOCAL） main表：增加192.168.8.8/24的网段路由（RTN_UNICAST） local表
tcpdump命令与网口`PROMISC`状态标志位
0.1. 问题现象tcpdump/iproute2 是很多网络问题下的调试工具，大家也都很熟他的一些特性。比如， 执行tcpdump命令后，如果没有使用-p参数, 网口会进入PROMISC状态。 通过ip link命令可以查看网口状态，其中状态位里有个PROMISC标志。但是，后台执行一个在 eth0 口上抓包的tcpdump命令，就会发现一个问题： 当tcpdump命令在后台运
PAWS 在tcp协议栈中的实现
0.1. PAWS 检查： tcp_timewait_state_process 中使用，也就是在syn 报文明中了 tw 状态的 socket 山海，才使用。 不是所有syn报文都做检查 12345678910111213141516171819 91 enum tcp_tw_status 92 tcp_timewait_state_process(struct inet_timewait_s
tcp三次握手 --- 逐渐消失的tcp半链接队列
0.1. 概要：十年演进对比0.1.1. 历史实现(v4.3)网上大部分文档这部分内容讲的比较多，简单来说，可以把半链接队列的逻辑概括如下: 收到syn报文，查找listen socket。 创建一个半链接socket(req socket)，并放入listen socket的半链接队列里，发送syn+ack报文 收到client回复的ack报文，查找到对应的半链接socket(req so
创建req scoket时的三个长度检查
0.0.1. 创建半链接时的三个长度检查在处理TCP-SYN首包时候， tcp_conn_request函数里， 会有三个不同条件的长度检查。 inet_csk_reqsk_queue_is_full 半链接的个数超过sk_max_ack_backlog， 则丢包。 sk_acceptq_is_full： accept 队列长度超过sk_max_ack_backlog，则丢包。 sysctl_
网口状态标志位解析part2: 内核如何维护网卡carrier的状态
0.0.0.1. operstate的小插曲2006年内核引入operstate特性，在当时协议栈的维护者中也是颇有争议的！！！引入operstat特性的patch 0.1. 标志位IFF_UP0.1.1. 设置/清除标志位IFF_UPip link set eth0 up: 每个eth口在内核里有对应的struct net_device。 每个netdev设备里有一个上的fla