Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
GitHub or Developer Community with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 18149 [details]
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.
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.
=== Xamarin Studio Enterprise ===
Version 6.1.1 (build 15)
Installation UUID: ceaba76c-db06-4fbd-b326-f69ea53c3e01
Mono 4.6.1 (mono-4.6.0-branch-c8sr0/ef43c15) (64-bit)
GTK+ 2.24.23 (Raleigh theme)
Package version: 406010005
=== NuGet ===
=== Xamarin.Profiler ===
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler
=== Apple Developer Tools ===
Xcode 8.0 (11246)
=== Xamarin.Android ===
Version: 184.108.40.206 (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:
=== Xamarin Android Player ===
Location: /Applications/Xamarin Android Player.app
=== Xamarin.iOS ===
Version: 10.0.1.10 (Visual Studio Enterprise)
Build date: 2016-10-03 15:18:44-0400
=== Xamarin.Mac ===
Version: 220.127.116.11 (Visual Studio Enterprise)
=== Xamarin Inspector ===
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
=== Enabled user installed addins ===
Xamarin Inspector 0.10.0.0
*** Bug 45383 has been marked as a duplicate of this bug. ***
*** Bug 45763 has been marked as a duplicate of this bug. ***
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.
That is not a workaround that is acceptable for an enterprise customer and will be escalated.
Created attachment 18158 [details]
Correct Test Project
I accidentally uploaded the wrong test project. this is the correct one.
In my opinion a better temporary solution would be to set the DNS refresh timeout to 0.
## Note to the Xamarin team
Updating target milestone for initial assessment based on the reported regression status.
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!
Fixed in master and Mono 4.8 branch
*** Bug 46792 has been marked as a duplicate of this bug. ***
Thank you for getting this fixed Xamarin Team. Happy Holidays
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).
*** Bug 23806 has been marked as a duplicate of this bug. ***
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.
In reading the release notes for C9 I don't see this bugzilla referenced but perhaps I missed it. Can you confirm?
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. :)
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.
@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.