https://blog.rei.ac/tags/%E9%9A%8F%E7%AC%94/Recent content in 随笔 on ReiAC's BlogHugo -- gohugo.iozh-cnTue, 27 Oct 2026 17:05:56 +0800https://blog.rei.ac/post/debian-13-tcp-timestamps-%E5%AF%BC%E8%87%B4-apt-%E8%BF%9E%E6%8E%A5%E8%A2%AB%E9%98%B2%E7%81%AB%E5%A2%99%E4%B8%A2%E5%8C%85/Tue, 27 Oct 2026 17:05:56 +0800https://blog.rei.ac/post/debian-13-tcp-timestamps-%E5%AF%BC%E8%87%B4-apt-%E8%BF%9E%E6%8E%A5%E8%A2%AB%E9%98%B2%E7%81%AB%E5%A2%99%E4%B8%A2%E5%8C%85/<p>这两天在公司更新一台手上的开发机从 Debian 12 到 Debian 13</p> <p>然后更新完成后发现 apt 连公司源的时候第一个请求是好的, 后续的请求就会直接卡住</p> <p>这台设备之前在 Debian 12 的时候也是好的，手上另一台去年更新的 Debian 13 开发机是好的, 于是尝试将去年更新的那台 Debian 13 的机器也 apt upgrade 了一下后重启, 也出现了这个问题</p> <p>然后就开始抓包排查, 看样子像是第一个请求的包都能正常到服务器, 但是后续第二个条连接的 SYN 直接被丢了</p> <p>最怪的是, 偶尔是可以通的, 然后第三个连接又不通了</p> <p>最开始以为是公司防火墙策略的问题, 但是想想也不对, 毕竟更新前好的, 更神秘的是另一台 Debian 更新之后也复现了问题</p> <p>抓包看了眼序列, 发现发现第二条连接的 SYN 没回应, 像是被丢弃了, 想了想这条链路只能是 内核网络链路和 apt 应用了,</p> <p>因为另一台 Debian13 的机器 upgrade 后并没有更新 apt, 那想来只能是内核了</p> <p>验证了一下降级 apt 包里的内核历史版本, 发现好了</p> <p>二分法确认到第一个有这个问题的内核版本是 6.12.94, 检查相关改动, 大概能定位到这个改动 <a class="link" href="https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5da5662181ef8a251e3ba564903002c2e87de452" target="_blank" rel="noopener" >https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5da5662181ef8a251e3ba564903002c2e87de452</a> ^{<svg xmlns="http://www.w3.org/2000/svg" aria-hidden="true" focusable="false" x="0px" y="0px" viewBox="0 0 100 100" width="12" height="12" class="icon outbound"> <path fill="currentColor" d="M18.8,85.1h56l0,0c2.2,0,4-1.8,4-4v-32h-8v28h-48v-48h28v-8h-32l0,0c-2.2,0-4,1.8-4,4v56C14.8,83.3,16.6,85.1,18.8,85.1z"></path> <polygon fill="currentColor" points="45.7,48.7 51.3,54.3 77.2,28.5 77.2,37.2 85.2,37.2 85.2,14.9 62.8,14.9 62.8,22.9 71.5,22.9"></polygon> </svg>} </p> <p>这个改动是从主线 7.0 cherry pick 来修到 6.12.94 内核上的, 让 Timestamp Offset 的数值分布发生变化，使公司镜像源的服务器一直丢弃这个包</p> <p>但是这个其实存在迷惑, 因为按照改动代码来看</p> <ul> <li>旧的 TS Offset：32-bit 哈希结果。</li> <li>新的 TS Offset：64-bit 哈希结果中的一个 32-bit 部分</li> </ul> <p>两者的有效数值范围都是 0 到 $2^{32}−1$，即 0 到 4294967295, 按理来说变动是不大的</p> <p>解决方法是配置 <code>/etc/sysctl.d/99-tcp-timestamps.conf</code></p> <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code><span class="lnt">1 </span><span class="lnt">2 </span></code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-fallback" data-lang="fallback"><span class="line"><span class="cl"># 这个值默认 1 启用 TCP 时间戳, 并为每个连接使用随机偏移量; 0 禁用; 2 启用但是不随机 </span></span><span class="line"><span class="cl">net.ipv4.tcp_timestamps = 2 </span></span></code></pre></td></tr></table> </div> </div><p>另外还搜到了一篇知乎的文章, 是2020年的, 和我这个2026年的 fix 无关, 但是原理上可能相同</p> <p><a class="link" href="https://zhuanlan.zhihu.com/p/145939529" target="_blank" rel="noopener" >https://zhuanlan.zhihu.com/p/145939529</a> ^{<svg xmlns="http://www.w3.org/2000/svg" aria-hidden="true" focusable="false" x="0px" y="0px" viewBox="0 0 100 100" width="12" height="12" class="icon outbound"> <path fill="currentColor" d="M18.8,85.1h56l0,0c2.2,0,4-1.8,4-4v-32h-8v28h-48v-48h28v-8h-32l0,0c-2.2,0-4,1.8-4,4v56C14.8,83.3,16.6,85.1,18.8,85.1z"></path> <polygon fill="currentColor" points="45.7,48.7 51.3,54.3 77.2,28.5 77.2,37.2 85.2,37.2 85.2,14.9 62.8,14.9 62.8,22.9 71.5,22.9"></polygon> </svg>} </p> <p>这篇知乎文章和现在的区别是 tcp_tw_recycle 这个东西已经于2017年移除（上面 commit 链接也有提到）</p> <p>接着检索互联网, 发现 Linux 网络开发邮件列表中，有份2026年的, 专门讨论 tcp: secure_seq: add back ports to TS offset 的后续报告。它描述了 NAT 场景下的 TCP Timestamp Offset 回归问题，而且报告者发现，将客户端设置为 tcp_timestamps=2 可以恢复正常。</p> <p><a class="link" href="https://lists.openwall.net/netdev/2026/06/11/29" target="_blank" rel="noopener" >https://lists.openwall.net/netdev/2026/06/11/29</a> ^{<svg xmlns="http://www.w3.org/2000/svg" aria-hidden="true" focusable="false" x="0px" y="0px" viewBox="0 0 100 100" width="12" height="12" class="icon outbound"> <path fill="currentColor" d="M18.8,85.1h56l0,0c2.2,0,4-1.8,4-4v-32h-8v28h-48v-48h28v-8h-32l0,0c-2.2,0-4,1.8-4,4v56C14.8,83.3,16.6,85.1,18.8,85.1z"></path> <polygon fill="currentColor" points="45.7,48.7 51.3,54.3 77.2,28.5 77.2,37.2 85.2,37.2 85.2,14.9 62.8,14.9 62.8,22.9 71.5,22.9"></polygon> </svg>} </p> <p>结合两篇文章和自己抓包, 盲猜了一个问题发生步骤</p> <ol> <li>Debian 13 根据本地四元组生成 Timestamp Offset：TS_OFFSET = hash(src_ip, dst_ip, src_port, dst_port)</li> <li>服务端复用旧连接的四元组,短连接关闭后，服务端可能仍然保留该四元组对应的 TIME_WAIT 状态。新的连接复用同一个外部端口时，如果新连接的 TSval 比旧连接的时间戳小，就可能触发 PAWS 相关检查</li> <li>最后丢包这一步是自己盲猜的, 因为未经流程申请对公司的防火墙做测试, 感觉上是被防火墙直接丢了 SYN, 或者服务端可能返回针对旧连接状态的 ACK，而不是预期的 SYN-ACK？</li> </ol> <p>另外这个现象在另一位使用 Ubuntu 开发机的同事的设备上也复现了, Ubuntu 26.04 出现这个问题, 24.04 设备是好的, 也是同样的解决方法</p> <p>且 Debian 12 的 timestamp 序列似乎是递增的？（但是这里不合理，因为net.ipv4.tcp_timestamps = 1 这个默认选项很早就存在了）</p> <p>由于是在公司遇到这个问题, 工作时间直接被同事召唤解决其他问题去了, 暂时没空完整详细的探究这个问题发生的根源, 因此只先记录到现在这个程度</p>