A couple of VPN API questions

Hi,


I am working on implementing our VPN client on iOS using the new Network extension framework. I have most of it working, but there are a couple of things that are a bit strange. My vpn client uses a mix of objective C, C/C++ and swift.


Question 1:

When I run the VPN client and starts streaming from some kind of streaming service I see that the VPN network extension is slowly leaking memory. If I run the extension in Instruments they show up as a Malloc 16 KB with NEPacketTunnelFlow writePackets:withProtocols as the responsible caller every 8-10 seconds. I have looked over my code a number of times, but have a very hard time finding any leaks there. I am not sure how reliable the information in Instruments is, but that is what it says. The memory leak will eventually make my extension crash (it seems like that happens when it is over 6 MB). Has anyone else seen this behavior? Also, writePackets returns a BOOL. What does false mean? I cannot see anything in the documentation about how to interpret the return value.


Question 2:

If I have my VPN client connected and put my iPad into flight mode, our VPN client code will then sit and wait to be able to reconnect when the reachability code tells us we have connectivity again. When the connectivity is back, we can actually connect the socket to the VPN server, but we cannot get any traffic through. I have tried to call setTunnelNetworkSettings again before reconnecting and that makes it work 1 out of 5 times. My thinking with that was if we had to set the IP of the server again to the 32-bit static route to the VPN server setup again. The code does use berkeley sockets instead of the TCP and UDP sockets (createTCPConnectionToEndPoint etc.) provided by the NEProvider. I know the documentation says it is recommended to use those, but that requires major rewrites of our code that I would like to stay away from. Is there anything that needs to be done when the connectivity is lost and comes back that I am missing?


Rgds,

Lars

Some further information that I have gathered from Instruments regarding the memory leak. There are allocations made by libdispatch.dylib and the Responsible caller is _dispatch_root_queue_drain that are 16 KB as well. These are however deallocated after a couple of seconds. Is that the garbage collection kicking in?

One more update regarding the memory leak. If I surround the call to writePackets with an autoreleasepool the memory leak goes away. What I find a bit strange is that there is already an autoreleasepool in the objective-C thread that calls writePackets. Do you need to have a separate autoreleasepool if you call swift code from objective-C code? I guess I need to brush up my ARC knowledge. I long for the good old days when I was responsible for the deallocation myself 🙂

Question 1: …

Has anyone else seen this behavior?

Honestly, I haven’t gone looking. Can you reproduce the problem with SimpleTunnel sample code? If the Leaks instrument is showing leaks in SimpleTunnel, that’s definitely bugworth (either as a bug in the sample or a bug in the OS itself).

These are however deallocated after a couple of seconds. Is that the garbage collection kicking in?

iOS doesn’t do garbage collection it the traditional sense. In the general sense, however, various subsystems do retain stuff for extended periods of time, in caches and whatnot, and that stuff can be released under various circumstances, so it’s quite reasonable to see unexplained peaks and trough in memory allocations here.

Do you need to have a separate autoreleasepool if you call swift code from objective-C code?

No.

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks for the response.


I have realized that I did not ever went outside of my autoreleasepool scope so the memory just kept building up. So I am the fool here!


Did you get a chance to look at my other question?


Rgds,

Lars

Did you get a chance to look at my other question?

Nothing particularly concrete. If you run the same test against SimpleTunnel, what happens? If things work there, then that’s a good indication that it might be worthwhile experimenting with NWTCPConnection.

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"
A couple of VPN API questions
 
 
Q