Add remote_addr field to lightning_net_tokio::setup_outbound#4372
Add remote_addr field to lightning_net_tokio::setup_outbound#4372tankyleo wants to merge 1 commit intolightningdevkit:mainfrom
remote_addr field to lightning_net_tokio::setup_outbound#4372Conversation
tankyleo
commented
Feb 2, 2026
When `setup_outbound` was used to setup a connection proxied over Tor, it previously set `remote_addr` to the address of the Tor proxy, and not the address of the peer on the other side of the stream. The address of the Tor proxy was assigned to the `PeerDetails::socket_address` for that peer in `PeerManager::list_peers`, and if it was not a private IPV4 or IPV6 address, it was also reported to the peer in our init message. Here we ask callers of `setup_outbound` to pass a `remote_addr` separately from the `StdTcpStream`. `connect_outbound` sets this new `remote_addr` parameter to `get_addr_from_stream`, and `tor_connect_outbound` passes its own `addr` parameter directly to `remote_addr`. Notably, Onion V3 addresses will now appear in `PeerManager::list_peers` for outbound Tor connections to Onion V3 services made using `tor_connect_outbound`, and will be reported to the peer in our init message. While this adds a new parameter to the public `fn setup_outbound` function, this closely mirrors the existing public method `PeerManager::new_outbound_connection`.
|
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
|
Fixes the issues @jharveyb reported in lightningdevkit/ldk-node#778 |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4372 +/- ##
==========================================
+ Coverage 85.98% 86.00% +0.01%
==========================================
Files 156 156
Lines 102641 102694 +53
Branches 102641 102694 +53
==========================================
+ Hits 88258 88317 +59
+ Misses 11873 11869 -4
+ Partials 2510 2508 -2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
tnull
left a comment
There was a problem hiding this comment.
Generally makes sense. One question, otherwise CI seems unhappy right now.
| /// [`PeerManager::list_peers`]: lightning::ln::peer_handler::PeerManager::list_peers | ||
| pub fn setup_outbound<PM: Deref + 'static + Send + Sync + Clone>( | ||
| peer_manager: PM, their_node_id: PublicKey, stream: StdTcpStream, | ||
| remote_addr: Option<SocketAddress>, |
There was a problem hiding this comment.
Hmm, rather than adding this on the generic setup_outbound, would it make sense to refactor this to be an setup_outbound_internal and offer two setup_outbound and setup_outbound_tor variants that do the right (tm) thing for the user? Or, put differently, for non-Tor users this remote_addr argument might be confusing?
TheBlueMatt
left a comment
There was a problem hiding this comment.
Agree with @tnull otherwise lgtm