[macOS] Connectivity lost and never restored due to invalidated selected_entry

[rafael-oliveira-edge]

Summary

When using libjuice on macOS, connectivity is lost shortly after establishing a connection and never recovers. This issue of losing connection shortly does not occur on Linux or Windows.

Details

The issue occurs when the connection temporarily drops and the following block in agent.c is executed:

if (nominated_pair && nominated_pair->state == ICE_CANDIDATE_PAIR_STATE_FAILED) {
    JLOG_WARN("Lost connectivity");
    agent_change_state(agent, JUICE_STATE_FAILED);
    atomic_store(&agent->selected_entry, NULL); // disallow sending
    return 0;
}

This sets the internal state to JUICE_STATE_FAILED and clears the selected_entry, which disables sending.

However, if the ICE connection is shortly re-established and the agent transition back to JUICE_STATE_COMPLETED — but the selected_entry is never restored.

As a result:

• The connection remains unusable for sending even though it reports a completed state.
• No packets can be sent through the agent anymore.
• This does not happen on Linux or Windows, only on macOS.
• The issue occurs even if no traffic is being sent — the connection still fails quickly.

Expected Behavior

After ICE reconnects and the state returns to JUICE_STATE_COMPLETED, the agent should restore a valid selected_entry so that data can be sent again?

Platform

• OS: macOS
• libjuice version: 1.6.0
• Steps to reproduce:
  1. Run a libjuice-based agent on macOS.
  2. Establish connection.
  3. Wait for a brief period (connection drops).
  4. Connection transitions to FAILED and then back to COMPLETED.
  5. Sending data fails due to selected_entry == NULL.

[rafael-oliveira-edge]

Just to make make it clearer. I have a udp server, running libjuice in a linux box. If I use the Mac os client, the linux server, keeps losing connectivity to the mac os client. The linux and the windows clients, do not trigger these behaviour on the linux server.

I am running the clients and the server in a local network. Below is a log of the server, after connecting the to mac os client. The states are the values in the juice_state_t enum, I am printing then in the on_state_changed calback:

22:35:57 WARN ibcs_proxy.c:63: State changed to 1
22:35:57 WARN ibcs_proxy.c:63: State changed to 2
22:35:58 WARN ibcs_proxy.c:63: State changed to 3
22:35:58 WARN ibcs_proxy.c:63: State changed to 4
22:36:13 WARN agent.c:1031: Lost connectivity
22:36:13 WARN ibcs_proxy.c:63: State changed to 5
22:36:13 WARN agent.c:1031: Lost connectivity
22:36:17 WARN agent.c:1031: Lost connectivity
22:36:23 WARN ibcs_proxy.c:63: State changed to 4

[paullouisageneau]

This is not just about restoring a valid selected_entry so you can send again, something bad is happening with the pair state in the first place. Could you please post the verbose log?

[rafael-oliveira-edge]

This is the log from the server:

11:24:48 DEBUG agent.c:849: STUN entry 1: Sending request to IPV6-1 client (6 retransmissions left)
11:24:48 DEBUG agent.c:1581: Sending STUN Binding request
11:24:48 DEBUG agent.c:779: Received STUN datagram from IPV6-1 client
11:24:48 DEBUG agent.c:1430: Received STUN Binding success response from peer
11:24:48 DEBUG agent.c:1486: Candidate pair check succeeded
11:24:48 DEBUG agent.c:1501: Got a nominated pair (controlled)
11:24:48 DEBUG agent.c:1040: New selected and nominated pair
11:24:48 INFO agent.c:1157: Changing state to completed

11:24:48 DEBUG agent.c:849: STUN entry 3: Sending request to IPV6-2 client (6 retransmissions left)
11:24:48 DEBUG agent.c:1581: Sending STUN Binding request
11:24:48 DEBUG agent.c:779: Received STUN datagram from IPV6-1 client
11:24:48 DEBUG agent.c:1430: Received STUN Binding success response from peer
11:24:48 DEBUG agent.c:1476: Candidate pair check failed (non-symmetric source address in response)

After some time:

11:25:07 DEBUG agent.c:779: Received STUN datagram from IPV6-3 client
11:25:07 DEBUG agent.c:2276: Obtained a new remote reflexive candidate, priority=0
11:25:07 DEBUG agent.c:1430: Received STUN Binding success response from peer
11:25:07 DEBUG agent.c:1476: Candidate pair check failed (non-symmetric source address in response)
11:25:07 WARN agent.c:1031: Lost connectivity
11:25:07 INFO agent.c:1157: Changing state to failed

11:25:08 DEBUG agent.c:779: Received STUN datagram from IPV6-1 client
11:25:08 DEBUG agent.c:2606: STUN entry 1 pair matching incoming address
11:25:08 DEBUG agent.c:1339: Received STUN Binding request
11:25:08 DEBUG agent.c:1581: Sending STUN Binding response
11:25:08 DEBUG agent.c:1422: Triggered pair check
11:25:08 INFO agent.c:1157: Changing state to completed

After that, even if the state is completed, I can't send data.

It seems that macOS (especially recent versions) might change the source address used in UDP NAT traversal, possibly due to its use of IPv6 privacy extensions or changes in its IP stack.

When on macOS, the server also reports:

13:09:26 WARN agent.c:803: Received a datagram from unknown address, ignoring

[rafael-oliveira-edge]

I do not know if this is the best way to solve the problem, but I've added a workaround near line 1076 in agent.c

       //Enable keepalive for the entry of the nominated pair
	if (nominated_entry &&
	    nominated_entry->state != AGENT_STUN_ENTRY_STATE_SUCCEEDED_KEEPALIVE) {
		nominated_entry->state = AGENT_STUN_ENTRY_STATE_SUCCEEDED_KEEPALIVE;
		agent_arm_keepalive(agent, nominated_entry);
                //workaround
		atomic_store(&agent->selected_entry, nominated_entry);
	}

I've tested and it seems to work, altough it causes some failures before the entry being validated again.

[rafael-oliveira-edge]

Sorry for bothering you. But do you have any updates about this issue?

[paullouisageneau]

I'm still not totally sure of what's happening here. Obviously macOS does something fishy with addresses, and the ICE spec explicitly says candidates with non-symmetric addresses must be marked as failed. IPv6 privacy extensions should not cause this kind of behavior.

The workaround in itself is not really acceptable because the state still goes to failed and back to connected. A mitigation could be to prevent marking the candidate as failed after the initial check.

[paullouisageneau]

Please test with #306 that the state does not go to failed.

[rafael-oliveira-edge]

I've made a few tests and it seems to be working properly now. Thank you very much!