[client] Supress ICE signaling in case of force relay setting#5820
[client] Supress ICE signaling in case of force relay setting#5820
Conversation
When NB_FORCE_RELAY is enabled, skip WorkerICE creation entirely, suppress ICE credentials in offer/answer messages, disable the periodic ICE candidate monitor, and fix isConnectedOnAllWay to only check relay status so the guard stops sending unnecessary offers.
…tials Track whether the remote peer includes ICE credentials in its offers/answers. When remote stops sending ICE credentials, skip ICE listener dispatch, suppress ICE credentials in responses, and exclude ICE from the guard connectivity check. When remote resumes sending ICE credentials, re-enable all ICE behavior.
… transition Fix nil pointer dereference in signalOfferAnswer when SessionID is nil (relay-only offers). Close stale ICE agent immediately when remote peer stops sending ICE credentials to avoid traffic black-hole during the ICE disconnect timeout.
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
client/internal/peer/conn.go (1)
735-749:⚠️ Potential issue | 🟠 MajorRequire at least one transport when remote ICE is disabled.
Once
RemoteICESupported()is false, this path skips the ICE gate. If relay is also unsupported for the peer, the function now falls through totrue, so the guard stops re-offering even though there is no working transport.💡 Suggested fix
func (conn *Conn) isConnectedOnAllWay() (connected bool) { @@ - // For non-forced platforms: check ICE connection status only if remote peer supports ICE - if conn.handshaker.RemoteICESupported() { + relaySupported := conn.workerRelay.IsRelayConnectionSupportedWithPeer() + + // For non-forced platforms: check ICE connection status only if remote peer supports ICE. + // If the remote disabled ICE, relay has to be available instead. + if conn.handshaker.RemoteICESupported() { if conn.statusICE.Get() == worker.StatusDisconnected && !conn.workerICE.InProgress() { return false } + } else if !relaySupported { + return false } // If relay is supported with peer, it must also be connected - if conn.workerRelay.IsRelayConnectionSupportedWithPeer() { + if relaySupported { if conn.statusRelay.Get() == worker.StatusDisconnected { return false } }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@client/internal/peer/conn.go` around lines 735 - 749, The current transport-readiness check incorrectly returns true when RemoteICESupported() is false and the peer also doesn't support relay; update the logic in the readiness function that contains conn.handshaker.RemoteICESupported(), conn.statusICE, and conn.workerRelay.IsRelayConnectionSupportedWithPeer() so that when RemoteICESupported() is false you still require at least one working transport: if relay is not supported with the peer (workerRelay.IsRelayConnectionSupportedWithPeer() == false) then return false; otherwise continue to validate the relay status as currently done (i.e., require statusRelay != StatusDisconnected).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@client/internal/peer/conn.go`:
- Around line 735-749: The current transport-readiness check incorrectly returns
true when RemoteICESupported() is false and the peer also doesn't support relay;
update the logic in the readiness function that contains
conn.handshaker.RemoteICESupported(), conn.statusICE, and
conn.workerRelay.IsRelayConnectionSupportedWithPeer() so that when
RemoteICESupported() is false you still require at least one working transport:
if relay is not supported with the peer
(workerRelay.IsRelayConnectionSupportedWithPeer() == false) then return false;
otherwise continue to validate the relay status as currently done (i.e., require
statusRelay != StatusDisconnected).
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 97653c97-31db-42e6-973f-df416c625882
📒 Files selected for processing (6)
client/internal/engine.goclient/internal/peer/conn.goclient/internal/peer/env.goclient/internal/peer/guard/sr_watcher.goclient/internal/peer/handshaker.goclient/internal/peer/signaler.go



Describe your changes
Suppress ICE signaling and periodic offers in force-relay mode
When NB_FORCE_RELAY is enabled, skip WorkerICE creation entirely,
suppress ICE credentials in offer/answer messages, disable the
periodic ICE candidate monitor, and fix isConnectedOnAllWay to
only check relay status so the guard stops sending unnecessary offers.
Issue ticket number and link
Stack
Checklist
Documentation
Select exactly one:
Docs PR URL (required if "docs added" is checked)
Paste the PR link from https://github.com/netbirdio/docs here:
https://github.com/netbirdio/docs/pull/__
Summary by CodeRabbit