Bug 6057 - UdpClient IPv6 Receive throws ArgumentException
Summary: UdpClient IPv6 Receive throws ArgumentException
Alias: None
Product: Class Libraries
Classification: Mono
Component: System ()
Version: 2.10.x
Hardware: PC Linux
: --- normal
Target Milestone: Untriaged
Assignee: marcos.henrich
: 36315 ()
Depends on:
Reported: 2012-07-10 05:31 UTC by mab
Modified: 2016-01-13 10:19 UTC (History)
6 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:

Description mab 2012-07-10 05:31:46 UTC
Description of Problem:
UdpClient's Receive() function throws ArgumentException when using IPv6 endpoints.

Steps to reproduce the problem:

UdpClient udpClient = new UdpClient(PORT, AddressFamily.InterNetworkV6);
IPEndPoint remoteEP = new IPEndPoint(IPAddress.IPv6Any, 0);
byte[] receive_byte_array;
receive_byte_array = udpClient.Receive(ref remoteEP);

Send data to an IPv6 endpoint, which sends data back.

Actual Results:
System.ArgumentException: The IPEndPoint was created using InterNetwork AddressFamily but SocketAddress contains InterNetworkV6 instead, please use the same type.
  at System.Net.IPEndPoint.Create (System.Net.SocketAddress socketAddress) [0x00000] in <filename unknown>:0 
  at System.Net.Sockets.Socket.ReceiveFrom_nochecks_exc (System.Byte[] buf, Int32 offset, Int32 size, SocketFlags flags, System.Net.EndPoint& remote_end, Boolean throwOnError, System.Int32& error) [0x00000] in <filename unknown>:0 
  at System.Net.Sockets.Socket.ReceiveFrom_nochecks (System.Byte[] buf, Int32 offset, Int32 size, SocketFlags flags, System.Net.EndPoint& remote_end) [0x00000] in <filename unknown>:0 
  at System.Net.Sockets.Socket.ReceiveFrom (System.Byte[] buffer, System.Net.EndPoint& remoteEP) [0x00000] in <filename unknown>:0 
  at System.Net.Sockets.UdpClient.Receive (System.Net.IPEndPoint& remoteEP) [0x00000] in <filename unknown>:0 

Expected Results:
Should receive data.

How often does this happen? 

Additional Information:

Can be fixed by replacing:

EndPoint endPoint = new IPEndPoint (IPAddress.Any, 0);


EndPoint endPoint;
if (remoteEP.AddressFamily == AddressFamily.InterNetwork) {
  endPoint = new IPEndPoint (IPAddress.Any, 0);
} else {
  endPoint = new IPEndPoint (IPAddress.IPv6Any, 0);
Comment 1 Rodrigo Kumpera 2013-01-11 16:25:48 UTC
Please provide a complete test case, I don't see how exactly to build one of your explanation that will match what you're experiencing.
Comment 3 John Miller [MSFT] 2015-11-27 18:16:32 UTC

What do you need for this bug? Also, what is missing from the description that does not help reproduce this? I've filed https://bugzilla.xamarin.com/show_bug.cgi?id=36315 which might be a duplicate.
Comment 4 Jan Vilhuber 2015-11-30 15:29:19 UTC
The code in the description is more than adequate to reproduce the problem. Failing that, try using DnDns (available in a few locations; ours is here: https://github.com/nachocove/DnDns) on a IPv6-only network to do DNS lookups. I suspect it would be much easier to just use the code in the description, though. Some knowledge of networking is required.
Comment 5 Rodrigo Kumpera 2015-12-01 13:29:48 UTC
Hey Marcos,

Could you take a look at this one?
Comment 6 marcos.henrich 2015-12-01 15:47:09 UTC
This should be fixed by PR 2274
Comment 7 marcos.henrich 2015-12-01 20:12:43 UTC
*** Bug 36315 has been marked as a duplicate of this bug. ***
Comment 8 marcos.henrich 2016-01-13 10:19:35 UTC
Fixed in master b21767e.