-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
panic: Calling IP() on a DomainAddress #116
Comments
两天前的提交已经修复 13ad3fd (不过最新的 commit 有问题,等下会 force |
怎么解决循环引用的问题? |
|
如果发现存在其它问题,也请直接反馈 比如目前发现任意门 TPROXY 那里不能缓存 conns,只能发一个包就 close,否则行为会异常,等下打算看看把 dial 改为 listen 的表现 |
问题修复了吗,我用最新版碰到了相同的问题 |
I encountered this issue just now on xray 1.8.10 unfortunately i have nothing useful to reproduce it with. the server config has been running fine for a very long time before then, so i suspect it is somehow triggered by traffic and not the config itself. but i also don't know which protocol. stacktrace
config (users, wireguard credentials and http paths redacted)
|
It occurs with 1.8.13 as well. Stacktrace is the same. Is it reasonable to think the broken address comes from a specific inbound? I can try to remove inbounds from production (or rather, move them to a secondary xray container) until the problem stops occurring, but would like to know if it's worth the effort. currently the issue only happens 2-3 times per day, so it's kind of fine with autorestart. |
Also had this a few times on one server. Can you by any chance have any outbound with ForceIP? I didn't checked the code but I didn't see this error anymore when I removed plain ForceIP from outbound (ForceIPv4v6 & ForceIPv6v4 is ok for me) |
i posted my full config above, no I don't use any variant of ForceIP. |
Oh, sorry, didn't pay enough attention. Now I see. That's strange than. If I encounter that once more I'll get back with additional info. |
Hi @RPRX @yuhan6665 @mmmray , on core 1.8.23, this log appears and stop core .(go1.22.5 linux/amd64) 2024/08/13 21:08:29 DEBUG - XRAY: 2334503 what is problem ? |
by the way, I patched the panic in question to print out the inner domain address, and it shows all kinds of normal hosts/domain names. Therefore this is not the same bug as #3628, where things such as |
Some update here. I patched xray with this patch on top of 1.8.23: diff --git a/features/routing/session/context.go b/features/routing/session/context.go
index 3c9764b..5153b12 100644
--- a/features/routing/session/context.go
+++ b/features/routing/session/context.go
@@ -2,6 +2,8 @@ package session
import (
"context"
+ "time"
+ "fmt"
"github.com/xtls/xray-core/common/net"
"github.com/xtls/xray-core/common/session"
@@ -50,8 +52,15 @@ func (ctx *Context) GetTargetIPs() []net.IP {
return nil
}
- if ctx.Outbound.Target.Address.Family().IsIP() {
- return []net.IP{ctx.Outbound.Target.Address.IP()}
+ addr := ctx.Outbound.Target.Address
+
+ if addr.Family().IsIP() {
+ time.Sleep(time.Millisecond)
+ addr2 := ctx.Outbound.Target.Address
+ if !addr2.Family().IsIP() {
+ fmt.Println("XDEBUG before: ", addr, "after: ", addr2)
+ }
+ return []net.IP{addr.IP()}
}
return nil And am getting this output after a while:
I think it means that the Note that the IP addresses stand in no relation to the hostnames at all, 1.1.1.1 certainly doesn't belong to google. |
my problem sloved with this options in 1.8.23 protocol": "freedom", and routing": { The problem was in asIs for freedom and routing |
We should fix crash even if you configured wrong, please try to post your stacktace |
I applied those config changes and got the same crash almost immediately
I think I know though where the race condition happens: Xray-core/app/dispatcher/default.go Line 242 in 41d03d1
this line essentially mutates outbound while other goroutines may access it:
|
why it would call dispatch more than once? |
@yuhan6665 it's two completely unrelated connections going through the same outbound. |
That should be different contexts though
|
it's possible the contexts are different but pointing to the same outbound object. I guess this sounds illogical but the signs point in that direction. Otherwise, how can it be that I'm observing mutations from 1.1.1.1 to some google domain from within GetTargetIPs? |
Fix XTLS#116 This issue does not appear at all if mux.cool is disabled. Maybe the issue can be avoided if routing is disabled too, but it's possible that the same issue appears elsewhere. Tests should be added. ***The mux server has no tests at all!*** Step-by-step: 1. The mux server is calling handleStatusNew with the same context multiple times. That function then calls w.dispatcher.Dispatch 2. Dispatch assigns some values specific to the connection onto the outbound here: https://github.com/XTLS/Xray-core/blob/83eef6bc1f554be84aeb799417688a070cd32ab8/app/dispatcher/default.go#L241-L242 3. Because the outbounds array on the connection object is the same across multiple connections (it's the same context), the value of outbound.Target flips back and forth between values such as "1.1.1.1" or "chat.facebook.com" (IPAddress vs DomainAddress) 4. Many layers deeper in routing, as part of this Dispatch call, this function is called: https://github.com/XTLS/Xray-core/blob/83eef6bc1f554be84aeb799417688a070cd32ab8/features/routing/session/context.go#L53-L55 It does two things, in order: 1. Checks if Target is an IPAddress (IsIP) 2. If it's an IP, call IP() Because Target keeps mutating back and forth between multiple kinds of address, it sometimes is an IP for Step 1, and a DomainAddress for Step 2 5. Calling IP() on a DomainAddress panics: panic: Calling IP() on a DomainAddress. goroutine 123018 [running]: github.com/xtls/xray-core/common/net.domainAddress.IP(...) github.com/xtls/xray-core/common/net/address.go:172 github.com/xtls/xray-core/features/routing/session.(*Context).GetTargetIPs(0xc004175428) github.com/xtls/xray-core/features/routing/session/context.go:54 +0x5f github.com/xtls/xray-core/app/router.(*MultiGeoIPMatcher).Apply(0xc0003a63e0, {0x156c770?, 0xc004175428?}) github.com/xtls/xray-core/app/router/condition.go:143 +0x3e github.com/xtls/xray-core/app/router.(*ConditionChan).Apply(0x495c9d?, {0x156c770, 0xc004175428}) github.com/xtls/xray-core/app/router/condition.go:32 +0x5c github.com/xtls/xray-core/app/router.(*Rule).Apply(...) github.com/xtls/xray-core/app/router/config.go:30 github.com/xtls/xray-core/app/router.(*Router).pickRouteInternal(0xc000367a40, {0x156c770, 0xc004175428}) github.com/xtls/xray-core/app/router/router.go:196 +0x176 github.com/xtls/xray-core/app/router.(*Router).PickRoute(0x1562810?, {0x156c770?, 0xc004175428?}) github.com/xtls/xray-core/app/router/router.go:84 +0x25 github.com/xtls/xray-core/app/dispatcher.(*DefaultDispatcher).routedDispatch(0xc000398fc0, {0x1562810, 0xc0050cd350}, 0xc00418dea0, {{0x15625a8, 0xc005974c10}, 0x1bb, 0x2}) github.com/xtls/xray-core/app/dispatcher/default.go:420 +0x307 created by github.com/xtls/xray-core/app/dispatcher.(*DefaultDispatcher).Dispatch in goroutine 123015 github.com/xtls/xray-core/app/dispatcher/default.go:252 +0x56c
在往buf.Buffer的UDP属性赋值的时候,创建
&net.UDPAddr{
IP: addr.IP(),
Port: int(port.Value()),
}
但这里的addr是从addrParser.ReadAddressPort()而来,这里的addr有可能是域名,如果直接调用addr.IP(),会直接panic
func (domainAddress) IP() net.IP {
panic("Calling IP() on a DomainAddress.")
}
The text was updated successfully, but these errors were encountered: