Add `markForRouting(udp_socket: int)` to Android FFI to prevent packet loops about firezone HOT 5 CLOSED

I think the following idea is relevant here: #3343 (comment).

from firezone.

This would be a one-off callback from connlib -> JVM, probably wouldn't need to updateTunnelState?

from firezone.

This would be a one-off callback from connlib -> JVM

I think we should not do one-off callbacks. In fact, I think the only "callback" we should do is updateTunnelState. I am saying "callback" because I have this vision that it is not implemented as a callback but instead, the connlib interface is essentially a Stream<Item = State> that gets continuously read by client-specific crates (like connlib-android). These crates can then either use a callback or something else to talk across the FFI boundary¹.

We should really try to implement the clients such that they always respond to state updates. In this particular case, the Android app knows when it is creating a file descriptor (when it creates the new VPN service), it doesn't need to be told by connlib when to do that :)

The goal of what I linked above is that:

• connlib only ever emits its current state
• clients display that
• user input calls "commands" on the connlib session
• client state only changes as a result of a new connlib state

If we keep the data flow unidirectional like this, it will be very difficult to program bugs into the client! :)

from firezone.

@thomaseizinger Yeah that makes sense.

This is a platform-specific thing needed on Android for protecting the datagram socket for each channel that gets opened, not the file descriptor (we already call protect on that).

Apple's network stack already does this for us, and on Linux we can perform this directly with fwmark.

On Android however we can only do it on the JVM side of the boundary.

Would this mean issuing a state update from connlib -> JVM for each channel we need to open? That would be a no-op for the other platforms?

Maybe it'll help to start defining the schema for the state object connlib sends back. The UDP datagram socket could be an optional field sent to the JVM.

from firezone.

Ah I see! Once snownet is integrated, we only have two UDP file-descriptors, one for IP4 and one for IP6 but yes, we could make them part of the state so clients have access to them.

Maybe it'll help to start defining the schema for the state object connlib sends back. The UDP datagram socket could be an optional field sent to the JVM.

Unless we plan to emitting state updates prior to launching the tunnel, we should always have two defined as binding to the sockets is pretty much the very first thing we do.

from firezone.