Vendors: pin MafiaNet v0.16.0 for the tunnelled-client MTU fix - #266
Conversation
Players behind a VPN could not connect. MafiaNet negotiated the path MTU in one direction only, then froze it for the life of the connection and applied it to both -- with no black-hole detection afterwards, so a datagram too large for the return path was resent at the same size until the connection timed out. Handshake packets are small enough to survive that, so the failure landed on the first split payload: the peer connected and then hung or dropped. v0.16.0 caps the negotiated MTU at 1400, which clears WireGuard and typical IPSec/IKEv2 tunnels, and clamps an MTU reported by a remote peer -- previously guarded only by a RakAssert, so a release build would adopt 65535 from a single forged datagram. Wire-compatible: RAKNET_PROTOCOL_VERSION stays at 7 and no message ids move. Peers converge on the smaller of their two caps, so a server built on this pin caps every connection, including clients still built against 0.15.0, with no client update needed. Note the bump is classified major by bump_version.sh because it touches MafiaNetPin.cmake. That rule is a deliberate proxy for "the wire format may have moved", which it has not here; the classification is conservative rather than protocol-mandated. Verified: M2OServer 64 builds against the new pin, and the fetched tree is at 667fa4e9 with MAXIMUM_MTU_SIZE 1400.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. WalkthroughThe CMake configuration updates MafiaNet from v0.15.0 to v0.16.0. The new comment records an MTU cap of 1400 and preserved ChangesMafiaNet dependency update
Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to This localized dependency pin adopts MafiaNet v0.16.0 for the tunnelled-client MTU fix while preserving wire compatibility; no actionable merge-blocking risk remains beyond normal checks and review. Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (1 skipped: 1 unsupported.) ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
2 participants
Pins MafiaNet to v0.16.0, which fixes players behind a VPN being unable to connect.
Why
MafiaNet negotiated the path MTU in one direction only — the connecting peer padded
ID_OPEN_CONNECTION_REQUEST_1down its ladder, the accepting peer echoed back whatever size arrived — then froze that value for the life of the connection and applied it to both directions, with no black-hole detection afterwards. A datagram too large for the return path was resent at the same size until the connection timed out.Every handshake packet is small enough to survive that, so the failure landed on the first split payload instead: the peer connected and then hung or dropped. Which tunnelled players it hit depended entirely on their exit node's encapsulation overhead — WireGuard 1420, Tailscale and many providers 1280, IKEv2 ~1400 — against MafiaNet's old top rung of 1492. That is why it looked intermittent.
v0.16.0 caps the negotiated MTU at 1400, adds finer rungs (1280, 1024) so stepping down costs less payload capacity, and clamps an MTU reported by a remote peer — previously guarded only by a
RakAssert, so a release build would adopt an MTU of 65535 from a single forged, unauthenticated datagram. It also fixes a deadWSAEMSGSIZEcheck, a stalledsendtoabandoning a connection attempt outright, and a latent divide-by-zero inConnect().Compatibility
Wire-compatible.
RAKNET_PROTOCOL_VERSIONstays at 7 and no message ids move.Two peers converge on the smaller of their two caps, because the accepting side clamps to its own
MAXIMUM_MTU_SIZEbefore replying and both sides clamp what they are told. A server built on this pin caps every connection — including clients still built against 0.15.0 — with no client update required.On the version bump
bump_version.shclassifies this as a major Framework bump because it touchescmake/MafiaNetPin.cmake. That rule is a deliberate proxy for "the wire format may have moved", and the pin file documents it as such. It has not moved here — the protocol version is unchanged and the MTU is negotiated per connection, never part of the packet format — so the major classification is the tooling being conservative by design rather than a real break. Flagging it rather than working around it.Verification
builds\build.bat M2OServer 64builds clean against the new pin._deps/mafianet-srcis at667fa4e9(chore(release): v0.16.0) withMAXIMUM_MTU_SIZE 1400, confirming the pin actually moved rather than reusing the cached 0.15.0 checkout.Summary by CodeRabbit