Full Tunnel DNS filtering bootloops iOS 11.3 beta 1

[polarimetric]

Steps to reproduce

1. Install iOS 11.3 developer beta 1 on an iPhone (8 in my case)
2. Enable "Full Tunnel" DNS filtering with at least one DNS user filter or subscription enabled
3. Wait 5-10 seconds
4. Device crashes and reboots; if user is not fast enough disabling DNS filtering after reboot and unlock, a boot loop ensues

Expected behavior

The device should not crash and reboot.

Actual behavior

The device crashes and reboots without fail within 5-10 seconds of VPN connection if "Full Tunnel" is enabled. Split Tunnel does not appear to have this issue. I am not sure if this is an iOS beta bug (especially since this is a first developer beta) or an Adguard bug, but it's relatively urgent, especially since if the user has DNS filtering enabled on 11.2.5 and then updates to 11.3 beta 1, the device will without fail crash and reboot before the iOS initial setup post-update sequence can be completed; the only way to recover from this is to restore via iTunes as there is no way to disable DNS filtering until the device is set up.

Interestingly, this bug does NOT appear to be present on an iPad (2017, 9.7-inch) running iOS 11.3 developer beta 1; only on my iPhone.

Customer ID

1738330

Your environment

iPhone 8, 64 GB iOS 11.3 developer beta 1 Wi-Fi and mobile data

[polarimetric]

Forgot to include that I’ve replicated this issue on both the latest stable version (1.3.3) and the latest TestFlight beta version (2.0.0 128).

[zeezeepiggy]

Can you try other vpn apps if they have the same issue? Like f-secure freedome or any vpn app. I am thinking that VPN probably is broken in 11.3 beta 1. We have the same issue with ios 9.3.3 before where vpn is broken.

[polarimetric]

Freedome does not appear to have the same issue (perhaps because it appears to be split-tunnel). I can use AdGuard without issue as long as I set it to Split Tunnel mode; it’s only Full Tunnel (which does not display the persistent “VPN” badge in the status bar) which triggers this issue.

[zeezeepiggy]

Ok. There must be something wrong with Full Tunnel then... hopefully they will know the cause and it will be fixed in by either adguard team or apple . I use full tunnel mode all the time...

[dnovitskyi]

Reps.zip

User log files

[zebrum]

Can not reproduce the issue on iphone X.

[polarimetric]

I posted about the issue in a reddit thread here: https://reddit.com/r/iOSBeta/comments/7syw78/bug_turn_off_full_tunnel_vpn_apps_before_updating/ two confirmed they experienced the same issue; two others did not. It seems to be device specific especially since I did not have the issue on my iPad but did on my iPhone 8.

[zebrum]

Except that could be device specific problem, it's more likely iOS bug.

one more complain: https://forum.adguard.com/index.php?threads/ios-11-3-beta-1.27938/#post-164245

[shabie1]

I’m having the same issue on an iPhone X running the iOS 11.3 beta. Having to use split-tunnel for the time being.

[shabie1]

Sorry, I meant having to use full-tunnel for the time being. Split-tunnel is the mode that makes my phone respring endlessly.

[ameshkov]

Guys, there's an interesting comment from Reddit about that: > I believe it's the widget. If we have the widget enabled, boot loop.

Can you confirm?

[polarimetric]

Unfortunately, no—I can reproduce the behavior reported in this bug with the widget disabled.

[ameshkov]

Uh, thanks for testing! For now I've marked this issue as an "iOS Bug", let's wait till the next beta then.

[astra-io]

to fix, uninstall app, reset network settings, reinstall. or maybe just reinstall. seems to be working now

[shabie1]

Tried that and it still makes my phone reboot.

[astra-io]

I forgot to mention that I'm on the beta. Here's what I did and it seems like it completely fixed - everything else was temporary or instantly put me in a boot loop: I reset network settings, checked app, enabled full tunnel and boot loop ensued. I uninstalled the app, reset network settings, reinstalled, enabled and turned on full tunnel.

