ipv6 udp tracker outgoing error peers

[lirener]

What version of this package are you using?
"bittorrent-tracker": "^11.0.0"

What operating system, Node.js, and npm version?
system：win10
Node.js：v20.10.0
"bittorrent-tracker": "^11.0.0"

What happened?
udp tracker is outgoing with the wrong IPV6 address（udp tracker 传出错误的IPV6地址）

What did you expect to happen?
Trace the cause of the problem and fix it（追踪该问题的产生原因，并且修复它）

Are you willing to submit a pull request to fix this bug?
I won't
BUG.avi ：https://www.veed.io/view/22cb4c20-d8b5-41c9-84bb-e43e3468f900?panel=share

[lirener]

能否独立ipv4和ipv6?
又或者 仅启动ipv6 udp 模式 可以实现吗？
Can ipv4 and ipv6 be independent?
Or is it possible to only enable ipv6 udp mode?

---

就是因为随机获取IPV6地址 我不知道为什么 所以我分离了UDP的ipv4和IPV6
（It's because I get the IPV6 address randomly. I don't know why, so I separated the UDP ipv4 and IPV6.）

接着 今天又发现个问题。。
我的路由opentracker负责udp ipv4模式
电脑负责ipv6 udp模式 他们起冲突了 会导致ipv6覆盖ipv4 ip
Then Found another problem today. .
My routing opentracker is responsible for udp ipv4 mode
The computer is responsible for the ipv6 udp mode. If they conflict, it will cause ipv6 to overwrite ipv4 ip.

我的IPV4 ip：
27.155.140.215
我的IPV6 ip：
240e:37b:563:1800:2840:d04d:fdba:224e

如果说返回路由器的IP我还能理解是NAT问题 但是

24.0.40.64:53325	解析：#24(18).0(0).#40(28).#64(40)
36.14.3.123:1379	解析：#36(24).#14(0E).#3(03).#123(7B):#1379(0563)
253.186.34.78:2		解析：#253(FD).#186(BA).#34(22).#78(4E):#2(2)

我的BT端口：02

带#号代表10进制 ()中内容代表16进制

路由器使用的是opentracker(仅ipv4)、转发到电脑应用udp是BT tracker(包含ipv4+ipv6)

我想这个问题 比较严重
如果有的用户一会请求IPV6一会请求IPV4(尝试重试)
可能就会造成正常用户请求出现错误IP的情况……
恰巧我的tracker目前是ipv4+ipv6混合
如果达到了上述说的就可能造成错误的请求任意用户分解IPV6的IPV4地址
I think this problem is more serious
If some users request IPV6 for a while and IPV4 for a while (try again)
It may cause a normal user request to have an incorrect IP...
It just so happens that my tracker is currently a mix of ipv4+ipv6
If the above is achieved, it may cause an error in requesting any user to decompose the IPv6 IPv4 address.

[lirener]

随机IPV6地址的原因 找到了
同样的问题ipv4地址变成组合起来到IPV6去了……
THE REASON FOR RANDOM IPV6 ADDRESSES HAS BEEN FOUND
Same problem: ipv4 addresses become combined to IPV6......

并且今天我尝试关闭了udp opentracker也无法解决 看样子不是应用冲突。。
该问题要一段时间后 才会产生 具体多久还不确定
使用了相关BT软件：qBittorrent Enhanced Edition v4.6.2.10 (64-bit)、Tixati v3.19
And today I tried to close UDP opentracker and couldn't solve it Looks like it's not an application conflict.
It will take some time for the problem to arise, and it is uncertain how long it will take
Related torrent software was used: qBittorrent Enhanced Edition v4.6.2.10 (64-bit), Tixati v3.19

[github-actions]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

[lirener]

【problem solved】
This problem is caused by opentracker
And as long as someone else uses udp to connect once, a link will be generated. You must use the command in the routing
[conntrack -F] [echo / >/proc/net/nf_conntrack] After clearing all connections
Only then will this problem be solved. So it is not a BT tracker BUG. The author of opentracker has fixed it in the latest version, but many different devices have not yet made adaptation updates.

---

【问题已解决】
该问题是opentracker产生的
而且只要别人使用udp连接1次就会产生链路 必须在路由使用命令
【conntrack -F】【echo / >/proc/net/nf_conntrack】清除所有连接后
才会解决这个问题的产生 所以不是BT tracker的BUG opentracker的作者在最新版已经修复 但很多分歧设备还没做适配更新