client: auto-join authorized multicast groups on connect with no args#3864
Merged
Conversation
elitegreg
approved these changes
Jun 10, 2026
When 'doublezero connect multicast' is invoked without groups, look up the caller's AccessPass (UNSPECIFIED-first, then exact IP) and auto-join every authorized group: publish to mgroup_pub_allowlist and subscribe to mgroup_sub_allowlist. Stale allowlist pubkeys (deleted groups) are dropped, and an empty allowlist is a no-op success.
Cover the no-args auto-join path: publish + subscribe from both allowlists, empty-allowlist no-op, stale-pubkey filtering, and parse_dz_mode accepting multicast with no groups.
Authorize a client for publishing on one group and subscribing on another, run 'doublezero connect multicast' with no arguments, and assert the onchain Multicast user auto-joins exactly those publish/subscribe groups.
juan-malbeclabs
force-pushed
the
jo/multicast-connect-autojoin-accesspass
branch
from
09f3bfc to
01d503f
Compare
groupPubKeyByCode did a single GetProgramData read right after `multicast group create`, racing ahead of ledger propagation and intermittently failing with "group not found". Wrap the lookup in require.Eventually, matching the polling pattern used elsewhere in this test.
ben-dz
added a commit
that referenced
this pull request
Jun 10, 2026
…3870) ## Summary of Changes - Reverts #3861 (`105d9035`): `doublezero connect ibrl` no longer auto-flips to `IBRLWithAllocatedIP` when the daemon's default-route source is an RFC1918 address. - The heuristic misfires on hosts behind 1:1 NAT — e.g. the chi-dn devnet QA hosts — where plain IBRL works. After today's daily deploy picked up the change, those hosts silently connected as a different user type with an allocated `dz_ip`, and devnet QA `TestQA_MultiTunnel/unicast_connectivity` failed deterministically (route waits expect public-IP routes). - Beyond QA, the same silent user-type change would hit any NAT'd production client on the next release, so the detection needs to distinguish 1:1 NAT from address-translating NAT before re-landing. - Removes the `behind_nat` field from the daemon's `/v2/status` response and the CLI's NAT-aware connect path; explicit `-a` / `--client-ip` behavior is unchanged. - Targeted for a standalone v0.27.1 release (v0.27.0 is already tagged with the feature included). ## Diff Breakdown | Category | Files | Lines (+/-) | Net | |--------------|-------|--------------|-------| | Core logic | 2 | +19 / -163 | -144 | | Scaffolding | 9 | +3 / -52 | -49 | | Tests | 2 | +1 / -117 | -116 | | Docs | 1 | +3 / -0 | +3 | | **Total** | 14 | +26 / -332 | -306 | Pure revert: net -306 lines, mostly removing the NAT-detection logic and its tests. <details> <summary>Key files (click to expand)</summary> - `client/doublezero/src/command/connect.rs` — remove the behind-NAT auto-allocate decision and its tests - `client/doublezerod/internal/runtime/clientip.go` — `DiscoverClientIP` no longer reports `behindNAT`; restores the pre-#3861 signature </details> ## Testing Verification - `cargo test -p doublezero`: 145 tests pass (includes the connect command suite the revert touches). - `go test ./client/doublezerod/internal/runtime/... ./client/doublezerod/internal/manager/...`: pass. - `make rust-lint` clean in the dev container. - The revert auto-merged around #3864 (auto-join multicast groups), which landed in `connect.rs` afterward; only `CHANGELOG.md` needed manual resolution (v0.27.0 section kept as shipped history, revert noted under Unreleased).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary of Changes
doublezero connect multicastinvoked with no groups now auto-joins every multicast group authorized in the caller's AccessPass: it publishes tomgroup_pub_allowlistand subscribes tomgroup_sub_allowlist. The AccessPass is resolved via the existingGetAccessPassCommand, which already tries the shared dynamic-seat pass (UNSPECIFIED/0.0.0.0PDA) first and falls back to the exact client-IP pass.--publish/--subscribeand the legacy positional syntax are unchanged.Diff Breakdown
Mostly tests; the core change is a single new branch in
execute_multicastplus relaxingparse_dz_mode.Key files (click to expand)
client/doublezero/src/command/connect.rs—parse_dz_modeaccepts multicast with no groups (empty vectors instead of erroring);execute_multicastderives pub/sub group pubkeys from the AccessPass allowlists when none are passed, filters stale pubkeys, and returns whether anything was provisioned so the success footer is conditional.CHANGELOG.md— Client entry for the new auto-join behavior.Testing Verification
command::connect::tests: auto-join publishes + subscribes from both allowlists; empty allowlist is a no-op with no onchain calls; stale allowlist pubkeys are filtered out;parse_dz_modeyields empty groups for no-args multicast.command::connect::testsmodule passes (42 tests); clippy clean with-Dclippy::all -Dwarnings.