C# + VisualStudio + Multiple WebDriver instances = SocketExceptions - c#

The WebDriver-based tests for our web application requires multiple browser windows open at once: one opens the consumer-facing portal, the other opens the administrator portal (to ensure changes in one are seen in the other). This is done by creating two seperate WebDriver objects: eg
IWebDriver driver1 = DriverFactory.NewChromeDriver();
IWebDriver driver2 = DriverFactory.NewChromeDriver();
The test can access both WebDrivers as desired. Our tests are specified in SpecFlow and implemented as MSTest cases. The tests are developed in VisualStudio 2013 Premium, and the drivers simply use the local machine's ChromeDriver instance. All well and good.
When a test performs some actions in Driver2 (say, logging in) and then moves back to Driver1, I end up with a SocketException being thrown because localhost actively refused the connection. Windows Firewall has been told to permit the application on all ports, the factory sets up the proxy correctly. The precise stack trace is:
System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 127.0.0.1:50467
Result StackTrace:
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)
Firefox opens one browser and then gives up. IE can't even FIND the browser when multiple windows are open.
(I never had this problem until I installed the latest update for VS2013....)
Any ideas? Thanks team.

It transpires that Selenium may indeed throw a WebDriver exception if an element is not present in the DOM. In the end, I had to wrap my accessing code within a try-catch: if the WebDriver exception wraps a WebException that wraps a SocketException, and the SocketException's SocketErrorCode is ConnectionRefused, that means the element is indeed absent from the DOM.

Related

Dns.GetHostAddressesAsync: Resource temporarily unavailable

First, for some context: I am using .NetCore to develop an API with Identity. Everything is on a Cloud server, inside a Docker. When a user is created, an email is sent to the new User using a mailkit and the webmail server through Plesk (Hosted on the same machine). The docker is accessed via a redirection trough Apache using a ProxyPass from the subdomain to the port on localhost
Everything works great while debugging trough JetBrain's Rider, but it is not able to process the email in the docker on the server.
Here is the stack:
System.Net.Internals.SocketExceptionFactory+ExtendedSocketException (00000001, 11): Resource temporarily unavailable
at System.Net.Dns.InternalGetHostByName(String hostName)
at System.Net.Dns.ResolveCallback(Object context)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw(Exception source)
at System.Net.Dns.HostResolutionEndHelper(IAsyncResult asyncResult)
at System.Net.Dns.EndGetHostAddresses(IAsyncResult asyncResult)
at System.Net.Dns.<>c.<GetHostAddressesAsync>b__25_1(IAsyncResult asyncResult)
at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)
I have yet to try and run the docker on another linux machine to test.
One of my current guess would be a problem with the SSL certificate, but I don't think it would cause a problem with the DNS or any internal socket.
Another guess is thats its a problem for the Docker to get the DNS Hostname, but since it works ok in a local.
Edit: I tried multiple time to run the docker on the mac and the error is still triggered once in a while but not always. It is although always triggered on the server and never send the email
After two weeks of research, I finally stumbled upon a solution for this:
The problem is related to the network, that was obvious, but it's precisely about how containers are isolated from one another. Problem is, the container has no outbound connection. A solution that work inside a standalone container is to use the --network host parameter, which would expose the host network to the container. Note that using this would remove the port mapping from the container since the container's port 5000 is now linked to the host's port 5000
Hope this solution can help others

unable to know what is blocking to my application to communicate to Web service

Recently we were facing an issue in client place is that we were unable to communicate to web service even we checked that there is no system proxy set in that system, to overcome this we had given a dummy proxy (localhost:port) and its started working well but after some days with dummy proxy it was unable to communicate to service if we remove dummy proxy then it started working well. i am not able to understand what is blocking me to communicate to service. what may be the issue and how can we overcome this problem. This issue is happening only on some system.
Actually it has to go and hit this URL http://********-tech.in:8080/******dp/ClientVersion but suddenly it started hitting this one 125.21.244.38:8080 why i am not able to conclude.
2017-05-05 00:19:44,721 ERROR [Heartbeat Service ] - Exception while sending heartbeat to manager.
System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 125.21.244.38:8080
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)
--- End of inner exception stack trace ---
at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)
at System.Net.HttpWebRequest.GetRequestStream()
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at HeartbeatWSImplService.heartbeat(String probeUid, heartbeatRequest heartbeatRequest)
at ProHance.ProbeHeartBeat.HeartBeat.timer_Elapsed(Object sender, ElapsedEventArgs e)
Please read this post here they are telling to set the default proxy for the webservice request, they are trying to the proxy details while connecting to google. If there is no proxy configured you can try the method mentioned there. Set the default proxy.

Azure service bus relay connecting to unknown ip address: 40.112.124.x:9352

