[Bug] unable to send packets on OpenWRT

[flakeforever]

Verify steps

• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.
• I have searched on the issue tracker for a related issue.

Version

2.5.0

What OS are you seeing the problem on?

Other

Description

I have been using 2.4.1 before, and it worked well on my OpenWRT(21.02.3). So when I updated to 2.5.0, in the same environment, I didn't change anything, I just replaced the file, then the tun device only has TX data but no RX data.

So even though I have set the log at debug level, it has no more output.

2.4.1

2.5.0

I have briefly looked at the code, but it seems a bit complex to me. I would like to know where should I start if I want to investigate this issue myself.

Thank you, if someone could reply to me.

CLI or Config

No response

Logs

No response

How to Reproduce

No response

[xjasonlyu]

That's weird, v2.5.0 doesn't change anything on the tun side. Can you share your detailed configuration?

[flakeforever]

Alright, thank you.

My config:
/usr/sbin/tun2socks -device tun://tun0 -proxy socks5://10.8.0.7:1080 -loglevel debug

That's all, perhaps the issue lies in some default parameters?

[xjasonlyu]

How about your route tables?

[flakeforever]

Here is:

ip rule add fwmark 100 lookup 100
ip route add default dev tun0 table 100
iptables -t mangle -A PREROUTING -s 192.168.10.128/26 -m set --match-set office-ip dst -j MARK --set-mark 100

So, the office-ip is an ip-set

[myloft]

I had the same problem on an ARMv7 OpenWRT device.

[Kot-nikot]

Also release 2.5.0 does not work on OpenWRT 22.03 mipsel architecture. Installed 2.4.1 works.

[xjasonlyu]

Wondering how should I debug this as I don’t have arm-based openwrt devices. ;-)

[myloft]

From my test, the backend proxy server has received the request and returned the data. I will test on an x86 openwrt device to confirm whether it is related to the architecture.

[myloft]

From my test, the backend proxy server has received the request and returned the data. I will test on an x86 openwrt device to confirm whether it is related to the architecture.

It works fine on an x86 openwrt device.

[Kot-nikot]

Интересно, как мне отладить это, поскольку у меня нет устройств openwrt на базе рук. ;-)

does not work for me on ramips/mt7621 mipsle.

[xjasonlyu]

This issue should be fixed by 46c04db, welcome to try!

[flakeforever]

Hey bro, thank you for your work.

I compiled an exe and conducted tests. From the debug logs, I can see that it is able to parse some TCP protocols, but it still doesn't work correctly (it shows TCP connections, but cannot transmit data correctly).

I also did some tests today, and when I rolled back the version of golang.zx2c4.com/wireguard/tun to v0.0.0-20220318042302-193cf8d6a5d6 and edited tun_wireguard.go, it started working properly. I guess it might be an issue with this component?

These are my results, and I also hope that others can test it.

[xjasonlyu]

Yes, it is related to the wireguard tun module. I have tested on linux and macos, and it works well. But I have not yet tested on Windows.

Theoretically, if it shows TCP connections, it should be fine.. But taking from your screenshot, it seems like you tested on a linux-based platform, then why would you compile an exe for it?

[flakeforever]

Oh I mean it's an executable file, not .exe. :)
It does show some TCP connections initially, but I believe it might be blocking the threads, causing the data not to be transmitted correctly. When I forcefully shut it down, I can see some information.

DEBU[0123] [TCP] copy data for origin->remote: read tcp 142.251.220.110:443: operation aborted
DEBU[0123] [TCP] copy data for origin->remote: read tcp 104.244.42.193:443: operation aborted
DEBU[0123] [TCP] copy data for origin->remote: read tcp 13.251.235.250:443: operation aborted

[xjasonlyu]

Oh yes, these log messages are expected during shutdown stage.

[flakeforever]

After its initialization, it parsed some TCP connections, but these connections didn't finish. It wasn't until I forcibly terminated it.

INFO[0001] [TCP] 192.168.88.107:52626 <-> 142.251.220.110:443
INFO[0002] [TCP] 192.168.88.107:52629 <-> 104.244.42.193:443
INFO[0002] [TCP] 192.168.88.107:52630 <-> 104.244.42.193:443
INFO[0002] [TCP] 192.168.88.107:52631 <-> 104.244.42.193:443
INFO[0003] [TCP] 192.168.88.107:52637 <-> 13.251.235.250:443
INFO[0004] [TCP] 192.168.88.107:52638 <-> 104.244.42.2:443
INFO[0004] [TCP] 192.168.88.107:52639 <-> 104.244.42.2:443
INFO[0004] [TCP] 192.168.88.107:52640 <-> 104.244.42.2:443

DEBU[0123] [TCP] copy data for origin->remote: read tcp 142.251.220.110:443: operation aborted
DEBU[0123] [TCP] copy data for origin->remote: read tcp 104.244.42.193:443: operation aborted
DEBU[0123] [TCP] copy data for origin->remote: read tcp 13.251.235.250:443: operation aborted

[Kot-nikot]

I compiled the latest version of the package with yesterday's fixes for my linux mipsel platform:
tun2socks: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, Go BuildID=_a2qvyNQr2TsGApgkrYc/1HslD8tYyut90xLuuCH9/vs0I8gAVkClGIJVehn2Z/H_Sei_m7q3M2hukzwEWL, with debug_info, not stripped.

What do we have about the result:
The problem with data transfer is not solved. Some of the data passes through the tunnel and some does not.

INFO[0003] [TCP] 172.16.250.1:41708 <-> 157.240.205.34:443
INFO[0003] [TCP] 172.16.250.1:40764 <-> 157.240.205.63:443
INFO[0003] [TCP] 172.16.250.1:43832 <-> 31.13.65.50:80
DEBU[0075] [TCP] copy data for origin->remote: read tcp 31.13.65.50:80->172.16.250.1:43832: i/o timeout
DEBU[0130] [TCP] copy data for origin->remote: read tcp 157.240.205.63:443->172.16.250.1:40764: i/o timeout
DEBU[0333] [TCP] copy data for origin->remote: read tcp 157.240.205.34:443: operation timed out
DEBU[0393] [TCP] copy data for remote->origin: read tcp 100.81.8.82:38240->141.148.224.141:1234: i/o timeout

Accordingly, resources in the network are not available.

[netrixken]

can confirm, latest source code still has the issue (mt7621)

[xjasonlyu]

OK, I'll check it again.

[xjasonlyu]

Can anyone confirm this fix: 44ad654?

[Kot-nikot]

Checked. Everything seems to be working at first glance. I will continue to test. Thank you for your hard work.

[flakeforever]

Okay, cool bro! I confirm that this issue has been resolved.