Linux编译SCTP内核模块的轻量级方法

场景

一般人很少会遇到主动编译Linux内核模块的机会。

我们遇到的情况是，内核sctp协议栈与用户态sctp协议栈冲突，导致不得不hack一个非标准的SCTP内核模块，插入到合一安装的系统中，使得两个协议栈能够兼容起来！

具体冲突场景

在Linux内核SCTP协议栈与用户态SCTP协议栈共同工作的场景，现象为用户态SCTP协议栈的偶联建立，总是被自动ABORT掉。

解决方法：

• SCTP内核协议栈的应用，与使用用户态协议栈的应用分开部署
• 合一部署时，需要对内核SCTP内核模块进行hack，插入非标准的SCTP内核模块

hack SCTP内核模块的方法

• 暴力方式，对于SCTP内核协议栈代码中所有发送ABORT的代码注释掉，使得内核协议栈不能发送ABORT报文

此方式不用理解SCTP内核代码的具体逻辑，简单粗暴，充满着暴力美学

• 优雅方式，在sctp_recv函数中增加兼容代码goto discard_release，使得跳过对于RFC2960，8.4 - Handle OOTB报文的处理

此方式修改位置确定，代码修改少，且逻辑顺畅。具体修改方法不难，可自我学习

---

另外，内核SCTP模块主动对于OOTB报文，发送ABORT报文，它源头就在于RFC 2960, 8.4章节的界定

重新编译SCTP内核模块方法

全量编译方法

按照部署环境的内核版本号，从社区下载与之一致的Linux内核源代码包，解压后，对内核编译进行配置，以及hack SCTP内核模块代码，然后进行全内核代码的编译。

最开始一直对这种全量编译内核模块的方法，表示过怀疑，为了一个小小的内核模块，竟然需要编译整个内核，太过于重装了！

不过，此方法一直能够用，而且只有在产品要求部署在新环境时，才被迫这样编译一次，整体上劳费程度被均摊了，就没有费心思去深入研究这个问题。

直到这一次，用这种编译方法翻了车，虽然，可以编译出来的SCTP内核模块，但就是无法插入到新环境的Linux操作系统。

推测可能新环境的内核存在与社区内核存在不同的裁剪，难道需要新环境Linux的源码包？

后来，在友商的技术支持下，了解到一种轻量级编译内核模块的方法，而且还更外简洁、通用 😃

轻量级新方法

   # 在新环境上，安装对应内核开发包，可以从ISO镜像中获取
   # 以rpm安装包为例
   yum install kernel-headers kernel-devel
   
   # 按需要编译某一具体的内核代码
   # 注意：/usr/src/kernel/sdk为安装完上面的开发包后生成的目录
   make -C /usr/src/kernel/sdk -j4 M=/path/to/sctpsource modules

• -C选项指定了Linux内核开发包的位置；有此选项甚至可以进行内核模块的交叉编译
• -j4指示进行并行编译
• M= M=/path/to/sctpsource通过Makefile入参变量，指定编译的内核模块源码目录
• modules目标，指明了进行内核模块编译，而非全量内核编译

验证hack后兼容性

前置条件

# 插入非标准sctp内核模块
insmod /path/to/sctpko

# 查看是否插入成功
lsmod |grep sctp

使用lksctp-tools使用内核协议栈工具集

# 以服务器端角色启动
sctp_test -H 127.0.0.1 -P 60000 -l &

# 客户端发起单次连接
sctp_test -H 127.0.0.1 -P 60001 -h 127.0.0.1 -p 60000 -s

# 需要同时在另外一个终端上抓包观察
tcpdump -nnNi any  sctp

使用usrsctp用户态协议栈工具集

# 前置条件需要对usrsctp进行编译

export LD_LIBRARY_PATH=/path/to/usrsctp/usrsctplib/.libs
cd /path/to/usrsctp/usrsctplib/

# 启动非UDP封装的用户态协议栈服务器端
./programs/echo_server &

# 发起客户端连接
./programs/client 127.0.0.1 7

# 需要同时在另外一个终端上抓包观察
tcpdump -nnNi any  sctp