[Bug]: pairing fails after a correct PIN when the inviter connected over IPv6 link-local — the joiner's return POST drops the %zone ([fe80::…]:14321 → no route to host)
维护者通常 2 天内回复
评估
这个 Issue 还没有评估数据。
描述
PAIR version
v0.1.1 (13b6811), all 14 services built from source with Go 1.25.5 (darwin/arm64); same behaviour expected from the release binaries (the code path is services/nvpair-cluster-manager/invite.go).
Operating system
macOS 26.5.2 on both nodes (inviter and joiner).
Hardware
Two Apple Mac mini M4 (16 GB) on one Wi-Fi LAN, IPv4 192.168.86.0/24 plus IPv6 link-local on en0.
Inference engine and model
Ollama 0.30.7 on the joiner (llama3.2:1b); not relevant to the bug.
What happened
cluster:invite-node {"address":"karen.local"} from the inviter returned a PIN and state:"pending"; the joiner received cluster:invite-received and answered cluster:respond-to-invite {inviteId, accept:true, pin} with the correct PIN — and the result was state:"failed". The joiner's log shows why: its completion/notify POST to the inviter used the inviter's IPv6 link-local address without the zone:
[nvpair-cluster-manager] INFO invite inv-9f69cc176d6c: completion failed: Post "http://[fe80::c16:bee4:c6a1:3fd]:14321/v1/cluster/pairing": dial tcp [fe80::c16:bee4:c6a1:3fd]:14321: connect: no route to host
[nvpair-cluster-manager] INFO invite inv-9f69cc176d6c: notify inviter fail attempt 1/3: ... (same, ×3)
fe80::/10 addresses are only routable with a scope (%en0); the inviter had reached the joiner over link-local (the hostname resolved to an IPv6 link-local first), the joiner took the remote address of that inbound connection as the inviter's address, and the zone was dropped when it was rendered back into a URL. Both nodes' /v1/cluster/pairing were reachable over IPv4 the whole time.
Expected
Either keep the zone when rendering a link-local address into the return URL ([fe80::…%25en0]), or prefer a global/IPv4 address from the inviter's advertised ips= list for the return path; at minimum surface the dial error in the respond-to-invite result instead of a bare state:"failed" after a correct PIN.
Steps to reproduce
- Two macOS nodes on one LAN with IPv6 link-local enabled (default), PAIR services running on both.
- On node A:
{"jsonrpc":"2.0","id":1,"method":"cluster:invite-node","params":{"address":"<node-B-hostname>.local"}}— where the name resolves to a link-local IPv6 first (askaren.localdid here:fe80::…then192.168.86.17). - On node B: answer
cluster:invite-receivedwithcluster:respond-to-inviteand the PIN shown on A. - Observe
state:"failed"and the log line above on B. - Repeat with
"address":"192.168.86.17"(IPv4 literal):state:"paired",nodes:get-initialshows two members on both sides.
Sanitized logs
Above; nothing else in either log around the failure. Happy to attach the full sanitizer bundle if useful.
Confirmations
- I searched existing issues (#1 mDNS source port, #3 Local Network permission, #44 multicast drops are adjacent; none covers the pairing return URL).
- I agree to follow the Code of Conduct.
- 主要语言
- Go
- 星标
- 1.6k
- 派生
- 277
- 平均合并
- 4 天 14 小时
- 30 天内合并 PR
- 31
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
NVIDIA/Personal-AI-Router 的其他 Issue
-
[Bug]: macOS privileged helper is signed as com.nvidia.nvpair, so its pinned code-signing requirement always fails ("Privileged helper setup incomplete")可能已有人在做 @Noah-Tervalon-Nvidia 于 2 天前认领。 未关闭
难度 4/5 1-2 天 新手友好度 18/100
NVIDIA/Personal-AI-Router#175 · 1 条评论 · 已指派 1 人 ·
维护者通常 2 天内回复
-
难度 5/5 一周以上 新手友好度 20/100
NVIDIA/Personal-AI-Router#165 ·
维护者通常 2 天内回复
-
bug
难度 4/5 3-5 天 新手友好度 46/100
NVIDIA/Personal-AI-Router#164 ·
维护者通常 2 天内回复
-
enhancement
难度 4/5 一周以上 新手友好度 12/100
NVIDIA/Personal-AI-Router#162 ·
维护者通常 2 天内回复
-
enhancement
难度 4/5 3-5 天 新手友好度 25/100
NVIDIA/Personal-AI-Router#154 · 1 条评论 ·
维护者通常 2 天内回复
查看 NVIDIA/Personal-AI-Router 的全部 Issue
相似的 Issue
-
needs_triage
难度 2/5 1-3 小时 新手友好度 70/100
维护者通常 2 天内回复
-
kind/bug
难度 2/5 1-3 小时 新手友好度 70/100
kubernetes-sigs/cluster-api-provider-ibmcloud#3023 · 1 条评论 ·
维护者通常 1 天内回复
-
[Bug]: message-level cache_control on chat messages is dropped, so Anthropic prompt caching never triggers可能已有人在做 @Atharva-Kanherkar 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 80/100
维护者通常 1 天内回复
-
documentation good first issue help wanted
难度 2/5 1-3 小时 新手友好度 90/100
eugenioenko/ttt#1000 ·
维护者通常 1 天内回复
-
bug needs-acceptance wg/developer-experience-ecosystem
难度 2/5 1-3 小时 新手友好度 82/100
vllm-project/semantic-router#5249 ·
维护者通常 1 天内回复