Sometimes it would stop working, even though everything was enabled. To fix it, I just switched from split tunnel to full tunnel to reenable. You can tell it stopped working if it doesn't create any logs.

[astra-io]

I got bootloop as i connected to wifi. Turned wifi off and no more issues. Obviously this is inconvenient to many, but as a udp user, i barely use wifi.

[polarimetric]

Still occurring on iOS 11.3 beta 2.

[ameshkov]

Still occurring on iOS 11.3 beta 2.

What's AdGuard version? Does it happen on v2.0 beta?

[polarimetric]

Yes. I’m using 2.0.0 (136) from TestFlight.

[ameshkov]

@IvanIin can we somehow expose tunnel settings to the app advanced settings? We cannot reproduce this issue on our side so the only possibility I see is to let people change the tunnel settings manually and figure a stable configuration.

[shabie1]

I’m still having this same issue as well on my iPhone X running iOS 11.3 beta 2. Full tunnel mode still instantly causes phone to boot loop. Resetting network settings doesn’t help. Full tunnel mode still works fine on my iPad 5th gen running iOS 11.3 beta 2 though. It seems this issue only occurs on iPhones.

[ameshkov]

@polarimetric one more thing, iOS crash reports might be useful.

Go to Settings > Privacy, scroll down and tap Analytics. Then tap Share iPhone & Watch Analytics and send it to apple@adguard.com

[ameshkov]

It'd be better to reproduce the issue before sending the crash reports :(

[shabie1]

I can reproduce the issue again and send you my crash reports as well if you would like. Also forgot to include this in my earlier post but split-tunnel still works fine on iPhone. It’s only full-tunnel that causes the endless reboots. Also, if using cellular data, full-tunnel mode still works. It’s only when using full-tunnel mode while also connected to any WiFi network that causes the phone to boot loop.

[ameshkov]

@shabie1 I appreciate that, thank you!

[polarimetric]

I also sent crash logs to the indicated email address after reproducing the issue.

[ameshkov]

Got them, thank you!

Waiting for @IvanIin to analyze them

[polarimetric]

Tentatively at least, I can’t reproduce this on iOS 11.3 developer beta 3. The associated iOS bug may have been resolved. Can anyone else confirm? @shabie1 @gnawh

[shabie1]

Still happens on my iPhone X running 11.3 beta 3. Again, only happens when using both WiFi and Split-Tunnel. It works fine with LTE and Split-Tunnel.

[polarimetric]

@shabie1 do you mean full-tunnel or is split-tunnel causing the kernel panics for you?

[shabie1]

Split-Tunnel, but only while connected to WiFi.

[ameshkov]

@shabie1 could you please also send crash reports to us? Maybe it's something different in your case?

[ameshkov]

From @polarimetric log:

Thread 3 name:  Dispatch queue: com.apple.network.connections
Thread 3 Crashed:
0   libsystem_platform.dylib        0x00000001816e1be4 os_unfair_lock_lock$VARIANT$armv81 + 16
1   libnetwork.dylib                0x0000000182a56f64 nw_connection_endpoint_report + 112
2   libnetwork.dylib                0x00000001829f4c6c nw_endpoint_handler_report + 168
3   libnetwork.dylib                0x00000001829f58f8 nw_endpoint_handler_path_change + 1040
4   libnetwork.dylib                0x00000001829f54d4 __nw_endpoint_handler_start_block_invoke + 116
5   libsystem_network.dylib         0x0000000181678c9c nw_path_necp_update_evaluator + 1332
6   libsystem_network.dylib         0x00000001816785fc nw_path_necp_check_for_updates + 880
7   libdispatch.dylib               0x00000001813bca2c _dispatch_client_callout + 16
8   libdispatch.dylib               0x00000001813f9748 _dispatch_continuation_pop$VARIANT$armv81 + 416
9   libdispatch.dylib               0x0000000181402bc0 _dispatch_source_invoke$VARIANT$armv81 + 1248
10  libdispatch.dylib               0x00000001813fb014 _dispatch_queue_serial_drain$VARIANT$armv81 + 248
11  libdispatch.dylib               0x00000001813fba78 _dispatch_queue_invoke$VARIANT$armv81 + 328
12  libdispatch.dylib               0x00000001813fc41c _dispatch_root_queue_drain_deferred_wlh$VARIANT$armv81 + 332
13  libdispatch.dylib               0x00000001814043ec _dispatch_workloop_worker_thread$VARIANT$armv81 + 612
14  libsystem_pthread.dylib         0x00000001816e5e70 _pthread_wqthread + 860
15  libsystem_pthread.dylib         0x00000001816e5b08 start_wqthread + 4

