与tincfecVPN同用复现huge packet提示，以及对原因的一点猜想

[DavidRice1]

wangyu 您好，

使用这款软件有一段时间了，之前一直用做wget时中转链接，提速效果显著。最近开始使用您的另一个项目"tinyfecVPN"，虽然使用上没有问题，但查看生成的log发现记录了上百条[WARN]huge packet, data_len > 1800,dropped。

参阅了#158 觉得问题不在"tinyfecVPN"上，故把issue发在本项目中。

测试：版本，环境

两款软件均于11月18日clone、编译，系统为全新安装Ubuntu 18.10 x64，清空过iptables并仅新增SNAT条目。客户端与服务端均运行于上述环境的机器，软件配置如下：

./udp2raw_amd64 -s -r ip:port  -l 127.0.0.1:1234 -k "*some-password*" -a --retry-on-error
./tinyvpn -c -r 127.0.0.1:1234 --sub-net 10.0.0.0 -f 1:3,2:4,8:6,20:10 --tun-dev tun100 --keep-reconnect

现象

表现为访问与使用https网站过程中会报huge packet：例如使用speedtest.net时，下载测速时客户端会出现警告，上传测速时服务端会出现警告。分别测试了客户端与服务端透过IPv4 或 IPv6链接，现象相同。
利用#210 中提到的tcpdump方法，一样可见大包（两个小包粘贴在一起）只出现在接收侧，但又不是发送侧发出的（只发送了两个小包）。

猜想

网上关联的问题（收到比网卡设置的更大MTU的数据包）都提到了为网卡的“Large Receive Offload (LRO)”或Linux内核中“Generic Receive Offload (GRO)“功能会合并数据包并放到TCP栈中来提升网络效率。【类似的还有TCP Segmentation Offload, Generic Segmentation Offload等，取决于网卡支持，可用ethtool --show-offload DEV_NAME查看】。
尝试使用ethtool禁用网卡的LRO功能，但有一部分是内嵌到网卡固件的，并没有提供修改空间，例如显示tx-gso-robust: on [fixed]的条例修改会提示Could not change any device features。关闭其余提供Offload的条例依旧可见huge packet警告。

由于本人对Linux和网卡驱动等不是很熟悉，可能存在我的修改并没有完全禁用Offload功能，还是请指点。如果的确原因如此，亦或无法绕过这个缓存，可否考虑不要丢弃大于1800数据包或附加其他条件而不过滤Offload后的包呢？

谢谢！

引用：https://seclists.org/tcpdump/2012/q1/127

[wangyu-]

udp2raw在2层抓包（mac层），我以前觉得udp2raw应该不会受粘包影响。

网上关联的问题（收到比网卡设置的更大MTU的数据包）都提到了为网卡的“Large Receive Offload (LRO)”或Linux内核中“Generic Receive Offload (GRO)“功能会合并数据包并放到TCP栈中来提升网络效率。【类似的还有TCP Segmentation Offload, Generic Segmentation Offload等，取决于网卡支持，可用ethtool --show-offload DEV_NAME查看】。

不过看了你说的以后，我觉得也许有些包在网卡驱动层(LRO)就被粘在一起了，即使在mac层抓包也绕不过。

如果的确原因如此，亦或无法绕过这个缓存，可否考虑不要丢弃大于1800数据包或附加其他条件而不过滤Offload后的包呢？

如果原因确实如此，会考虑。 不过不仅仅是不丢弃大于1800的包这么简单，如果想要把粘在一起的两个/多个包正确拆分开来，需要在udp2raw协议的层面做修改。

[DavidRice1]

谢谢您的回答，期待未来修复这个问题 :D

[Olympus-E]

在使用iperf3 直接通过udp2raw（udp2raw转发udp数据 tinyportmapper 转发iperf所需的tcp数据）测试udp速度的时候也遇到这个问题了 tcpdump抓包复现此问题 确认为粘包（收到包为2倍发出包大小）

udp2raw命令：
sudo ./udp2raw_amd64 -c -l 0.0.0.0:2005 -r **It's a secret**:7355 -k **It's also a secret** --cipher-mode xor --auth-mode simple --retry-on-error -a

经测试 当GRO打开时 出现包长大于1800警告

当GRO关闭时 没有警告（我网卡TSO 等其余默认关闭）

数据下一楼放

[Olympus-E]

网卡offload选项情况（GRO已关闭）

IPERF3选项
iperf3 -c 127.0.0.1 -p 2005 -u -b 50M -R -l 1000

UDP2RAW日志数据先不贴了，其余正常，当GRO为ON时出现packet_len > 1800， GRO OFF警告消失

TCP测试（iperf3 -c 127.0.0.1 -p 2005 -P10 -R）在GRO为ON时没有此问题

[kailin4u]

如果想要把粘在一起的两个/多个包正确拆分开来，需要在udp2raw协议的层面做修改。

期待修复这个问题，可以考虑在每个包前面增加包长字段

[wangyu-]

已修复。

新发布的20190716.test.0版 增加了--fix-gro选项，可以解决这个问题，你们试用下，需要在两端同时开启这个选项。

[keeno1982]

我在原来可用的配置上，在服务端和客户端各加了--fix-gro，然后网络就不通了

[zhyonc]

期待Win客户端版本更进--fix-gro选项

[livehl]

ethtool -K eth0 gro off

阿里云
搞定

[fbion]

mark

[clanet]

使用了新发布的20190716.test.0，虽然不出现>1800的warning，但出现了另外的warnning:
[WARN]huge packet, data_len 18001 > 18000(max_data_len),dropped

[wangyu-]

我在原来可用的配置上，在服务端和客户端各加了--fix-gro，然后网络就不通了

无法复现。

[wangyu-]

使用了新发布的20190716.test.0，虽然不出现>1800的warning，但出现了另外的warnning:
[WARN]huge packet, data_len 18001 > 18000(max_data_len),dropped

可以试一下新版看解决了没有。
https://github.com/wangyu-/udp2raw-tunnel/releases/tag/20200715.0

[Jimmy-Z]

我这里也遇到了这个warning, 然后看到了这个参数, 加上有效, 但是README完全没有提到, 搜索才找到这里来, 我觉得不如不要在README里放一份过时的help输出.

[SylphiaWindy]

我这里是 wireguard + udp2raw，除了 --fix-gro 以外没有使用其他的 options
ping 是 ok 的，iperf3 测试速率都是0，日志中出现 [WARN]huge packet, data_len > 1800,dropped
之后又将两端的 gro gso 都关掉，问题依旧

tcpdump 抓包看收到的大小最大是1250

应该是我这里某一端 tun 网卡的 mtu 设置有问题导致的？ wireguard tun 网卡 MTU 大于 1200 就会有问题？

[wangyu-]

我这里也遇到了这个warning, 然后看到了这个参数, 加上有效, 但是README完全没有提到, 搜索才找到这里来, 我觉得不如不要在README里放一份过时的help输出.

README.md里的help输出不保证是最新的，很多问题help输出也不一定能覆盖到。

我在huge packet的warning里加上了--fix-gro的提示。 另外创建了一个wiki页面，总结了一些常见的问题：

https://github.com/wangyu-/udp2raw-tunnel/wiki/Known-issues-and-solutions