[Bug] unable to send packets on OpenWRT
flakeforever opened this issue · comments
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
That's weird, v2.5.0 doesn't change anything on the tun side. Can you share your detailed configuration?
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?
How about your route tables?
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
I had the same problem on an ARMv7 OpenWRT device.
Also release 2.5.0 does not work on OpenWRT 22.03 mipsel architecture. Installed 2.4.1 works.
Wondering how should I debug this as I don’t have arm-based openwrt devices. ;-)
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.
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.
Интересно, как мне отладить это, поскольку у меня нет устройств openwrt на базе рук. ;-)
does not work for me on ramips/mt7621 mipsle.
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.
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?
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
Oh yes, these log messages are expected during shutdown stage.
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
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.
can confirm, latest source code still has the issue (mt7621)
OK, I'll check it again.
Checked. Everything seems to be working at first glance. I will continue to test. Thank you for your hard work.
Okay, cool bro! I confirm that this issue has been resolved.