Fast analysis: nothing of ours in the stack trace, the crash happens inside of iOS, but the root cause is still unclear.

[ameshkov]

In order to file a bug report to Apple, I need additional information (and they provide an instruction for that). I'd appreciate if any of you can do it, reproduce the issue and then send us the logs.

Here's a complete instruction on how to enable logging, trigger a sysdiagnose and sync it with your computer via itunes: https://uploads.adguard.com/up04_vcgym_VPN_Logging_Instructions.pdf

[shabie1]

The link won’t work for me, I get this message: Sorry, you cannot view this page. This page no longer exists or the Apple ID you signed in with does not have permission to view this page. If you’re currently a member of the Apple Developer Program, you or your Team Agent may need to update your account by agreeing to the latest license agreement in order to access this page.

[ameshkov]

Ah, restricted to iOS devs, just a moment.

[ameshkov]

Re-hosted the file and updated my previous comment.

[shabie1]

Reproduced the issue, did the sysdiagnose, and recorded the time. I won’t have access to a computer to sync until later tonight though.

[ameshkov]

Thank you!

[shabie1]

Also, I’m on the latest public version of Adguard Pro, I’d like to try the 2.0 beta if possible and see if that fixes the issue, but I need a TestFlight code.

[ameshkov]

@shabie1 plz file an application here: https://kb.adguard.com/en/general/adguard-beta-testing-program#adguard-adguard-pro-for-ios

@zebrum will take care of it tomorrow.

[polarimetric]

Spoke too soon, just experienced the issue on beta 3. I will complete the full diagnostic process requested above later tonight.

[ameshkov]

God, it's huge. Thank you very much!

Filed a bug to Apple: 37747122

[polarimetric]

Just discovered some additional information which may be helpful: I can only reproduce this bug on particular WiFi networks. I think it’s the network security that determines whether it happens or not. On open networks and WPA2 Enterprise networks, I can’t reproduce the bootloop. However, on WPA2 Personal networks, I can reproduce it without fail by activating full-tunnel VPN, connecting to WiFi, and then trying to load any data (the bootloop occurs as soon as the device attempts to up/download anything through the network).

[ameshkov]

Meanwhile, got an answer from Apple:

Engineering has determined that your bug report (37747122) is a duplicate of 36947993 and will be closed.

The open or closed status of the original report your bug was duplicated to appears in a text box within the bug detail section of the bug reporter user interface. For security and privacy reasons, we don't provide access to the original bug yours was duped to.

The state of 36947993 is "OPEN".

[ghost]

I’ve submitted this to Apple since via the beta Feedback app when I initially noticed it in initial iOS11b. It’s actually also been an issue for those using public iOS11 releases without AdGuard Pro. It’s especially prevalent for those who do not have at least 10% of the device’s total storage free. This is not to say those experiencing it are above that threshold; it’s merely information to keep in mind for everyone.

[polarimetric]

Currently testing this on iOS 11.3 developer beta 4, have not reproduced yet.

[polarimetric]

After using full tunnel on iOS 11.3 developer beta 4 all day on various networks, I haven’t been able to reproduce this at all. Pending comments from others, this bug may have been resolved.

[ameshkov]

Fingers crossed