Internet Reachability Verifier - Support Thread

Big update! - Version 1.1.0 is now available:

• Changed internal coroutine to wait using realtime instead of pauseable normal time.
  
• Also the getTimeWithoutInternetConnection is now realtime-based.
  
• Added forceReverification method which sets status to pending verification, which is also now internally noticed immediately.
  
• Exposed the time value settings to inspector.
  
• Added AppleHTTPS method (due to ATS, App Transport Security).
• Added waitForNetVerifiedStatus convenience helper coroutine.
  
• Fixed regression bug of running verification twice.

 

Hi tonic,

We have found a few issues with IRV. The biggest one we are facing now is that in Desktop Standalone builds the example doesn't seem to be working. I am disabling and re-enabling my network adapter with no change. I am doing a simple build of the example scene that is provided. The only way I am able to get it to recognize the change is forcing reverification, but that's not an ideal solution. Any idea why this could be? We are on 5.4.1p1.

Any help is greatly appreciated!

 

Hi @invictvs1,

Thanks for asking. I'm not fully sure I understood what exactly isn't working for you, but it sounds to me like you're expecting the status to change to "offline" after the network connectivity has already been verified?

Normally desktop machines are never totally "offline", as is documented by Unity for the Application.internetReachability: "Non-handhelds are considered to always be capable of NetworkReachability.ReachableViaLocalAreaNetwork". The Internet Reachability Verifier (IRV) asset uses that to determine if there's even point trying to verify actual internet connectivity.

It's important to note that IRV is used only for verifying when the online internet connectivity works -- active monitoring of "online --> offline" is not a feature of IRV. This is because monitoring for that would require some constant network traffic, and that would be actually impolite(*) towards end-users, since it would be "unnecessary" traffic. Instead of that "unnecessary" traffic, a developer is expected to simply monitor for error situations when they're using network -- which is normally done anyway (or should be done). When you can figure out from the errors that e.g. connection was cut off, then you can manually request for the reverification.

So to recap:
1. IRV monitors when online connectivity is available (this is the main feature of the asset). This can be done "constantly" without causing network traffic, so it is an effective way.
2. After network connectivity is verified, IRV basically does nothing. (Except on mobiles the device can go to offline state e.g. when going to airplane mode including WiFi off; in such case IRV will go to that step 1).
3. When networking is verified, you do stuff in the net (e.g. using WWW class, or some other means of networking). In case of failure, you're supposed to look at error codes, and if determined to be necessary, ask for IRV to reverify the connectivity (that is, go back to that step 1).

Hope this helps! If I understood you wrong and your problem is different, please re-explain how the built-in examples are not working and I'll try to figure it out.

---
* (Edit) forgot to mention that the unnecessary traffic would be impolite because in many places users still have to pay by amount of used traffic.

 

This definitely helps, and you understood my question correctly. Makes a lot of sense now, thanks for the clarification. I will rework our IRV implementation in the application and see if it resolves my problem.

 

I just upgrade and I am getting this error now.

IRV www error: Protocol " https" not supported or disabled in libcurl

and if I change to http
IRV www error: Protocol " http" not supported or disabled in libcurl

It is only using the custom method, when I choose https apple it works.

 

@phoenixrising, make sure you have correctly written the URL, it looks like you have extra space at the beginning?

 

Wow, I feel stupid, yup that fixes it! Thanks!

 

Does it support IPV6 for iOS? Confirm?

 

@Priyanka-Rajwanshi I think it should work just fine, but haven't verified in IPv6-only network. No direct IP (v4) addresses are used, and the verification uses standard http/https connections using UnityEngine.WWW, so I am almost sure there's no problem.

 

Okay. Thank you

 

Hi,
I noticed that you didn't update this plugin since August, are you still supporting it?
And are you planning to add more features/improvements soon?

 

@Wajdik, yes, still supporting, like you can see from the August update. Previous one was over a year earlier, as this asset does not require frequent updates.

There are no big feature additions planned. Do you have something in mind?

 

Hi,
You can add a way to check the connection periodically, for example if we use (www.msftncsi.com/ncsi.txt) to check the Internet connection it will not consume any noticeable bandwidth.
You can add this feature and let the developers to decide to use it or not!

 

