Zxneric
Zxneric
SagerNet/sing-quic#9 fixes this. But the same bug may also happened to hysteria1 and tuic. I have no idea about those protocol. Please also update them. @nekohasekai @dyhkwong plz review
And it seems that mtu discovery never worked properly
@nekohasekai 此错误在 1.9.0-rc11 中被修复，但是在 rc12 中再次出现 force push sing-quic 时，丢弃了 https://github.com/SagerNet/sing-quic/pull/9/commits/6a7930915e8150bbe732d85fe9cb8a1cd174017a 中的补丁。 设置此参数可以保证服务端工作正常，尤其是与其他实现的服务端互操作时，仅仅设置 udpMtu 只能保证客户端行为
@nekohasekai I would like to know how you plan to fix this issue? Are there any planned patches? Please let me know if you have any comments on my fix.
问题出在 https://github.com/SagerNet/quic-go/blob/cbbf722db9215d5ebf2f53ed43c804e71a71346c/connection.go#L316-L320， 如果不设置 config.MaxDatagramFrameSize， 会导致连接的 MaxDatagramFrameSize 被默认设置为16384，在这种情况下，对端如果发送了 加上hysteria header以后的包大小 大于 路径MTU 的包，会导致直接被丢弃。 如果服务端也是sing-box的话是没有这个问题的，因为sing-box在发送之前写死了检查大小的逻辑，但是如果和官方实现通信的话这里就bug了。
MaxDatagramFrameSize 在原本的 quic-go 中是不存在的，是被一系列patch加上的。 hysteria官方实现没有设置这个值是因为 wire.MaxDatagramSize 被改成了 1200，所以不会有问题。但是 sing-box 回滚了这个patch，因此需要手动设置这个值来通知对端正确的大小。 https://github.com/SagerNet/sing-quic/pull/10 我之前提的 PR 被拒了
1200是默认的设置，这个数值会在运行时被改变，我在hysteria的官方实现打log确认的。应该是和路径发现有关。 我确实没有弄清楚完整的整个逻辑链，但是这里肯定有个bug是确定的