С# WSAEINVAL (10022) Invalid argument on socket create - c#

I'm trying to create a chat on C# with WinSock (System.Net.Sockets) for the institute. On my computer everything works fine. On the ones in the institute it throws an exception on the line:
socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
SocketException: WSAEINVAL (10022) Invalid argument on socket create.
All arguments are absolutely following the guidelines.
I managed to find this thread (seems like my kind of problem).
Microsoft even created a patch to this one.
Institute computer runs on Windows7. I got no administator rights neither I am allowed to show chat on my notebook. So, it seems that I cannot edit windows registry or install an update. Are there any ways for me to fix or avoid this problem?

Related

SocketException thrown when invoking TcpListener.Start()

I am aware that there is already a similar question here. However, the only answer there does not solve my problem.
Here is my code:
TcpListener TcpListener = new TcpListener(localaddr: IPAddress.Any, port: 8080);
TcpListener.Start();
Executing TcpListener.Start(); gave me this error:
System.Net.Sockets.SocketException: 'An attempt was made to access a
socket in a way forbidden by its access permissions'
I have already defined an inbound security rule inside my firewall to make Port 8080 publicly accessible (I am aware that this is generally not recommended, but I am temporarily doing this for testing purposes):
When I run netstat -o, I am able to verify that Port 8080 does not already have an established connection.
For what it is worth, I am starting a TcpListener on an Azure virtual machine.
Any suggestions on how I can fix the SocketException?
UPDATE:
When I run netstat -o -n -a | findstr 0.0.0.0:8080, I see the following result:
TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING 4
Could the SocketException have been thrown because there already is a TcpListener listening on Port 8080?
I tried terminating the existing TcpListener by running taskkill/pid 4 /F (in order to see whether SocketException will still be thrown after terminating it), but didn't succeed:
ERROR: The process with PID 4 could not be terminated. Reason: Access
is denied.
Did the PID of 4 really not set alarm bells ringing before you tried taskkill? It's unusually low. In most windows systems I've worked on, it's been the system "process" that is the OS.
It's probable that something has registered to use that port as part of a URL reserved via HTTP.SYS.
If you have IIS running look for sites that are running on that port.

Server Client Application with .NET and Xamarin

I searched around the internet a lot of hours but I couldn't find anything that matches my case.
I simply want to implement a Server/Client App with TCP or UDP where my Android App (Xamarin) acts as a server and my .NET application as Client. Since I have not much experience with app development and no experience with Xamarin, I was looking for an example. All I found was this:
http://www.codeproject.com/Articles/340714/Android-How-to-communicate-with-NET-application-vi
First of all this is the opposite way (Server on .NET and Client as App) and additionaly it is for Android Studio so it's hard for me to translate these things into Xamarin without errors.
Please can someone help and give me an example how to realize my issue?
Thank you!
On Xamarin.Android you can use all of the regular .Net socket classes:
Namespaces:
using System.Net;
using System.Net.Sockets;
Example:
IPHostEntry ipHostInfo = Dns.GetHostEntry (Dns.GetHostName ());
IPAddress ipAddress = ipHostInfo.AddressList [0];
IPEndPoint localEndPoint = new IPEndPoint (ipAddress, 11000);
System.Diagnostics.Debug.WriteLine(ipAddress.ToString());
// Create a TCP/IP socket.
Socket listener = new Socket (AddressFamily.InterNetwork,
SocketType.Stream, ProtocolType.Tcp);
AndroidManifest.xml Required Permissions are:
<uses-permission android:name="android.permission.INTERNET"></uses-permission>
The MSDN-based Asynchronous Server Socket example works as a cut/paste example with no changes.
i.e.
Using the MSDN code, you can call the static method, AsynchronousSocketListener.StartListening, in a thread to start listening on port 11000 defined in the AsynchronousSocketListener class.
new Thread (new ThreadStart (delegate {
AsynchronousSocketListener.StartListening();
})).Start ();
Once it is running on your device/emulator, you can telnet into your Android TCP socket server:
>telnet 10.71.34.100 11000
Trying 10.71.34.100...
Connected to 10.71.34.100.
Escape character is '^]'.
Once connected, type in This is a test<EOF> and the Android will echo it back:
This is a test<EOF>
You do this like in normal .net, except you have to ask permissions to use sockets.
There are tons of simple example of creating a listening tcp connection in c#.
The problem you will have is to know the IP address of your server (in the phone) as it will likely change often when the user is moving.

Getting invalid pointer address when binding socket in C#?

