允许使用通过非官方 Planet ID 生成的 Planet 文件 / Allow Planet files generated through unofficial Planet IDs
f0re1gnKey opened this issue · 20 comments
planet文件使用最新的ztncui生成 https://github.com/kmahyyg/ztncui-aio
ZeroTier 1.10.6 Linux和Windows均可正常使用的planet文件
导入Zerotier Fix提示 planet 文件格式错误,文件导入和url导入均可稳定复现
你使用的 APP 版本和 Android 版本分别是什么?
检查了下你提到的 repo,这个 repo 目前生成的 planet 文件默认使用的是随机的 Planet ID(cmd/mkworld/main.go#L54)。而目前版本的 Zerotier Fix 只接受使用 Zerotier 官方定义的 ZT_WORLD_ID_EARTH
作为 Planet ID 的 Planet 文件。稍后我搞一个接触限制的版本吧。
你使用的 APP 版本和 Android 版本分别是什么?
APP 1.0.9
Android 10
检查了下你提到的 repo,这个 repo 目前生成的 planet 文件默认使用的是随机的 Planet ID(cmd/mkworld/main.go#L54)。而目前版本的 Zerotier Fix 只接受使用 Zerotier 官方定义的
ZT_WORLD_ID_EARTH
作为 Planet ID 的 Planet 文件。稍后我搞一个接触限制的版本吧。
看了一下ZerotierFix的代码,似乎是判断Planet文件Header的时候把官方的Planet ID也一起放在里面了
ztncui支持自定义Planet ID,或许可以直接写官方Planet ID生成适合的文件,官方ID是多少
似乎我自己找到了
https://github.com/zerotier/ZeroTierOne/blob/c6f07ee19fd78acd8a04700388684c09a1cb604c/node/World.hpp#L46-L53
0x08, (byte) 0xea, (byte) 0xc9, 0x0a
看了一下ZerotierFix的代码,似乎是判断Planet文件Header的时候把官方的Planet ID也一起放在里面了
是的。主要是之前实现自定义 Planet 文件的时候我调研了下现有的生成方式,看到基本都是修改官方 mkworld.cpp
后生成的,而这个逻辑下 Planet ID 是写死为 ZT_WORLD_ID_EARTH
的。由于目前没有官方的说明(可能是我没找到),所以我也不是很确定这个 ID 是否是可以随意设置的。
不过考虑到使用自定义 ID 也可以正确运行。此外 Moon 的 ID 是默认设置为 Zt 地址的数值形式的,所以之后版本应该不会再强制要求为 ZT_WORLD_ID_EARTH
了。
那么当前的解决办法是什么呢 ?
@v808comd 近期应该会发布一个版本来更新官方的 1.12.1 核心。如果比较急的话也可以直接安装 Action 实时构建的版本。
@v808comd 近期应该会发布一个版本来更新官方的 1.12.1 核心。如果比较急的话也可以直接安装 Action 实时构建的版本。
Action构建的貌似还是1.10.6的....
@GreatMichaelLee 是的,因为我还没做😆。Action 上目前是包含了解决这个 Issue 的 Commit。
大佬加油,据说1.12.1 对Network performance 有20%-30%提升
提示1.12.1有坑,建议等1.12.2
提示1.12.1有坑,建议等1.12.2
啥坑?我用的挺好
提示1.12.1有坑,建议等1.12.2
啥坑?我用的挺好
自建planet才会遇到的坑,其他使用方式没有问题
zerotier/ZeroTierOne#2114
提示1.12.1有坑,建议等1.12.2
啥坑?我用的挺好
自建planet才会遇到的坑,其他使用方式没有问题
zerotier/ZeroTierOne#2114
我就是轻量云自建啊?
提示1.12.1有坑,建议等1.12.2
啥坑?我用的挺好
自建planet才会遇到的坑,其他使用方式没有问题
zerotier/ZeroTierOne#2114我就是轻量云自建啊?
那么,请问issue看了吗,您是否对issue的真实性有怀疑呢?如果有,请在issue里提出,而不是在这里和我扯有没有问题
其他人可以复现,而你不能复现,只能说明你部署的时候已经是是作者修复过memberlist的版本,或者你部署的环境有差异。无论哪种情况都说明你的结论没有意义,除非你推翻issue和commit
看了下 Issue 应该是 Controller 相关的问题,Fix 这边更新应该还好,不会有太大影响
提示1.12.1有坑,建议等1.12.2
啥坑?我用的挺好
自建planet才会遇到的坑,其他使用方式没有问题
zerotier/ZeroTierOne#2114我就是轻量云自建啊?
那么,请问issue看了吗,您是否对issue的真实性有怀疑呢?如果有,请在issue里提出,而不是在这里和我扯有没有问题
其他人可以复现,而你不能复现,只能说明你部署的时候已经是是作者修复过memberlist的版本,或者你部署的环境有差异。无论哪种情况都说明你的结论没有意义,除非你推翻issue和commit
我不知道你用的controller API是用的直接自己写的东西调用还是什么,我用的是ztncui, 你觉得我会不知道没有issue吗?有问题自己多看看有没有其他解决方案,看看是不是已经用其他方式可以解决,而不是因噎废食,居高临下颐指气使。
key-networks/ztncui#123 (comment)
提示1.12.1有坑,建议等1.12.2
啥坑?我用的挺好
自建planet才会遇到的坑,其他使用方式没有问题
zerotier/ZeroTierOne#2114我就是轻量云自建啊?
那么,请问issue看了吗,您是否对issue的真实性有怀疑呢?如果有,请在issue里提出,而不是在这里和我扯有没有问题
其他人可以复现,而你不能复现,只能说明你部署的时候已经是是作者修复过memberlist的版本,或者你部署的环境有差异。无论哪种情况都说明你的结论没有意义,除非你推翻issue和commit我不知道你用的controller API是用的直接自己写的东西调用还是什么,我用的是ztncui, 你觉得我会不知道没有issue吗?有问题自己多看看有没有其他解决方案,看看是不是已经用其他方式可以解决,而不是因噎废食,居高临下颐指气使。 key-networks/ztncui#123 (comment)
so?我说1.12.1有问题,这个事实是否存在?他的memberlist是不是因为改动而导致大量基于controller的应用有问题。1.12.0问题更多,已经修过一次了,我都懒得跟你扯
你说的其他解决方案就是在ztncui提issue然后坐等修复吗,可笑可笑
ztncui已经是我上一个用过的方案,我现在有更好的,什么是因噎废食?是你井底之蛙吧
就你会提issue?sinamics/ztnet#102 (comment)
提示1.12.1有坑,建议等1.12.2
啥坑?我用的挺好
自建planet才会遇到的坑,其他使用方式没有问题
zerotier/ZeroTierOne#2114我就是轻量云自建啊?
那么,请问issue看了吗,您是否对issue的真实性有怀疑呢?如果有,请在issue里提出,而不是在这里和我扯有没有问题
其他人可以复现,而你不能复现,只能说明你部署的时候已经是是作者修复过memberlist的版本,或者你部署的环境有差异。无论哪种情况都说明你的结论没有意义,除非你推翻issue和commit我不知道你用的controller API是用的直接自己写的东西调用还是什么,我用的是ztncui, 你觉得我会不知道没有issue吗?有问题自己多看看有没有其他解决方案,看看是不是已经用其他方式可以解决,而不是因噎废食,居高临下颐指气使。 key-networks/ztncui#123 (comment)
我好心提醒开发者,1.12.1 有坑,可以等待马上要发布的1.12.2避免不必要的兼容性修改,官方也承认问题存在并且已经commit了新代码,写入了1.12.2 milestone,你倒好在这里逼逼赖赖什么,拿已经修过的ztncui说1.12.1没问题,我看你才是有问题
@GreatMichaelLee @f0re1gnKey 感谢二位的 Issue 与对 Zerotier core 1.12.1 版本 BUG 的提醒。也请两位停止在此 Issue 下继续与这个 Issue 主题无关的讨论。在开源社区请友善讨论,别太情绪化。
关于 1.12.1 的 Controller API 变更问题,鉴于官方主动修复了输出格式,那说明的确不是官方计划修改 API 而确实是 BUG。不过我目前评估感觉这点对 Zerotier Fix 的影响比较有限,毕竟 Fix 还没有涉及 Controller 的部分。不过鉴于确实是个已知且有较大影响的 BUG,所以新版本还是晚几天再发布,我自己先测试下。
另外,鉴于 Issue 相关的问题已经得到了修复,因此本 Issue 将会关闭。下个版本将会包含这个修复。如果急需此功能也可以下载 Action 中的 nightly build。