kcptun+udp2raw设置了MTU依然报huge packet

[liaowang11]

看了以前的ISSUE，设置了MTU还是报huge packet，不过功能上看来没什么问题。另外见tcpdump截图，里面没找到有大于1800的packet。

udp2raw版本号：

udp2raw-tunnel
git version:e5584c73be    build date:Sep  6 2018 10:36:31
repository: https://github.com/wangyu-/udp2raw-tunnel

服务端设置

$ udp2raw/udp2raw_amd64 -s -a -l0.0.0.0:28900 -r127.0.0.1:28903 -k $pwd --raw-mode faketcp
$ kcptun/server_linux_amd64 -l :28903 -t 127.0.0.1:$port -mode fast2 -mtu 1200

客户端设置

./udp2raw_amd64 -c -r $remoteIP$:28900 -l 0.0.0.0:1090 --raw-mode faketcp -a -k $pwd
./client_linux_amd64 -mtu 1200 -l ":1092" -r "localhost:1090" -mode fast2

tcpdump

[wangyu-]

我在vultr VPS上用你给的参数，通过scp拷贝大文件，复现了huge packet , data_len >1800的现象。

但是我用tcpdump能抓到大于1800的包。 你的抓包参数应该不对，你的tcpdump应该被设置成了只抓udp的包或者只抓lo接口上的包，而大于1800的包是从公网上收到的(fake)tcp包。

scp拷贝大文件是从server拷贝到client端，huge packet , data_len >1800出现在client端。VPS client是vultr日本，server是vultr美西

以下是client端抓包日志（抓包参数tcpdump -ieth0 tcp and greater 1500 and port 28900）：

09:24:16.803899 IP 45.77.xx.xx.vultr.com.28900 > 45.76.xx.xx.vultr.com.12384: Flags [.], seq 10829184:10831680, ack 73409, win 40965, options [nop,nop,TS val 1738338633 ecr 3763510806], length 2496
09:24:17.015758 IP 45.77.xx.xx.vultr.com.28900 > 45.76.xx.xx.vultr.com.12384: Flags [.], seq 10585728:10588224, ack 77201, win 41298, options [nop,nop,TS val 1738338844 ecr 3763511029], length 2496

可见client端确实收到了长度>1800的包，tcpdump可以抓到

server端抓包日志(tcpdump -i ens3 tcp and greater 1500 and port 28900)：

空

抓不到，可以判断长度为2496的包不是server发出的。

进一步分析问题

在server端去掉greater 1500参数。用tcpdump -i ens3 tcp and port 28900抓包：

09:30:24.751245 IP 45.77.xx.xx.vultr.com.28900 > 45.76.xx.xx.vultr.com.12384: Flags [.], seq 2805184:2806432, ack 32529, win 41421, options [nop,nop,TS val 1738706640 ecr 3763878821], length 1248
09:30:24.751948 IP 45.77.xx.xx.vultr.com.28900 > 45.76.xx.xx.vultr.com.12384: Flags [.], seq 2806432:2807680, ack 32529, win 41055, options [nop,nop,TS val 1738706641 ecr 3763878821], length 1248

可见正常的server端发出的数据包长度为1248。

2496长度的包应该是VPS运营商的锅，2496很可能是因为VPS把2个1248长度的包错误得粘在了一起。

不知你的VPS是不是也是Vultr。建议你修正tcpdump的参数以后，重新抓包看一下，是不是同样的原因。

[liaowang11]

确实如此，用你的方法我这边验证出来了，看到客户端报错就以为客户端发送的时候报的（所以tcpdump只抓了发送的包）。
不过我用的是GCP，怀疑是ISP做了什么，不清楚了。

[fbion]

mark