Hi, I'm having a couple of issues trying to proxy UDP flows using App Proxy Provider (Specifically I'm using NETransparentProxyProvider) I'm using iperf3 to test the UDP flows: -This command is executed in the client: iperf3 -c 192.168.100.9 -p 5011 -u -This command is executed in the backend: iperf3 -s -p 5011
I observe two problems: -Once the first set of bytes are received from the backend and are written to the flow, then there are not outgoing bytes read from the flow to be sent to the backend. -But the most significant issue is that all the subsequent flows are not received in the AppProxyProvider. The provider went to a bad state and the only option is to kill the process to start it again.
In my code the AppProxyProvider is implemented with Objective C and there is a server that is the actual component that connects to the backend. (client->server->backend) But in order to figure out what is wrong I implemented a simple App Proxy Provider for UDP flows in swift using NWConnection API. So in this case there is no any server (client->backend)
When the App Proxy is executed (with the proper setting to match the UDP flows with 192.168.100.9) the UDP flow is properly open in the client and backend. Then the datagrams are read from the flow and sent to the backend. Then some bytes are received from the backend and written to the client. This is the point where the issue happens: -The completion handler for writeDatagrams is success but as I mentioned before the next datagrams are not sent by the flow and most important, the Proxy Provider stops receiving new flows. These message are shown in the console app:
- debug 15:22:49.589076-0300 nnn.systemextension opening flow UDP [{length = 0, bytes = 0x}] local port 0 interface en0 with local 192.168.100.13:53606
- debug 15:22:49.589767-0300 nnn.systemextension (2011000062): Open, sending successful connect result
- debug 15:22:49.589924-0300 nnn.systemextension (2011000062): Got a connect result with window size 786896
- debug 15:22:49.590019-0300 nnn.systemextension (2011000062): invoking open completed event handler
- debug 15:22:49.590279-0300 nnn.systemextension nw_socket_handle_socket_event [C1:1] Event mask: 0x800
- default 15:22:49.590326-0300 nnn.systemextension nw_socket_handle_socket_event [C1:1] Socket received CONNECTED event
- default 15:22:49.590426-0300 nnn.systemextension nw_flow_connected [C1 IPv4#187b93af:5011 ready socket-flow (satisfied (Path is satisfied), viable, interface: en0, ipv4, ipv6, dns)] Output protocol connected
- debug 15:22:49.590493-0300 nnn.systemextension nw_endpoint_flow_connected_path_change [C1 IPv4#187b93af:5011 ready socket-flow (satisfied (Path is satisfied), viable, interface: en0, ipv4, ipv6, dns)]
- debug 15:22:49.601342-0300 nnn.systemextension (2011000062): received 4 udp bytes from app
- debug 15:22:49.601432-0300 nnn.systemextension (2011000062): plugin read 4 bytes
- debug 15:22:49.601682-0300 nnn.systemextension providertestpablo readDatagrams success UDP flow, copier: 0 data.count: 1 dataItem.length bytes: 4
- debug 15:22:49.612696-0300 nnn.systemextension providertestpablo writeDatagrams to execute UDP flow, copier: 0 length bytes: 4 copier.remoteEndpoint: 192.168.100.9:5011
- debug 15:22:49.612873-0300 nnn.systemextension (2011000062): Wrote 4 bytes to the kernel (total bytes written = 4)
- debug 15:22:49.612931-0300 nnn.systemextension (2011000062): plugin wrote 4 bytes
- debug 15:22:49.613032-0300 nnn.systemextension providertestpablo write success to execute UDP flow, copier: 0 length bytes: 4 copier.remoteEndpoint: 192.168.100.9:5011
- error 15:22:49.634139-0300 nnn.systemextension (0): Failed to read an entire packet
- error 15:22:49.634195-0300 nnn.systemextension (0): control: aborting director due to EOF
- default 15:22:49.634228-0300 nnn.systemextension (0): Aborting the director
- default 15:22:49.634275-0300 nnn.systemextension (2011000062): Closing reads (suppressing SHUT_WR), closed by plugin
- default 15:22:49.634314-0300 nnn.systemextension (2011000062): Closing writes, sending SHUT_RD
Has anyone observed this issue before? From the API point of view there we can only invoke readDatagrams and writeDatagrams, so It doesn't look that something is wrong in the implementation.