[GH-ISSUE #1932] client/server/server.go->Status() returns connected when WiFi Dropouts #3759

Closed
opened 2026-08-05 00:54:10 -04:00 by saavagebueno · 5 comments
Owner

Originally created by @hurricanehrndz on GitHub (May 6, 2024).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/1932

Describe the problem

client/server/server.go->Status() returns a status connected when WiFi is suddenly disconnected this contradicts the output of netbird status that accurately reflects the connection state

This results in the menubar/systray item inaccurately reflecting the connection state, is this oversight or an actual design decission?

To Reproduce

Steps to reproduce the behavior:
On macOS

  1. Connect
  2. Turn off WiFi
  3. Icon indicates I am successfully connected when it is impossible

Expected behavior

Icon should accurately reflect the connection state

Are you using NetBird Cloud?
Nope

NetBird version
0.27.3

NetBird status -d output:

NA

Originally created by @hurricanehrndz on GitHub (May 6, 2024). Original GitHub issue: https://github.com/netbirdio/netbird/issues/1932 **Describe the problem** [client/server/server.go->Status() ](https://github.com/netbirdio/netbird/blob/main/client/server/server.go#L597) returns a status connected when WiFi is suddenly disconnected this contradicts the output of `netbird status` that accurately reflects the connection state This results in the menubar/systray item inaccurately reflecting the connection state, is this oversight or an actual design decission? **To Reproduce** Steps to reproduce the behavior: On macOS 1. Connect 2. Turn off WiFi 3. Icon indicates I am successfully connected when it is impossible **Expected behavior** Icon should accurately reflect the connection state **Are you using NetBird Cloud?** Nope **NetBird version** 0.27.3 **NetBird status -d output:** NA
saavagebueno added the triage-needed label 2026-08-05 00:54:10 -04:00
Author
Owner

@mlsmaycon commented on GitHub (May 7, 2024):

@hurricanehrndz, the connected status has the following behavior:

  1. connection to the management and signal servers: they are handled by the grpc client and have a 10s timeout; this may cause an invalid status during this timeout
  2. P2P connections are not considered in the status response; they are additional to the management/signal status

If the status is not updating after a few seconds, that's an issue.

We are working on a network monitor, https://github.com/netbirdio/netbird/pull/1904, which will respond to network changes, especially the ones that touch the default gateway.

<!-- gh-comment-id:2097785159 --> @mlsmaycon commented on GitHub (May 7, 2024): @hurricanehrndz, the connected status has the following behavior: 1. connection to the management and signal servers: they are handled by the grpc client and have a 10s timeout; this may cause an invalid status during this timeout 2. P2P connections are not considered in the status response; they are additional to the management/signal status If the status is not updating after a few seconds, that's an issue. We are working on a network monitor, https://github.com/netbirdio/netbird/pull/1904, which will respond to network changes, especially the ones that touch the default gateway.
Author
Owner

@hurricanehrndz commented on GitHub (May 8, 2024):

Thanks for the info, internal state is in server is never updated when connection to Signal or Management endpoint is terminated. Not sure if it should though

<!-- gh-comment-id:2100581221 --> @hurricanehrndz commented on GitHub (May 8, 2024): Thanks for the info, internal state is in server is never updated when connection to Signal or Management endpoint is terminated. Not sure if it should though
Author
Owner

@hurricanehrndz commented on GitHub (May 13, 2024):

I will attempt to test with the network monitor and report my findings

<!-- gh-comment-id:2108166709 --> @hurricanehrndz commented on GitHub (May 13, 2024): I will attempt to test with the network monitor and report my findings
Author
Owner

@hurricanehrndz commented on GitHub (May 14, 2024):

Network monitor will not work in our testing. It does too much and creates more issues than it helps solves. I maybe able to work around it, if I can change https://github.com/netbirdio/netbird/blob/main/client/server/server.go#L615 to optionally run probes.

<!-- gh-comment-id:2111023407 --> @hurricanehrndz commented on GitHub (May 14, 2024): Network monitor will not work in our testing. It does too much and creates more issues than it helps solves. I maybe able to work around it, if I can change https://github.com/netbirdio/netbird/blob/main/client/server/server.go#L615 to optionally run probes.
Author
Owner

@hurricanehrndz commented on GitHub (May 17, 2024):

Never mind, network monitor does help

<!-- gh-comment-id:2118395098 --> @hurricanehrndz commented on GitHub (May 17, 2024): Never mind, network monitor does help
Sign in to join this conversation.
No Label triage-needed
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#3759