Skip to content

use netlink events to emit lighthouse updates instead of a timer - #1477

Closed
JackDoan wants to merge 1 commit into
masterfrom
update-lh-on-netlink-addr
Closed

use netlink events to emit lighthouse updates instead of a timer#1477
JackDoan wants to merge 1 commit into
masterfrom
update-lh-on-netlink-addr

Conversation

@JackDoan

@JackDoan JackDoan commented Sep 9, 2025

Copy link
Copy Markdown
Collaborator

This needs to be

  • confined to Linux (afaik Android will kill you if you try to even touch netlink)
  • made configurable
  • less log spammy
  • do we still need to poke the lh every so often to make punchy work?
  • debounced

@nbrownus

Copy link
Copy Markdown
Collaborator

The main reason to stay in communication with a lighthouse is to learn about roaming real underlay addresses which might be opaque to the client.

Real underlay address changes are learned by simply receiving a properly crafted/encrypted packet though, so as long as the client sends encrypted packets on some regular cadence, we can squash the host update traffic.

Generally I would rely on test packets for this behavior but we made a change recently to reduce the amount of paperwork a nebula mesh has to deal with. If we are receiving traffic from the lighthouse then the tunnel is declared alive and we will never initiate a test packet to it. The only time we would send a test packet to a lighthouse is if we haven't sent or received a message from them within a 5 second period (by default) so we likely would want to adjust this to send test packets regardless of rx traffic.

@JackDoan

Copy link
Copy Markdown
Collaborator Author

The main reason to stay in communication with a lighthouse is to learn about roaming real underlay addresses which might be opaque to the client.

oof I forgot about NAT 😢

Real underlay address changes are learned by simply receiving a properly crafted/encrypted packet though, so as long as the client sends encrypted packets on some regular cadence, we can squash the host update traffic.

Generally I would rely on test packets for this behavior but we made a change recently to reduce the amount of paperwork a nebula mesh has to deal with. If we are receiving traffic from the lighthouse then the tunnel is declared alive and we will never initiate a test packet to it. The only time we would send a test packet to a lighthouse is if we haven't sent or received a message from them within a 5 second period (by default) so we likely would want to adjust this to send test packets regardless of rx traffic.

yeah I like this approach

@JackDoan JackDoan closed this Oct 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants