How do we pass a packet from NE via interface call to another code in Golang

Question

Created Oct ’21

Replies 6

Boosts 0

Participants 3

After VPN tunnel is created, I am trying to send a packet from packetFlow.readPackets() to another code via interface. This code is written in Golang which runs with the Swift App as a framework. I am able to see NSLog telling me that the packet is sent, but none of the logs written in Golang gets printed. How can I confirm whether the packets has reached the GO code?

Eg.

NE side:

self.packetFlow.readPackets { (packets: [Data], protocols: [NSNumber]) in

for packet in packets {

NSLog("Sending packet”). // prints in Device Console VpnSendbufferpacket1(packet) // Sending packet to GO NSLog("Sending Completed") // prints in Device Console } }

Go side:

VpnSendbufferpacket1(buf []byte){ print(“GO - Sendbufferpacket() -> Start”). // NO print bufferinGO := buf print(“GO - packet received", bufferinGO). // NO print }

Tried file write also but can't get the logs printed. Is there any alternative for this. Or an approach where we can pass packet info properly.

Boost

Answer 1

DTS Engineer OP

Apple

Oct ’21

After VPN tunnel is created, I am trying to send a packet from packetFlow.readPackets() to another code via interface.

What platform is this on? And if it’s on the Mac, are you building a NE app extension? Or system extension?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

Saju91 OP

Oct ’21

Platform is iOS and I am using NE App Extension.

0

Answer 3

DTS Engineer OP

Apple

Oct ’21

So, to be clear, the Go code is running within the same process as the Swift code? And that is the process running your NE provider?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 4

DTS Engineer OP

Apple

Oct ’21

The Go code is build as a framework

Ah, OK, that’s much clearer.

None of the logs which I had put in GO gets printed.

Right. I presume that Go’s printing infrastructure is wired up to stderr. If so, it won’t show up in Xcode (or anywhere useful) because your NE process is launched by a the system in a way that connects stderr to /dev/null.

The best way to fix this is to update your Go code to log using an abstraction layer and then connect that abstraction layer to the unified logging system. Those log entries will show up in Console, be captured in sysdiagnose logs, and so on.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 5

DTS Engineer OP

Apple

Oct ’21

Is there any memory restriction imposed in NE process beyond which it may crash ?

Yes, NE providers run in a very tight memory budget. I haven’t looked at this in detail in a few years (Matt is now answering most NE questions for DTS, yay!) but this post has the details from the last time I dug into this.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 6

DTS Engineer OP

Apple

Oct ’21

Is there any possibility of increasing this limit?

No.

Well you could file a bug requesting that we raise the limit but I don’t think that’s what you’re looking for.

I recommend that you profile your memory use and then optimise it to get under the limit.

One thing to be careful of here is that you not buffer too much within your provider. For more about this, see Network Extension Provider Memory Strategy.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1