Packet Tunnel Provider - Writing SSL3_RT_ALERT 2 bytes

Yes, the SSL3_RT_ALERT is most likely a result of the IPC detachement. An IPC detachment notice can mean a few different things; for example that the VPN connection failed to reconnect during to satisfy the on-demand rules, or that the VPN session itself actually timed out. One thing I would recommend doing is taking a rolling packet trace of your VPN connection to server while uploading the file. This should tell you which side is hanging up the connection and cut down on the data you need to record to figure this out.

Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com

Thanks, I'll do it, but also - when trying to reproduce I saw those msgs coming from the kernel:
X86PlatformPlugin::evaluateSoftLimit NOT calling cgDispatchCallback

It appeared many times, is it also related?
And maybe "playing" with the MTU might help here?

I dont believe these calls are related as they look to be CPU and GPU related.

| X86PlatformPlugin::evaluateSoftLimit NOT calling cgDispatchCallback

How does you memory look during this transfer?

Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com

The memory at the extension reached to 16.5 MB

Also, those msgs appeared again (multiple times, as in the other thread I posted): utun_output - ctl_enqueuembuf failed: 55

Edit: According to this post https://forums.developer.apple.com/thread/73148

the memory limit for iOS is 15MB, but

1. It doesn't say what's the limit for macOS

2. The app/extension didn't crash, everything still works, it's just the upload that stop at the middle without any error.

Right, I may have mentioned before but the message:

"utun_output - ctl_enqueuembuf failed: 55"

Refers to an ENOBUFS error (55) on your control socket for utun interface when data is received but your read queue on the socket is full.

Off the top of my head I am not sure on the memory limits for Network Extensions on macOS.

I would recommend investigating the memory handling here regardless to see if it has an impact.

Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com

I think you are right, and it's related to memory issues -

I saw cases where the Memory keeps increasing (slowly, but still). At the 'View Memory Graph Hierarchy' - there are a huge number os Malloc Blocks.

However, I can't find a leak anywhere. All the buffers I'm using (including for sending/receiving data) are fixed in size.

From the other hand, at the Console I didn't see any message about killing my app.

And I noticed that sometime, when sending a big file (1GB), the memory climbed up to 12MB, and I saw the infamous 'boringssl_context_message_handler(2257) [C8.1:2][0x10484dea0] Writing SSL3_RT_ALERT 2 bytes'

'boringssl_context_handle_warning_alert(1892) [C8.1:2][0x10484dea0] write alert, level: warning, description: close notify' messages,

but AFAIK, 12MB is not the memory limit for the extension, so I can't tell why it failed, even if there's a leak.

Which steps should I take to debug it? I already decreased the memory usage, but it didn't help.

P.S - the CPU also reached 80% in some cases

Interesting. What does the internet connection look like when you are doing this? Are you seeing a lot of retransmissions? If so, I am wondering if you are running into a head of line blocking issue and this is causing your memory to queue up and rise over time because previous transmissions are being re-sent. I would take a look at a packet trace on this for more information on retransmissions and then look at the other side to see if they are waiting on a certain amount of data to come through before they flush their buffers on the connection.

Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com

I'll try the packet trace, but before that, I missed something at your other answer -

"utun_output - ctl_enqueuembuf failed: 55 Refers to an ENOBUFS error (55) on your control socket for utun interface when data is received but your read queue on the socket is full."

Which read queue is full?

The one related to the packets coming from packetFlow.readPackets? So I'm asking the OS for more packets where I shouldn't?

Or is the buffer to which I'm reading the responses from the network? In that case, if I'll empty the buffer before sening new packets to the network it should help, right?

Becuase I think it's all related to this error, I'll try to handle it first.
Edit: For sending/receiving traffic, I'm creating a pipe. Is it possible to change its size? Something like F_SETPIPE_SZ? Would it help?

int pipe_fds[2];
int ret = pipe(pipe_fds);
fcntl(pipe_fds[0], soemthing like F_SETPIPE_SZ, 64 * 1024);

Yes, this is the one. If there are retransmissions on either side check that you are not building up data on either side before it's flushed.

| Or is the buffer to which I'm reading the responses from the network? In that case, if

| I'll empty the buffer before sening new packets to the network it should help, right?

Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com

I am wondering if anyone here came to any solution in regard to upload issue through packet tunnel.

During uploading on high speed network, we always get this error “utun_output - ctl_enqueuembuf failed: 55”. Download is fine. We tried tuning some of kernel buffer sizes (going through “sysctl -a”) but no success.

We're testing on macOS Monterey ver. 12.2 Apple M1 chip.

Any response is greatly appreciated.

Thanks,

Dankira.