@Wajdik, it's true that the bandwidth use is quite small for periodic checks.

So far I have left out for periodic check out of principle, for these reasons:

1. It still uses the bit of bandwidth every now and then, and there are users with mobile contracts where every bit of user bandwidth still has a cost (admittedly cost of reasonably done periodic check is negligible for relatively short sessions).
2. It is technically unnecessary. If connectivity is lost, it is always best to detect that by looking at error status from the networking operation you're doing at the moment, which is what is encouraged in this asset's docs as well (and at that point you can request for re-verifying of the net connection, to wait for a notification when it's deemed to work again). Using periodic check might encourage sloppy coding where errors are not checked for.

That being said, I'm sure there are some use cases where above points are no concern. I will consider this for a future update as an optional feature. I have busy times right now, so I can't give a promise when next version will be out.

 

Version 1.1.1 released, containing minor usability improvements: tooltips and a custom inspector which can give some in-editor warnings of unsuitable configuration. (periodic check feature discussed above has not been added in this version)

 

Any known incompatibility with iOS 10.3.1 or XCode 8.3.1? I updated XCode today and noticed that IRV (1.1.0 and 1.1.1) stopped working with the default validation method on iOS (Apple HTTPS). Apple and Apple2 still works.

 

Same problems here on iOS. Looks like Apple changed their html doc so this fails:

Code (CSharp):

1. int successPos = www.text.IndexOf("<BODY>Success</BODY>");
2.                 if (successPos >= 0 && successPos < 50)
3.                     return true;

Very easy to fix the plugin but do you think we could get Apple to fix this for now?

 

Thanks for reporting the issue. It's an unfortunate change on the page returned for the AppleHTTPS method.

This is fixed in the v1.1.2 hotfix release so please update to it immediately. It contains a bit looser/varied check for the Apple methods which hopefully prevents incidents like this for the future.

Unfortunately I don't have a valid contact which would be reasonable enough to ask for an immediate fix for this kind of thing. So I believe the quickest way to work around this is to just update an app. If you have an apple representative contact, then you can ask them to expedite the update for your app.

 

Hi tonic,

I'm using your internet verifier plugin in iOS but today suddenly it is giving me PendingVerification and mismatch status and showing error. Thus not able to play my Game. This problem is occuring only on iOS, Android build is runnning fine.

 

Hi @Wat123, as stated above, you need to update your app to use the v1.1.2.

 

Hi @tonic

The company I work for uses IRV in our app. And we seem to be running into the problem above. However, it appears that an old team member who is no longer with the company bought the license through their account (bought for the company use). So I'm just wondering if there's a way to upgrade our code without their account. Or if we're going to need to buy a new license.

Thanks!

 

@akajb, I'll send you a private message about this.

 

Hello, @tonic.
I use your IRV but on iOS i get always "Offline" state.
I updated IRV to 1.1.2, but still "Offline".

How solve problem?

 

Hi @Dm-Smirnov!

Can you please verify again that your project really has the latest version 1.1.2, and that your build is using the version? Perhaps delete the InternetReachabilityVerifier from project and import latest version again from the asset store.

Version 1.1.2 should work fine, but earlier versions have stopped working on iOS when using the AppleHTTPS method.

 

Hi @tonic!

I have found that the plugin does not work properly on Desktop platforms due to the netActivity coroutine using Application.internetReachability to detect a network change and force the status to PendingVerification. Unfortunately, Application.internetReachability seems to always be ReachableViaLocalAreaNetwork on non-handheld devices.

The test case I am working through occurs when starting my game with an active internet connection and cutting the connection in the middle of the game. The plugin never detects the connectivity change.

Is there a workaround/fix for this issue?

 

Hi @PetroUnityDev, what you describe about Application.internetReachability being limited that way is the very reason this asset even exists.

In Internet Reachability Verifier (IRV), the Application.internetReachability is only used as the "first step" to determine if there's point at all trying to verify the connectivity using an actual connection. If that passes, then the actual http(s) request is used to the place determined by selected captive portal detection method. The detection would work even without that "first step", it's just an optimization.

The asset only features verifying that there is connectivity when asked for that. It does not actively monitor for connection being lost. There's two reasons for that:
(1) Active monitoring with the same detection method would mean polling with http requests repeatedly, and that would lead to unnecessary network traffic. That'd be impolite towards user, since some still have to pay for their bandwidth (applies especially mobile networks). (Note that when the network doesn't work, polling with requests is ok, since they don't go anywhere, and when it finally does, it's about as small request as it could be).
(2) After you know the network works, you're going to do some other networking, with whatever API you're using. It's much better way to detect network loss by checking the error/return codes from that API -- you're supposed to check for the errors anyway. And that's the fastest way to know that network went down, rather waiting for a different component realizing it by polling.

