Post

Replies

Boosts

Views

Activity

Reply to Packet Tunnel Provider can't connect for unknown time after system wake
Well, I've tried to do this, and I can't confirm that these callbacks are called. My setup is: macOS Big Sur 11.6.2, mac mini, I've set the Turn display off after 1 minute of inactivity, removed the check to prevent it from sleep in that case. system network extension with Packet Tunnel Provider inside, based on wireguard opensource project I've added just such lines: override func sleep(completionHandler: @escaping () -> Void) { wg_log(.info, message: "Got sleep from provider") completionHandler() } override func wake() { wg_log(.info, message: "Got wake from provider") } And I've never seen such logs after several sleep-wake retries. All other logs from this class are ok, I can see them. Should I do anything else, except adding these lines to the class to subscribe the sleep/wake notifications? I've recorded the Console logs, but there are a lot, and nothing I can see related to my issue. Could you please point, what am I looking for?
Feb ’22
Reply to Packet Tunnel Provider can't connect for unknown time after system wake
No, I can't see anything related after wake. The nearest thing there before sleep: NESMVPNSession[Primary Tunnel<my tunnel name>:65B27634-3EBB-403E-98C9-2335A141E5E8:(null)]: status changed to disconnected, last stop reason Device went to sleep Filtering with my extension bundle id: default 19:43:33.614140+0200 <my sysext bundle id> [Extension <my app bundle id>]: Calling stopTunnelWithReason because: Device went to sleep default 19:43:33.619170+0200 <my sysext bundle id> container_create_or_lookup_app_group_path_by_app_group_identifier: success default 19:43:33.619740+0200 <my sysext bundle id> [Extension <my app bundle id>]: IPC detached error 19:43:33.623168+0200 <my sysext bundle id> SIOCGIFMTU failed: Device not configured error 19:43:33.623229+0200 <my sysext bundle id> NEVirtualInterfaceAdjustReadBufferSize: interface_get_mtu failed (6), defaulting to max mtu default 19:43:33.623342+0200 <my sysext bundle id> [Extension <my app bundle id>]: Session manager connection was invalidated default 19:43:33.623400+0200 <my sysext bundle id> [Extension <my app bundle id>]: Deallocating After wake I can't find any related logs from nesession manager (there are some, but unrelated) or my sysext(there is nothing at all). The process of my sysext is still running after wake, but just does nothing. I'm able to manually activate the tunnel from System Preferences - General or from code, but no callbacks hit. Should I file a bug about it?
Feb ’22
Reply to Packet Tunnel Provider can't connect for unknown time after system wake
My tunnel provider code now looks like: class PacketTunnelProvider: NEPacketTunnelProvider { ... override func sleep(completionHandler: @escaping () -> Void) { wg_log(.info, message: "Got sleep from provider") os_log(.default, "Got sleep from provider") completionHandler() } override func wake() { wg_log(.info, message: "Got wake from provider") os_log(.default, "Got wake from provider") } }
Feb ’22
Reply to Packet Tunnel Provider can't connect for unknown time after system wake
I'm using mac mini, so I set the energy saver to go to sleep after display is turned off (1 minute), and I'm waiting for it to go to sleep. I've checked, the manual sleep option (menu - Apple icon - sleep) gives me the same results. I've created the ticket FB9906942 for now. I'm going to try some more things during this week, and in case it would not help, I'll open a TSI, thanks.
Feb ’22
Reply to Multiple network extension unexpected behaviour
Well, I want to build more complex rules to process my internet traffic, than one provider offers, so I've decided to compose several providers. For example, to route some apps traffic into the packet tunnel provider, and route some other out, but more flexible, than only bundle-based rules could do. Based on previous thread, I hoped that it could be possible, and I can claim some traffic in Transparent proxy, then see it in the Packet Tunnel, and do smth with it, because its origin now a Transparent proxy. In the same time, traffic I've not claimed in Transparent Proxy will have its real origin, and could be processed in some other way. I've created a separate NE for each provider because it seems the right way for me, however now I see that I can combine several providers in one network extension - will check, if it helps me to have traffic trigger both providers.
Aug ’22