82574L 死亡数据包 考古

去年买了个带两个Intel 82574L网卡的工控机做All in One,发现其中一个网卡经常会死,平均一个礼拜死一次,另一个网卡一直很健壮。

期间试过将该网卡从ESXI直通给OpenWRT、升级OpenWRT从使用专有驱动到使用内核驱动的新版本、修改EEPROM、关闭offload、更换网线、增加散热,均无法彻底避免。

遇到的内核日志大体就这几种:Detected Hardware Unit Hang、Reset adapter unexpectedly、NIC link is down。

出现后,需要给网卡完整的断掉再通电才能够恢复。期间异常断网给家人带来了无尽的麻烦,特别我我在外时,家里断网,需要我回家后重启OpenWRT才能恢复,就异常麻烦。

之前互联网上对该问题的讨论,大多也就是我尝试过的那些方法,就剩pcie_aspm=off的方法我没试过,据说一些人试了也没有效果。最近无意中从上面这张图中见到了一个词“死亡数据包”。中文互联网上的信息实在有限,于是上Google用关键词“82574L death packet”搜索了一下,发现原来别有洞天。

商用硬件供应商Star2Star的技术总监Kristian Kielhofner于2013年在自己的博客发文指出,Intel的82574L(可能还包括82583)网卡芯片存在漏洞,会被特定的数据包攻击导致系统崩溃,这就是所谓的”packet of death”(死亡数据包)漏洞。坏消息是这个漏洞是底层问题,用Linux、BSD或者Windows都无所谓,统统都中枪。

他先是发现客户手里的机器会莫名其妙崩溃,并且需要经过完整的电源循环才能恢复,并且这个过程没有任何的规律可言。于是他花了几个星期-150小时来研究这个问题,最终在一个经销商的热情帮助下,发现了复现的方法,并将问题的源头指向了这个网卡,并写了bash脚本,通过ethtool命令修改EEPROM来修复(可惜他并不愿意分享他的脚本,与后来Intel官方发布的关闭电源管理的修改EEPROM脚本或许是一样的?),并写了一篇博客完整的记录整个过程。之后他登上了Slashdot,并得到了大量关注,并成功引起了Intel的关注,Intel的工程师打电话给他进行了愉快的交流,并提供了一个内部工具供他测试,并发布了官方的statement(可惜已经访问不到了)。博客下面有来自全世界的一百多条的评论,甚至有来自博客中提到的一款开源工具的作者的评论(改开源工具后来让Kristian Kielhofner为他的工具背书)。这些评论者由于没有得到作者分享的脚本,在评论中各自分享自己的EEPROM,试图寻找规律。评论中也有人贴出了Intel官方提供的EEPROM修复脚本(或许就是作者与Intel合作的成果?),有评论者反馈通过该脚本成果修复了公司的机器,并且7个月没有遇到任何问题(至少我是无法通过这个方案解决)。

作者在更新中,还发布了一个开源软件,通过记录网卡崩溃前的100M流量,来排查网络问题。

接着发现还有人专门采访他并发文在WIRED上。这件事还引起了CloudFlare的网络工程师的兴趣,并评论道”Figuring out something as convoluted as that is not only incredibly rewarding and satisfying, but time consuming and frustrating as well.”

一个公司的CTO,保持了极强的技术能力而非ppt能力,通过个人的力量,耗费大量时间,发现了巨头的某一款产品的某一个具体缺陷,巨头没有回避,而是成功与其合作,推动了产品的迭代。这个过程中,无数工程师参与专业型讨论,成功解决的也会回来反馈。同时还有媒体人参与报道。这种纯纯的技术的工程师文化,着实单纯,blog和Slashdot上的几百条评论没有任何戾气(跟当今中文互联网氛围差异很大)

现代软硬件越来越复杂,即使的巨头投入巨量的人力物力研发测试,也难以避免产品出现缺陷,工业领域的现代软硬件的稳定性和复杂度失控问题也值得思考

”Life is too short to be spent debugging Intel parts.”
                                — Van Jacobson

Share

You may also like...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注