Bad tcp behavior under mirrored network

[LHe496]

Windows Version

Microsoft Windows [Version 10.0.26100.2314]

WSL Version

2.3.26.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

5.15.167.4-microsoft-standard-WSL2

Distro Version

Ubuntu 22.04

Other Software

telnet 0.17-44build1 arm64

Repro Steps

On Windows on Arm wsl2 with a mirrored network, use telnet to connect to an unexisting port.
Suppose there is no process listening to port 8677:
telnet 127.0.0.1 8677

Expected Behavior

Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused

Actual Behavior

Trying 127.0.0.1...

The telnet will wait for a long time to report time out.

Diagnostic Logs

No response

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions here

Once completed please upload the output files to this Github issue.

Click here for more info on logging
If you choose to email these logs instead of attaching to the bug, please send them to [email protected] with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.

View similar issues

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it!

Open similar issues:

• WSL with networkingMode=mirrored does not refuse localhost connection while the port is not open (#12245), similarity score: 0.78
• Socket Connect hangs until timeout runs out in mirrored mode. (#10855), similarity score: 0.75

Closed similar issues:

• Mirrored networking mode makes requests to localhost:PORT wait 2 minutes (#10844), similarity score: 0.78
• In mirrored network mode, Devices on the same LAN subnet can access ports within my WSL2, but those on different subnets cannot. (#11447), similarity score: 0.77
• In Mirrored mode incoming packets from remote device on LAN are not received in WSL2 (#10535), similarity score: 0.75

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[LHe496]

It's Windows on Arm only. It's fine on amd64 PC.

[OneBlue]

/logs

[LHe496]

The log file:
WslLogs-2024-11-15_17-07-02.zip

[github-actions]

Diagnostic information

.wslconfig found
Detected appx version: 2.3.26.0

[CatalinFetoiu]

@LHe496 thanks for reporting the issue

this sounds similar to #10855

to confirm it's the same issue, could you please collect networking logs using https://github.com/microsoft/WSL/blob/master/diagnostics/collect-networking-logs.ps1? the script will generate a "WslNetworkingLogs" zip

It's interesting that the issue happens only on arm but not on amd

[LHe496]

Networking log:
WslNetworkingLogs-2024-11-16_14-17-21.zip

[github-actions]

Diagnostic information

.wslconfig found
Detected appx version: 2.3.26.0
optional-components.txt not found

[LHe496]

BTW, I've tested the procedure mentioned on #12245. It's the same to me. I think maybe it's the same problem since before updating wsl to version 2.3.26.0, I've experienced the same problem under wsl version 2.3.24.0.

[CatalinFetoiu]

thanks for sending the logs
it seems to be the same symptom as #10855

the RST packet should have destination port same as the source port of the SYN packet (45823), but the destination port is altered (it's 60362)

14:18:27.853583 loopback0 Out ifindex 2 00:15:5d:1e:ac:f8 ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 64, id 26490, offset 0, flags [DF], proto TCP (6), length 60)
127.0.0.1.45823 > 127.0.0.1.8677: Flags [S], cksum 0xfe30 (incorrect -> 0x3579), seq 2562497111, win 64240, options [mss 1460,sackOK,TS val 764011537 ecr 0,nop,wscale 7], length 0
14:18:27.854132 loopback0 In ifindex 2 00:15:5d:ee:ac:99 ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 128, id 45691, offset 0, flags [DF], proto TCP (6), length 40)
127.0.0.1.8677 > 127.0.0.1.60362: Flags [R.], cksum 0xfe1c (incorrect -> 0x7109), seq 0, ack 2562497112, win 0, length 0
14:18:28.904890 loopback0 Out ifindex 2 00:15:5d:1e:ac:f8 ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 64, id 26491, offset 0, flags [DF], proto TCP (6), length 60)

[CatalinFetoiu]

/dupe #10855

[microsoft-github-policy-service]

Hi! We've identified this issue as a duplicate of another one that already exists in this repository. This specific instance is being closed in favor of tracking the concern over on the referenced thread.

Thanks for your report!

[LHe496]

Something mysterious happens. After I installed wireshark to capture the traffic, it turns out to be fine that Windows seems to be able to sent back message to the right port. If I stop wireshark from capturing, it brokes again. Maybe this could be a clue.

[MichiBab]

The wireshark capturing did not fix it on my side sadly.