NetworkManager.DisconnectReason is always Empty String

[Reag]

Description

The variable NetworkManager.DisconnectReason is always empty. The code that sets this variable in the NetworkManager is never activated with UTP.

Reproduce Steps

1. Build a new project with netcode
2. Place a break point on line 47 of DisconnectReasonMessage.cs, the only function that accesses NetworkManager.DisconnectReason
3. Perform various Disconnects (connection interruption, timeout, client stopped, ect)

Actual Outcome

Breakpoint that sets the DisconnectReason is never tripped, leaving the variable as empty string

Expected Outcome

The variable will get some information about why the server disconnected the client

Environment

• OS: Windows 12
• Unity Version: 2021.3.12f1
• Netcode Version: 1.2.0
• Unity Transport Version: 1.3.0

[NoelStephensUnity]

@Reag
I think the property name is possibly misleading. The NetworkManager.DisconnectReason is something you would set if you are using connection approval.

I am going to mark this as a feature request since I can see a few spots where we could populate this string with known disconnection reasons (time out, client stopped/disconnected itself, and I think we might be able to determine if the transport just loses the connection...which would be a "connection interruption").

[Reag]

Would definitely be useful. The tooltip from Intellisense lead me to believe that this property would always be populated with a disconnect reason.

Both of my reports stem from a few hours of trying to track down the reason for a client disconnect. It turns out that after I fixed up a bad RPC, the scene had no network event traffic for idle clients. As, for some reason, the heartbeat in the project was misconfigured to be longer than the timeout, it lead to the clients disconnecting. However, I had no way to tell this (I only recieved a generic disconnect message from the console), and spent a few hours with wireshark and the unity debugger as a result.

Some kind of way of telling 'why' a client disconnected would definitely be a useful feature for me as a developer using this feature.

[NoelStephensUnity]

@Reag
Yikes! We already know this area needs improvement and don't want users spending several hours figuring out things like this.
I have marked this as a feature request and as we are planning our 2023 roadmap we will definitely be looking at things just like this.
Glad to hear you got past the issue... sorry you had to spend a few hours figuring it out.

[cantaspinar]

I am trying to use this with the connection approval process:

private void ApprovalCheck(NetworkManager.ConnectionApprovalRequest request, NetworkManager.ConnectionApprovalResponse response) { response.Approved = false; response.Reason = "Go away!"; }

My client indeed gets disconnected but the NetworkManager.Singleton.DisconnectReason returns an empty string on the client side. Am I missing sth?

Update: This happens when using Facepunch Transport. If I use Unity Transport, it works fine.

[NoelStephensUnity]

@cantaspinar
Is this the transport you are using?
If so, then it looks like it bypasses the NGO disconnect process if you are using that specific API...so I am not sure setting that in the approval check will have any impact.

If that is the third party library you are using, then you might file a github issue there.
If that is not the third party library you are using, then you could post it here and I could take a look when time allows.

[cantaspinar]

@NoelStephensUnity

I have been using the community facepunch transport.

issue

I have also tried the other community transport called SteamNetworkingSockets. Same issue with that one as well. :/

issue

Btw, I am just selecting the transport in the Netcode's NetworkManager component. Not using a custom NetworkManager implementation. I have created 2 issues

[NoelStephensUnity]

Ahh... sorry about that misunderstanding.
Looking at the community facepunch transport, the only thing I can think of is that the connection is closed before the message is actually sent.

So, you are checking the client-side's NetworkManager.DisconnectReason and that is either null or String.Empty when the client is not approved and disconnected?

[cantaspinar]

Ahh... sorry about that misunderstanding. Looking at the community facepunch transport, the only thing I can think of is that the connection is closed before the message is actually sent.

So, you are checking the client-side's NetworkManager.DisconnectReason and that is either null or String.Empty when the client is not approved and disconnected?

That is correct. It also appears like both transports does not terminate the connection properly? Facepunch goes to a timeout and the SteamNetworkingSockets gives this error: Can't disconect client, client not connected, clientId: XXXXXX