Then, when you realize that you've lost connection, then the expectation is that you manually force the IRV again to the PendingVerification state (call forceReverification()). It will then keep trying until the connection is verified again for the moment.

Hope this helps!

 

Cool!

 

Hi - I am again getting connection issues on iOS, and am already using the v1.1.2 hotfix .
It is odd, because if I use the Fiddler proxy tool to test the connection when "Decrypt HTTPS traffic" is enabled, then the connection response is correct, and the app finds a connection.
However with this disabled, the app cannot find a connection.

Anybody else experiencing this issue?

I can resolve this issue by resetting the settings on the device - however I do not understand what caused this issue ( nb this happened on multiple devices)

 

Hi @SuperbStarling42, just tried but can't reproduce the issue here. Everything seems to be fine. Care to give some more specifics like Unity and iOS version?

 

Have there been any errors reported against Unity 2017.2.0f3? Just updated to latest version of IRV to try to fix. I am seeing the following in Android logcat:

Code (csharp):

1. 10-12 14:27:45.829 27536-27573/<our app package> E/Unity: NullReferenceException: Object reference not set to an instance of an object
2. at UnityEngine.WWW.get_responseHeaders () [0x00076] in /Users/builduser/buildslave/unity/build/Runtime/WebRequestWWW/UWRWWW.cs:158
3. at InternetReachabilityVerifier.checkCaptivePortalDetectionResult (CaptivePortalDetectionMethod cpdm, UnityEngine.WWW www) [0x000e9] in /Users/lcadev/Documents/Unity/OurApp/Assets/InternetReachabilityVerifier/InternetReachabilityVerifier.cs:316
4. at InternetReachabilityVerifier+<netActivity>c__Iterator1.MoveNext () [0x00294] in /Users/lcadev/Documents/Unity/OurApp/Assets/InternetReachabilityVerifier/InternetReachabilityVerifier.cs:459
5. at UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress) [0x00028] in /Users/builduser/buildslave/unity/build/Runtime/Export/Coroutines.cs:17

 

I'm getting the same error:

Code (csharp):

1. NullReferenceException: Object reference not set to an instance of an object
2. UnityEngine.WWW.get_responseHeaders () (at C:/buildslave/unity/build/Runtime/WebRequestWWW/UWRWWW.cs:158)
3. InternetReachabilityVerifier.checkCaptivePortalDetectionResult (CaptivePortalDetectionMethod cpdm, UnityEngine.WWW www) (at Assets/InternetReachabilityVerifier/InternetReachabilityVerifier.cs:316)
4. InternetReachabilityVerifier+<netActivity>c__Iterator1.MoveNext () (at Assets/InternetReachabilityVerifier/InternetReachabilityVerifier.cs:459)
5. UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress) (at C:/buildslave/unity/build/Runtime/Export/Coroutines.cs:17)

I have Unity 2017.2.0f3.

 

Hi, thanks for the reports, I'll investigate this!

 

@rgonsalv & @Nadan, it seems Unity has replaced the implementation of WWW class internally. Their new implementation doesn't seem to fill in response http headers when http result is 204. This means there's a regression bug which makes latest Unity version incompatible with the "Google204" detection method of IRV.

Workaround: For now, just force the asset to use a different method instead of "DefaultByPlatform", for example "GoogleBlank" or "MicrosoftNCSI".

I'll solve this for next release some way, so that the asset will work again "out of the box".

 