On one of our teams desktop, we are getting a strange error when running this code:
IPAddress ipaddress = IPAddress.Parse(sIPDaddress);
var endpoint = new IPEndPoint(ipaddress, m_iPort);
listener.Bind(endpoint);
listener.Blocking = true;
listener.Listen(-1);
We are getting the following 10014 error on the bind command:
WSAEFAULT 10014 Bad address. The system detected an invalid pointer
address in attempting to use a pointer argument of a call. This error
occurs if an application passes an invalid pointer value, or if the
length of the buffer is too small. For instance, if the length of an
argument, which is a sockaddr structure, is smaller than the
sizeof(sockaddr).
We initially thought it was a network issue but my laptop running the same code works when connected to his network port.
The desktop is ip4 enabled and this is the only machine we are having this issue. We even changed the network card but the error still exists.
Any ideas where to look?
I found a line above the code above:
Socket listener = new Socket(0, SocketType.Stream, ProtocolType.Tcp);
I switched this to:
Socket listener = new Socket(AddressFamily.InterNetwork,
SocketType.Stream, ProtocolType.Tcp);
and it worked.
Still not sure why this happened on one the developer machines but not on the others.
What I did notice was when I did ipconfig on a working development machine there is a Link-local IPV6 address shown. However on the non-working machine there is no entry for a Link-local IPV6 address. Not sure if this is related.

Project specific socket exception: Dead network found

So today I tried to create a SFtpconnection to a remote host through the SSHNet API. Tests in a quick and dirty console application worked quite fine but when referencing the the builded DLL in the project where the functionality should be added, the DLL was throwing exceptions.
Debugging the project, the exception turned out to be on the socket connect (or begin connect function):
A socket operation encountered a dead network.
As stated before, the connection in another project to exactly the same server with the same parameters worked just fine.
I checked Project/Solution configurations. Checked the server name and other parameters carefully and made a testcase that in the specific project always fails (no matter what server) but WORKS in (new) projects:
var ep = new IPEndPoint(IPAddress.Parse(IPAdres),Port);
var sock = new Socket(ep.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
sock.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.NoDelay, true);
// Connect socket with specified timeout
var connectResult = sock.BeginConnect(ep, null, null);
if (!connectResult.AsyncWaitHandle.WaitOne(180, false))
{
throw new Exception("Timeout");
}
sock.EndConnect(connectResult);
But this doesn't seem like a strange example.
Does anyone has experience with this kind of error in a project specific way? Is there anything I'm missing?
Thanks,
Maybe the library was using the wrong NIC?
I encountered this exception on a Windows CE device with .net CF 2.0. In my case I was creating a socket for the GPRS interface, but the device was connected via Ethernet.

TCP Socket.Connect is generating false positives

I'm experiencing really weird behavior with the Socket.Connect method in C#. I am attempting a TCP Socket.Connect to a valid IP but closed port and the method is continuing as if I have successfully connected. When I packet sniffed what was going on I saw that the app was receiving RST packets from the remote machine. Yet from the tracing that is in place it is clear that the connect method is not throwing an exception. Any ideas what might be causing this?
The code that is running is basically this
IPEndPoint iep =
new IPEndPoint(System.Net.IPAddress.Parse(m_ipAddress), m_port);
Socket tcpSocket = new Socket(AddressFamily.InterNetwork,
SocketType.Stream, ProtocolType.Tcp);
tcpSocket.Connect(iep);
To add to the mystery... when running this code in a stand alone console application, the result is as expected – the connect method throws an exception. However, when running it in the Windows Service deployment we have the connect method does not throw an exception.
Edit in response to Mystere Man's answer
How would the exception be swallowed? I have a Trace.WriteLine right above the .Connect method and a Trace.WriteLine right under it (not shown in the code sample for readability). I know that both traces are running. I also have a try catch around the whole thing which also does a Trace.Writeline and I don't see that in the log files anywhere. I have also enabled the internal socket tracing as you suggested. I don't see any exceptions. I see what appears to be successful connections.
I am trying to identify differences between the windows service app and the diagnostic console app I made. I am running out of ideas though
End edit
Thanks
Are you sure the exception isn't being caught and swallowed in the service, but not in the console app?
My first step would be to isolate the differences between the two implementations. You mention tracing, but you don't say whether this is Network tracing (part of the BCL) or your own tracing. If you're not using network tracing, then enable that.
see AppDomain.CurrentDomain.UnhandledException
I have never observed this again. It seems to me that something was corrupt somewhere. Either the OS on which the app was installed or the .NET framework.

Categories