Forums

[occ2]

Hi Vadim,

Thanks for the suggestions. I ran the tests in Transparent Mode with
everything else unchanged, fully restarting both WireSock and the browser
before each run:

– MTU = 1280 (baseline): still stalls.
– MTU = 1380: works.
– No MTU line: works.
– Virtual Adapter Mode / AllowedApps test: skipped. I need Transparent Mode,
and since it now works, a full WireSock restart after my rare AllowedApps
edits is fine for me.

I captured a debug log with MTU 1280 (startup plus failing page loads).
I couldn’t find a way to attach files here, so I sent the sanitized log
and the actual S1-S4 / H1-H4 values in Ticket#821156 on help.wiresock.net
on November 9. The lines that stand out:

MTU=1280
[TUN]: Packet size is above MTU: ip_len = 1280 MTU = 1258 => Injecting ICMP Packet Too Big
[TUN]: Converted IPv6 packet to ICMPv6 Packet Too Big (MTU: 1258, payload: 1210 bytes)

Each appears 80 times, all for IPv6. There are no similar events for IPv4.

One problem seems clear: the effective MTU of 1258 is below the IPv6
minimum link MTU of 1280. Per RFC 8201, a host must not lower its path
MTU below 1280 when it receives a Packet Too Big with a smaller value.
So Windows keeps sending 1280-byte IPv6 packets, WireSock keeps rejecting
them, and those IPv6 connections hang.

That may not be the whole story, though: as mentioned in my first post,
disabling IPv6 in Firefox didn’t help, so IPv4 connections also seem to
stall with MTU 1280, just without any messages in the log. Perhaps some
IPv4 packets are not covered by the MSS adjustment either.

With MTU 1380 or the default, everything works, and MTU – S4 stays
>= 1280.

Possible fix for the IPv6 part: never go below 1280 for IPv6 (clamp the
IPv6 MTU/MSS), or at least warn when MTU – S4 < 1280.

Questions:
1. Does this match what you see in the code, and what could cause the
IPv4 stalls?
2. Until a fix is out, would you recommend MTU 1380 with S4 = 22, or
simply omitting the MTU line?

Thanks!

[Author]

Posts