|Summary:||After network reconnected, web request fails for a couple of minutes with a NameResolutionFailure|
|Product:||[Mono] Class Libraries||Reporter:||Jon Goldberger [MSFT] <jon.goldberger>|
|Component:||System.Net.Http||Assignee:||Marek Safar <masafa>|
|Severity:||normal||CC:||adrian.murphy, alexandre.pepin, brendan.zagaeski, cody.beyer, dannycabrera, ghigh, iphone.grandmaster, lassana.nd, luis.aguilera, masafa, michaelhyk, mono-bugs+mono, norman.mackay, parmendrak, peter.collins, pierce.boggan, sunilk, t.brand|
|Target Milestone:||4.8.0 (C9)|
|Tags:||ExPT||Is this bug a regression?:||Yes|
|Last known good build:||Mono 4.4.2 (mono-4.4.0-branch-c7sr1/f72fe45) (64-bit)|
Correct Test Project
Description Jon Goldberger [MSFT] 2016-10-20 19:49:46 UTC
Created attachment 18149 [details] Test Project ## Description This is a bit of an odd issue, so bear with me. If this sample app is launched with a network connection and a request is sent, the request succeeds. If then connection to the internet is lost, the request of course fails, but upon reconnecting to the internet the request sent succeeds right away. In contrast, if after app launch the first request is sent with no internet connection you get a NameResolutionFailure exception for obvious reasons (no network). However if you then reconnect to the internet subsequent requests will continue to fail with NameResolutionFailure exception for a couple of minutes, but eventually will succeed. This is a regression. BAD: Mono 4.6.1 (mono-4.6.0-branch-c8sr0/ef43c15) (64-bit) BAD: Mono 4.6.0 (mono-4.6.0-branch/746756c) (64-bit) GOOD: Mono 4.4.2 (mono-4.4.0-branch-c7sr1/f72fe45) (64-bit) ## Steps to reproduce 1. Open the attached sample app in Xamarin Studio (Mac). 2. Set the TestNameResFailure.Mono as the start up project. 3. Deploy the console app. 4. Disable your network connection (turn off WiFi or unplug ethernet, or whatever method suits you) 5. Type 's' to send a request 6. Console output will show NameResolutionFailure message. 7. Reconnect to the internet 8. Type 's' to send a request Expected result: Console output will display the ContentType of the response (text/HTML) Actual result: Console output still shows NameResolutionFailure exception. ## Notes As stated, eventually if you keep sending requests the after step 8 above, the request will work after a couple of minutes. The attached sample is using a HttpWebRequest however I have other customers reporting the same issue using HttpClient. This issue initially was reported against Xamarin Android (bug #45383, marking as a duplicate of this bug). I initially I thought this was a DNS caching issue and was able to resolve in another customers test case by making sure no request was sent when the network was not available. I found some posts that Android caches bad DNS queries and thought that was the issue. But upon discovering that XA 188.8.131.52 does not display this issue, I reconsidered. Also, upon further reading and investigation, I found out that the bad DNS query should only be cached for 10 seconds while the NameResolutionFailure exception persists for a couple of minutes after restoring network connection. But after reports of this occurring on iOS, I tested with a Mono console app and was able to reproduce. ## Environment === Xamarin Studio Enterprise === Version 6.1.1 (build 15) Installation UUID: ceaba76c-db06-4fbd-b326-f69ea53c3e01 Runtime: Mono 4.6.1 (mono-4.6.0-branch-c8sr0/ef43c15) (64-bit) GTK+ 2.24.23 (Raleigh theme) Package version: 406010005 === NuGet === Version: 184.108.40.206 === Xamarin.Profiler === Version: 0.33.1 Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler === Apple Developer Tools === Xcode 8.0 (11246) Build 8A218a === Xamarin.Android === Version: 220.127.116.11 (Visual Studio Enterprise) Android SDK: /Users/jongoldberger/Library/Developer/Xamarin/android-sdk-macosx Supported Android versions: 4.0.3 (API level 15) 4.1 (API level 16) 4.2 (API level 17) 4.3 (API level 18) 4.4 (API level 19) 5.0 (API level 21) 5.1 (API level 22) 6.0 (API level 23) 7.0 (API level 24) SDK Tools Version: 25.2.2 SDK Platform Tools Version: 24.0.3 SDK Build Tools Version: 24.0.3 Java SDK: /usr java version "1.8.0_91" Java(TM) SE Runtime Environment (build 1.8.0_91-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode) Android Designer EPL code available here: https://github.com/xamarin/AndroidDesigner.EPL === Xamarin Android Player === Version: 0.6.5 Location: /Applications/Xamarin Android Player.app === Xamarin.iOS === Version: 10.0.1.10 (Visual Studio Enterprise) Hash: ad1cd42 Branch: cycle8-sr0-xi Build date: 2016-10-03 15:18:44-0400 === Xamarin.Mac === Version: 18.104.22.168 (Visual Studio Enterprise) === Xamarin Inspector === Version: 0.10.0.0 Hash: e931a52 Branch: master Build date: Thu, 18 Aug 2016 17:46:46 GMT === Build Information === Release ID: 601010015 Git revision: fa52f02641726146e2589ed86ec4097fbe101888 Build date: 2016-09-22 08:03:02-04 Xamarin addins: 75d65712af93d54dc39ae4c42b21dfa574859fd6 Build lane: monodevelop-lion-cycle8-sr0 === Operating System === Mac OS X 10.12.0 Darwin Jons-MacBook-Pro.local 16.0.0 Darwin Kernel Version 16.0.0 Mon Aug 29 17:56:20 PDT 2016 root:xnu-3789.1.32~3/RELEASE_X86_64 x86_64 === Enabled user installed addins === Xamarin Inspector 0.10.0.0
Comment 1 Jon Goldberger [MSFT] 2016-10-20 19:50:34 UTC
*** Bug 45383 has been marked as a duplicate of this bug. ***
Comment 3 Jon Goldberger [MSFT] 2016-10-20 19:59:26 UTC
*** Bug 45763 has been marked as a duplicate of this bug. ***
Comment 4 Jon Goldberger [MSFT] 2016-10-20 20:05:41 UTC
The workaround for this would seem to be to test for network connectivity before sending your request, and to use a different url to test for connectivity than the one you need to send requests to.
Comment 5 NMackay 2016-10-20 21:18:34 UTC
That is not a workaround that is acceptable for an enterprise customer and will be escalated.
Comment 6 Jon Goldberger [MSFT] 2016-10-21 10:04:57 UTC
Created attachment 18158 [details] Correct Test Project I accidentally uploaded the wrong test project. this is the correct one.
Comment 8 Tim Brand 2016-11-21 20:31:40 UTC
In my opinion a better temporary solution would be to set the DNS refresh timeout to 0. See: http://stackoverflow.com/a/40725278/1560797
Comment 10 Brendan Zagaeski (Xamarin Support) 2016-12-05 23:02:01 UTC
## Note to the Xamarin team Updating target milestone for initial assessment based on the reported regression status.
Comment 11 NMackay 2016-12-06 12:22:38 UTC
Any update on this? this has been highlighted as a priority issue by our senior management, as it's regression bug it's very hard to explain away!
Comment 12 Marek Safar 2016-12-21 10:12:24 UTC
Fixed in master and Mono 4.8 branch
Comment 13 Marek Safar 2016-12-21 10:14:32 UTC
*** Bug 46792 has been marked as a duplicate of this bug. ***
Comment 15 Danny Cabrera 2016-12-21 13:55:02 UTC
Thank you for getting this fixed Xamarin Team. Happy Holidays
Comment 16 Luis Aguilera 2016-12-21 14:21:00 UTC
unfortunately, this fix has missed the cutoff for C8SR2 (which is to hit stable on Dec 22). It will, however, be included in the next C9 Alpha refresh (if I recall correctly, this will be the 7th Alpha).
Comment 17 Sebastien Pouliot 2016-12-22 14:21:08 UTC
*** Bug 23806 has been marked as a duplicate of this bug. ***
Comment 18 Sunil Kumar 2016-12-28 13:28:34 UTC
As per comment 14, this issue is working fine with master and C9 mono. Hence I am closing this issue marking its status as verified. Thanks!
Comment 19 Gerry 2017-01-17 17:12:01 UTC
In reading the release notes for C9 I don't see this bugzilla referenced but perhaps I missed it. Can you confirm? Thanks, Gerry
Comment 20 Danny Cabrera 2017-01-24 15:08:38 UTC
Just ran some tests on latest C9 from beta channel and appears fix rolled out although I don't see it listed in release notes either. :)
Comment 21 heebaek choi 2017-02-23 09:15:47 UTC
today, apple reject my app for a reason problem when using IPV6. so I am debugging my app and now i am here. xamarin is updated to very new stable version. Mono 4.8.0 (mono-4.8.0-branch/e4a3cf3) (64-bit) I tested with wifi off, wifi connect(IPv4), wifi connect(IPV6ONLY) sometimes occur ConnectFailure especially when using IPV6Only. is this bug fixed already and already contains in my version of Xamarin? please someone check again.
Comment 22 Jon Goldberger [MSFT] 2017-02-23 22:49:03 UTC
@heebaek choi , I have double checked and this bug is resolved in the current Cycle 9 stable builds. I tested Mono Console app, iOS and Android. All worked as expected. I suspect you are hitting a different issue. You did not even mention getting the nameResolutionFailure. Please note that I have seen many cases where Apple rejected an app on IPv6 compatibility grounds when the issue was actually something completely different. For example one app was rejected by Apple stating IPv6 Compatibility problems when the actual issue was the app crashing on startup due to a missing permission description for microphone usage. So I would suggest contacting Apple for a better assessment of what they found in your app to cause the rejection.