We deliver on-premise software that is exposed to the cloud using Azure Service bus relay, the basic code we use to expose is as follows (I have removed everything identifiable):
ServiceHost sh = new ServiceHost(typeof(BasicHttpEntityService));
BasicHttpRelayBinding basicHttpRelayBinding = new BasicHttpRelayBinding();
Uri uriEndPointAddress = ServiceBusEnvironment.CreateServiceUri("https", "ourdomain", "test-url-appendage");
m_shRelayServiceHost.AddServiceEndpoint(
typeof(IMyService),
basicHttpRelayBinding,
uriEndPointAddress
).Behaviors.Add(
new TransportClientEndpointBehavior
{
TokenProvider = TokenProvider.CreateSharedSecretTokenProvider(
"MyUser",
"MyPassword")
});
sh.Open();
This works fine at most of our customers, however, one of our customers has a strict firewall policy.
According to the SB guidelines we have found, we asked them to open ports 9351-9354 to ourdomain.servicebus.windows.net. Now we find out that when there is an incoming request, the service connects to both 'ourdomain' (we see this succeeds in Wireshark, and also in the WCF log) AND an unknown (to us) service on 40.112.124.x:9352 (the last octet changes with every request).
I have been able to reproduce the problem in my development environment by disallowing connections to any 40.x.x.x address on any port. This is what happens in the WCF log:
System.Net.Sockets.SocketException (0x80004005): An attempt was made to access a socket in a way forbidden by its access permissions 40.112.124.25:9352
Server stack trace:
at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)
at Microsoft.ServiceBus.RelayedConnectionSession.ConnectAsyncResult.<GetAsyncSteps>b__4(ConnectAsyncResult thisRef, IAsyncResult r)
at Microsoft.ServiceBus.Messaging.IteratorAsyncResult`1.StepCallback(IAsyncResult result)
Exception rethrown at [0]:
at Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult result)
at Microsoft.ServiceBus.RelayedConnectionSession.EndConnect(IAsyncResult result)
There is no DNS-request going out during this time, so there is no host name that provides any clues to the function of this outgoing connection.
From my investigation, this appears to be a Microsoft controlled subnet, so I'm fine with the relay service connecting to it, but I would like to know:
Is this additional connection optional?
If not, should we allow the entire subnet?
Could this IP-range change in the future? Is it hardcoded somewhere?
In the end, we requested support from Microsoft.
In short their answers were as follows:
Is this additional connection optional?
No it is not optional. For the relay listener, there is a control channel on port 5671, this connection is always there. Then there is a data channel on portal 9352, this connection established when there is a relay client tries to communicate with the listener.
Could this IP-range change in the future?
Currently, for relay this IP can change, so you need to allow the IP range for the entire datacenter in your region (https://www.microsoft.com/en-us/download/confirmation.aspx?id=41653). The SB product team will be working on to significantly reduce this IP range in the future, to make it much more predictable. There is no exact ETA on this future.
So the good news is they are working on it. The bad news is, that right now, we will need to add a LOT of IP addresses to the white-list to ensure smooth operation.

Cannot initialize AndroidDriver

At W2k8 64 bit I have in the android emulator instance of android 4.1 API Level 16 with ARM as CPU.
After launch of it I'm running my UnitTest and on the first line
var webDriver = new AndroidDriver("http://localhost:8080/wd/hub"); //also with no argument
I got an exception:
Unexpected error. System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 127.0.0.1:8080
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.InternalConnect(EndPoint remoteEP)
at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Int32 timeout, Exception& exception)
--- End of inner exception stack trace ---
at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)
at System.Net.HttpWebRequest.GetRequestStream()
at OpenQA.Selenium.Remote.HttpCommandExecutor.Execute(Command commandToExecute)
at OpenQA.Selenium.Remote.RemoteWebDriver.Execute(String driverCommandToExecute, Dictionary`2 parameters)
Version of this WebDriver is 2.25.1.0.
I followed this article:
http://www.nishantverma.com/2011/06/installing-webdriver-on-android.html
When I'm using other drivers like Firefox- or ChromeDriver works fine.
I would be gratefull for any advice
I might be telling you what you already know, but have you started the tcp port forwarding to android server you are running. for reference check Android Driver
Your server is not starting for some reason. Is it possible you already have something else running on port 8080?
Try running netstat -a -n and see if port 8080 is listed.
If it is in use, you might try setting up on a different port or killing the process which is using that port.
You might also try disabling UAC and Firewall on your machine and/or running the process as Administrator and see if that helps (This would be temporary of course, don't leave these off).

SocketException when calling WCF service from MVC on same server

I have a Windows 2008 Server with IIS 7.5 and one IP. There are two Application under the root, /web and /service. /web is a MVC4 application, and /service is a WCF 4.0 service.
When I consume the service from MVC, I use the following code:
// Create the web request
HttpWebRequest request = WebRequest.Create(TripServiceUrl + id) as HttpWebRequest;
// Get response
using (HttpWebResponse response = request.GetResponse() as HttpWebResponse)
{
// Get the response stream
StreamReader reader = new StreamReader(response.GetResponseStream());
// Console application output
tripJson = reader.ReadToEnd();
}
I get the following SocketException:
[SocketException (0x274c): A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 10.243.6.43:80]
System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress) +273
System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception) +584
However, I can see 10.243.6.43:80 (an internal address) from a browser on the server and successfully call the service. The IP is not publicly accessible.
What configuration should I have to do to make a self referential call like that work?
It's probably a loopback problem (security issue). See http://support.microsoft.com/kb/896861.
To summarize:
In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Right-click Lsa, point to New, and then click DWORD Value.
Type DisableLoopbackCheck, and then press ENTER.
Right-click DisableLoopbackCheck, and then click Modify.
In the Value data box, type 1, and then click OK.
Don't follow the step about DisableStrictNameChecking.
You'll also find a lot of reasons not to do this (you are, after all, disabling a security check), followed by a lot of people saying it's the only way to get SharePoint to work properly. In any event, it will help you determine if this is the problem.

Categories

Resources