I reported this implementation issue as a bug to Unity and they already reproduced it & sent to be fixed (apparently). There was no idea when it'll be fixed in Unity though, so unless it is patched very quickly, then I'll make a release at some point with a workaround.

 

The problem appears to start in 2017.1.2, fwiw. Thanks for attending to it.

 

It seems the problem is a bit wider, appeared as a regression also to latest 5.6 p/f releases as well. Unity provided this link to track the bug:

https://issuetracker.unity3d.com/is...eaders-method-returns-null-on-android-devices

 

@rgonsalv & @Nadan, seems like Unity has fixed the regression bug in Unity 2017.1.2p2 (also checked it works in 5.6.4p1).

 

Seems to work with Unity 2017.2.0p1 too.

 

Great, thanks for reporting @Harha-Studios!

 

Version 1.1.3 released.
Changes: Fixed deprecation warning with latest Unity versions. Made responseHeaders related code bit more robust.

 

@tonic
We are using a latest IRV plugin. we facing few issues related to latest android sdk version i.e. PIE
Scenario : If I build a game with android PIE as target sdk and run it on the device which has android PIE installed
IRV plugin does'nt work. It always shows offline. And if I use same build(target sdk = android Pie) on the device which has lower sdk version it works fine.

please help our game is live and, the live build's target sdk is Pie and few users who has pie installed are facing this issue. And I cant even update a build on store with downgraded sdk version as google doesnt allow me.

 

@dasu, that's an interesting issue.

Have you been able to verify this issue by yourself as well, and verified that it happens also with the supplied example scene(s)? We'd have to know that before being able to say the issue is with the IRV asset.

Also, what Unity version & settings are you building with?

 

Please note that minimum target SDK is Android 8.0 (API level 26), the Android Pie is not required yet.
https://developer.android.com/distribute/best-practices/develop/target-sdk

 

@dasu, I think I have a solid guess on what's the issue. It seems Android 9.0 Pie expects apps to use HTTPS by default, and HTTP is permitted only as a configured exception.

I don't have an exact solution to this (yet), but if you're in a hurry, the issue should be resolved by manually adding a network security policy to the Android build. Here's some relevant links:

• https://android-developers.googleblog.com/2018/08/introducing-android-9-pie.html
  "You'll now need to make connections over TLS, unless you explicitly opt-in to cleartext for specific domains."
  For example, if you are using the DefaultByPlatform captive portal detection method on Android, then it's picking the Google204 one under the hood, which would mean that you'd have to add clients3.google.com (or perhaps google.com with subdomains) as an domain exception to allow HTTP traffic. See method getCaptivePortalDetectionURL in InternetReachabilityVerifier.cs
• https://android-developers.googleblog.com/2018/04/protecting-users-with-tls-by-default-in.html
  See "Allow cleartext connections to a specific domain" and "Allow connections to arbitrary insecure domains".
• More details:
  https://developer.android.com/training/articles/security-config
• Google search for "network_security_config.xml site:github.com cleartextTrafficPermitted"
  This will lead to few additional examples of a custom network security config xml files.
• Make sure you have custom Android Manifest which points to that xml file. I found e.g. this link which shows one example of having custom Android manifest in Unity, which points to a network security config xml.

If you make any progress with solving this issue, I'd appreciate to hear any comments on what you have done.

 

Hello there I'm trying to put a break point on this code but it skips I don't know why and I already tried placing also debug.log . Here's the code

Code (CSharp):

1. Rtoran.InternetReachbilityChecker pChecker = Rtoran.InternetReachbilityChecker.Instance;
2.  
3.         pChecker.StartCheckNetwork(() =>
4.         {
5.             // (If check server related file is not defined, go to authentication check immediately) 체크서버관련 파일이 정의되어 있지 않다면 바로 인증체크로 넘어가도록 한다.
6.             if (string.IsNullOrEmpty(CheckJSonManager.Instance._AwsDatacenterURL.SERVERLIST_URL))
7.             {
8.                 hsDebug.LogError("You can not proceed with version check because the server list check related file is not defined(서버리스트체크 관련 파일이 정의되어 있지 않아 버전체크를 진행할수 없다)");
9.                 //Machine.ChangeState(WebLoginFlow.eWebLoginStep.eTW_VersionCheck);
10.                 Machine.ChangeState(WebLoginFlow.eWebLoginStep.eTWL_AuthCheck);
11.             }
12.             else
13.             {
14.                 System.Uri uri = new System.Uri(CheckJSonManager.Instance._AwsDatacenterURL.SERVERLIST_URL);
15.                 HTTPRequest pRequest = new HTTPRequest(uri,
16.                     delegate (HTTPRequest originalRequest, HTTPResponse response)
17.                     {
18.                         if (response == null)
19.                         {
20.                             hsDebug.LogError(uri.ToString() + " Requested by address but no response (주소로 요청했으나 Response 가 없다)");
21.                             //Machine.ChangeState(WebLoginFlow.eWebLoginStep.eTW_VersionCheck);
22.                             Machine.ChangeState(WebLoginFlow.eWebLoginStep.eTWL_AuthCheck);
23.                             return;
24.                         }
25.  
26.                         if (response.IsFromCache)
27.                         {
28.                             //hsDebug.Log("로컬 캐쉬에서 사용 : " + originalRequest.Uri);
29.                         }
30.  
31.                         switch (originalRequest.State)
32.                         {
33.                             case HTTPRequestStates.Finished:
34.                                 {
35.                                     try
36.                                     {
37.                                         CheckJSonManager.Instance._ServerListJSon = LitJson.JsonMapper.ToObject<ServerListJson>(originalRequest.Response.DataAsText);
38.                                     }
39.                                     catch (Exception ex)
40.                                     {
41.                                         Debug.LogError("path : " + originalRequest.Uri + "\nException : " + ex);
42.                                         //Machine.ChangeState(WebLoginFlow.eWebLoginStep.eTW_VersionCheck);
43.                                         Machine.ChangeState(WebLoginFlow.eWebLoginStep.eTWL_AuthCheck);
44.                                         return;
45.                                     }
46.  
47.  
48.                                     bool bFound = false;
49.                                     ServerListJson pServerListJSon = CheckJSonManager.Instance._ServerListJSon;
50.                                     int target_server_no = Int32.Parse(tzGlobal.Instance.VERSION.Split('.')[2]);
51.                                     for (int i = 0; i < pServerListJSon.serverData.Length; i++)
52.                                     {
53.                                         Debug.LogError(pServerListJSon.serverData[i].serverNo);
54.                                         if (target_server_no == pServerListJSon.serverData[i].serverNo)
55.                                         {
56.                                             bFound = true;
57.                                             ServerData pServerList = pServerListJSon.serverData[i];
58.  
59.                                             NetworkManager.Instance.WebSocketServer.SESSION_NAME = pServerList.serverNo.ToString();
60.                                             NetworkManager.Instance.WebSocketServer.SESSION_IP = pServerList.serverIP;
61.                                             NetworkManager.Instance.WebSocketServer.SESSION_PORT = pServerList.serverPort;
62.                                             tzGlobal.Instance.LOGIN_URL = pServerList.publisherURL;
63.                                             tzGlobal.Instance.JOIN_URL = pServerList.joinURL;
64.                                             tzGlobal.Instance.STREAMING_URL = pServerList.streamingURL;
65.  
66.  
67.                                             //NetworkManager.Instance.WebSocketServer.SESSION_IP = "123123.123123.123";
68.  
69.                                             break;
70.                                         }
71.                                     }
72.                                     if (!bFound)
73.                                     {
74.                                         Debug.LogWarning("serverList.json (No required server number found in. ) 에서 필요한 서버 번호를 찾지 못함. 첫번째 서버 정보를 사용한다.");
75.                                     }
76.  
77.                                     Machine.ChangeState(WebLoginFlow.eWebLoginStep.eTWL_AuthCheck);
78.                                 }
79.                                 break;
80.                             //case HTTPRequestStates.Aborted:
81.                             //case HTTPRequestStates.Error:
82.                             //case HTTPRequestStates.ConnectionTimedOut:
83.                             //case HTTPRequestStates.Initial:
84.                             //case HTTPRequestStates.Processing:
85.                             //case HTTPRequestStates.Queued:
86.                             //case HTTPRequestStates.TimedOut:
87.                             default:
88.                                 {
89.                                     hsDebug.LogError(uri.ToString() + " 주소로 요청했으나 Response 가 없다 ");
90.                                     //Machine.ChangeState(WebLoginFlow.eWebLoginStep.eTW_VersionCheck);
91.                                     Machine.ChangeState(WebLoginFlow.eWebLoginStep.eTWL_AuthCheck);
92.                                 }
93.                                 break;
94.                         }
95.                     });
96.  
97.                 pRequest.Send();
98.             }
99.         },
100.         (eNetStatus) =>
101.         {
102.             // 에러가 나오면 다시 강제 체크 하게 만든다.
103.             switch (eNetStatus)
104.             {
105.                 case InternetReachabilityVerifier.Status.Mismatch:
106.                     {
107.                         tzSceneManager.instance.HideLoading();
108.                         tzSceneManager.instance.CreateEmergencyPopup("MISSMATCH_NETWORK", LocalizationManager.GetText(eTextKey.MISSMATCH_NETWORK), "OK", null,
109.                         () =>
110.                         {
111.                             Rtoran.InternetReachbilityChecker.Instance.ForcedReCheck();
112.                         });
113.                     }
114.                     break;
115.                 case InternetReachabilityVerifier.Status.Error:
116.                     {
117.                         tzSceneManager.instance.HideLoading();
118.                         tzSceneManager.instance.CreateEmergencyPopup("ERROR_NETWORK", LocalizationManager.GetText(eTextKey.ERROR_NETWORK), "OK", null,
119.                         () =>
120.                         {
121.                             Rtoran.InternetReachbilityChecker.Instance.ForcedReCheck();
122.                         });
123.                     }
124.                     break;
125.                 case InternetReachabilityVerifier.Status.Offline:
126.                     {
127.                         tzSceneManager.instance.HideLoading();
128.                         tzSceneManager.instance.CreateEmergencyPopup("OFFLINE_NETWORK", LocalizationManager.GetText(eTextKey.OFFLINE_NETWORK), "OK", null,
129.                         () =>
130.                         {
131.                             Rtoran.InternetReachbilityChecker.Instance.ForcedReCheck();
132.                         });
133.                     }
134.                     break;
135.             }
136.         });

Could you please take a look at it.

 

Hi @Ginxx009, that code is referring to some different wrapper for internet checking (not included), and using your own internal APIs for various things. Trying to guess why that doesn't work is outside the scope of what's reasonably part of support.

Maybe you should make an isolated debugging project: first create an empty project, import the Internet Reachability Verifier, and check that the included example scenes work. After that you can "bring in" some hand picked parts of your own integration code to the test project. Perhaps you will then find out where's the issue.

 

Are you planning to update IRV to support Android 9? It is currently not working and while there may be workarounds, ideally the asset would support the OS update. This has caused problems in a live build for us and has apparently been a known issue for about five months.

 

Yes, this is definitely on the agenda, sorry for having to wait. I didn't have proper hardware for this until I just recently bought a new device, with promised Android 9 update for January (which just arrived a week ago or so).

Overall, if some app is critically dependent on connecting a specific server (which is in your own control), it's best to use https connections. Meaning that with IRV you'd use "custom method" with https url, and also https connections for the actual communication with the server. This way one can maximize the likelihood of connections working as intended, and minimize possibility of problems.

 

Hey @tonic, I've been using the asset in a project and I've just updated to Unity 2018.3.3. This has triggered some deprecation warnings from your plugin around the use of WWW (it's being replaced with UnityWebRequest https://docs.unity3d.com/ScriptReference/Networking.UnityWebRequest.html).

Could you please look at updating to use this newer Unity method?

Thanks!

 

@Murcho @Mandelboxed
I'm working on an update, code is somewhat done but documentation still needs updating. The update will contain solution for the Android 9 network security and will also use UnityWebRequest on Unity 2018.3+. I have some other things as well, so it may take a day or a week or something until I'm ready with the release.