Skip to content

Comments

TUN inbound: Make udp_fullcone pure side effect free udp connection#5525

Merged
RPRX merged 1 commit intoXTLS:mainfrom
Owersun:tun-udp-connection
Jan 12, 2026
Merged

TUN inbound: Make udp_fullcone pure side effect free udp connection#5525
RPRX merged 1 commit intoXTLS:mainfrom
Owersun:tun-udp-connection

Conversation

@Owersun
Copy link
Collaborator

@Owersun Owersun commented Jan 12, 2026

This makes udp_fullcone usage independent side effect free implementation of net.Conn
This allows to substitute other imeplentations ip stacks could use, but with custom logic allowing FullCone NAT
The code is clearly split to the places it belong, and handler/stack_gvisor/udp_fullcone don't depend on each other and don't know about each others implementation as they should be.
Both stack and connection are nice 200-300 line files.
Connection handling was remove from udp_fullcone and delegated to be part of lifecycle handler should do.
Handler will close connections calling .Close() on net.Conn, when outbound signal that the connection is complete, which will make udp connections close and clean up.
Running for 12 hours with two devices behind a router shows proper gofunc cleanup, keeping the number of running coroutines going up and down with connection number.

@RPRX
Copy link
Member

RPRX commented Jan 12, 2026

虽然 #5521 (comment) ,不过对 UDP 来说似乎应该仅看上行五分钟活跃而不是还看下行,不过这个应该改各个出站吧

等我合并了 #5522 你 rebase 一下

@RPRX
Copy link
Member

RPRX commented Jan 12, 2026

@Owersun rebase

…plementing net.Conn

Decouple udp connection from gVisor primitives, making handler/stack/udp_connection implementation independent of each other
@Owersun Owersun force-pushed the tun-udp-connection branch from 2dced0c to 322a2c2 Compare January 12, 2026 10:15
@Owersun
Copy link
Collaborator Author

Owersun commented Jan 12, 2026

done

@RPRX RPRX changed the title Proxy: Tun: Make udp_fullcone pure side effect free udp connection TUN inbound: Make udp_fullcone pure side effect free udp connection Jan 12, 2026
@RPRX RPRX merged commit a2c6e92 into XTLS:main Jan 12, 2026
39 checks passed
@RPRX
Copy link
Member

RPRX commented Jan 12, 2026

@Owersun 加上“指定网关 IP”和“自动设置系统路由”这两个选项吧,虽然 GUI 也能完成但对我这种直接跑 core 的人来说很方便

Windows 用一条 route add 0.0.0.0 mask 0.0.0.0 *.*.*.* if ** 就行了,要提醒下出站的 interface 设置 WLAN 等直连接口

@Owersun
Copy link
Collaborator Author

Owersun commented Jan 12, 2026

I will take a look, sure.
Couple of days pls :). I'll think about how to approach the design of options best, so people can't screw it badly by misconfiguring.

@RPRX
Copy link
Member

RPRX commented Jan 12, 2026

刚看了下,你这 rebase 咋把我 #5522 改的 log、ctx 那些都删掉了?我即将删掉这个 commit,请重新 PR,确保 #5522 的功能正常

@Owersun
Copy link
Collaborator Author

Owersun commented Jan 12, 2026

I think my google translate is failing me...
You mean the "DispatchLink" inside udp_fullcone and all "CanSpliceCopy" etc configuration for udp connection?
Yes, it's not longer needed, - the udp_fullcone implements udp_connection, that is passed to Handler.HandleConnection, and gets all the same configuration as tcp connection when dispatched.
It's now in one place for both TCP/UDP.
I see everything is unified now, all the logs are printed similar for both TCP/UDP.
Sniffing works, all looks good for me.
Was there anything different between how UDP connection dispatched and TCP connection dispatched?

@RPRX
Copy link
Member

RPRX commented Jan 12, 2026

如果是那样的话,那个 LogInfo processing TCP 改了吗

@Owersun
Copy link
Collaborator Author

Owersun commented Jan 12, 2026

nono, I didn't touch the handler at all in my changes, only udp_fullcone.go and stack_gvisor.go were in the pull request

@RPRX
Copy link
Member

RPRX commented Jan 12, 2026

那还是重新 PR 一下吧,那个被我改成了 LogInfo processing TCP,需要改一下 net type

@Owersun
Copy link
Collaborator Author

Owersun commented Jan 12, 2026

ah you mean handler.go line 130 "processing TCP from "...?
yeah, I'll fix that, sure! I'll open new pull request with more unified wording.

@Owersun
Copy link
Collaborator Author

Owersun commented Jan 12, 2026

done #5526

BTW: net.DestinationFromAddr() panics in case network protocol is unknown. I don't know how that could happen, but I already saw it once, a packet arrived for TCP connection with unknown network protocol, and the whole app closed on "panic".

@RPRX
Copy link
Member

RPRX commented Jan 12, 2026

不能吧,会不会是 gVisor 的 bug

@Owersun
Copy link
Collaborator Author

Owersun commented Jan 12, 2026

I'll keep an eye on that and try to figure out where it came from if I see it again.
And I agree with you that this is not right in current design and when we register gVisor for TCP and UDP it shouldn't give back anything unexpected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants