Iperf3 不经过openvp×n或者其他代理软件测速时 报data_len>1800错误，关闭GRO时报错消失

[Olympus-E]

具体测试过程和结果我贴在了 #226 最后，经测试是GRO在驱动层合并了数据包，关闭GRO无此问题

但是在远程VPS（我用的vultr）母机开启了GRO GSO之类的功能，子机器无法修改母鸡设置导致上传的时候依旧会报错

现在暂时通过修改源码 让udp2raw不丢弃超长的包，想法是既然数据包已经送进了网卡，由网卡进行了合并，进了系统就不再需要考虑包超长的问题，所以不丢弃也无妨

不过只是个暂时（暴力）解决方法，只要调控好发送端MTU，确保不会有（大量）超长包发送，不影响使用即可

不知道UDP2RAW处理大于1800的包还会有什么其它问题，本人小白一枚，看不懂代码细节，所有想法和结论只是基于猜猜猜，希望不要惹怒wangyu大大hhhhh

[wangyu-]

不知道UDP2RAW处理大于1800的包还会有什么其它问题

如果2个长度是1400的包粘在一起，你可以从中间切开恢复出两个包。

如果一个1400的包和1000的包粘在，粘在一起以后你怎么知道第一个包长度是1400呢。 至少需要加一个字段在包的开头标识包有多长吧。

[Olympus-E]

不知道UDP2RAW处理大于1800的包还会有什么其它问题

如果2个长度是1400的包粘在一起，你可以从中间切开恢复出两个包。

如果一个1400的包和1000的包粘在，粘在一起以后你怎么知道第一个包长度是1400呢。 至少需要加一个字段在包的开头标识包有多长吧。

刚刚粗略地看了下GRO的工作原理https://lwn.net/Articles/358910/

是不是GRO没法区分udp2raw传过来的数据（可能目的地MAC 端口什么的都一样，Headers也相似，因为都是通过udp2raw来传输的），把数据包识别成了被分片的数据了？进而导致GRO把这些相似数据包合并了。
觉得有分片才有合并，不然GRO也不会去合并两个不相干的数据包 会出错

[Olympus-E]

刚刚测试了下 udp2raw两侧使用--seq-mode 2选项能降低超长包数量

感觉是因为seq没有按续所以内核判断数据包不可合并，便把之前收集的待合并包先发上去了。

参考https://www.ibm.com/developerworks/cn/linux/l-cn-network-pt/index.html

以 IPv4 的 TCP 为例，匹配的条件有：
源 / 目的地址匹配
TOS/ 协议字段匹配
源 / 目的端口匹配
而很多其它事件将导致 GRO 列表向上层协议传递聚合的数据包，例如 TCP 的 ACK 不匹配或者 TCP 的序列号没有按序等等。

[kklem0]

I'm using udp2raw with Wireguard and I am also facing this issue.

[kklem0]

https://sandilands.info/sgordon/segmentation-offloading-with-wireshark-and-ethtool

[kklem0]

不知道UDP2RAW处理大于1800的包还会有什么其它问题

如果2个长度是1400的包粘在一起，你可以从中间切开恢复出两个包。

如果一个1400的包和1000的包粘在，粘在一起以后你怎么知道第一个包长度是1400呢。 至少需要加一个字段在包的开头标识包有多长吧。

The size is maximum segment size (MSS).
https://patchwork.kernel.org/patch/75235/
Would it just work if we simply add 65536 to the buffer size?