Binding to alternative IP in HttpWebRequest doesn't work in Windows Server 2008 - sockets

I am trying to bind a HttpWebRequest call to a specific IP on my server (which has many IPs). I have successfully written this code using BindIPEndPointDelegate and it works well on my local machine (Windows 7)
My issue is with Windows Server 2008. When I run the same console app on Windows Server 2008 it fails to bind to the IP when using the delegate. To complicate matters further, it seems to work for some destination URLs (http://www.microsoft.com) and doesn't work for some (http://www.google.com, http://www.facebook.com)
If I remove the IP specific binding (delegate) and run the app it works for all URLs.
The IP I am binding to is the default server IP address - meaning, in both scenarios the same IP should be used. I have verified this and it uses the same IP if I don't bind using the delegate. If I explicitly specific the IP it fails as described above.
I have tried turning off firewall, IIS & Antivirus - the problem persists.

Alright finally figured it out.
Upon testing again I found that specifying IPAddress.Any did not work either. On the other hand, IPAddress.IPv6Any worked fine.
Finally, I unchecked the IPv6 protocol in network adapter settings and the app starting working properly for all URLs and binding for all local IPv4 addresses.
Not sure if this is a bug in .NET code or feature - but disabling IPv6 fixed it for me.
Lastly, if anyone is facing "The requested address is not valid in its context" while making calls with binding, try disabling your antivirus.

Related

Fanuc Adapter Issues

I am trying to use the Fanuc Adapter found here https://github.com/mtconnect/adapter . And I've gotten this to compile and run on a machine with a Fanuc Controller. My problem is that it is giving me a result of -16 anytime I make a connection to it with an agent or through a web browser. I think the problem is that the machine is using an HSSB connection instead of ethernet and I have the wrong IP and Port. Yet everything online points to setting the IP to 127.0.0.1 and the default port to 8193, which I have tried. Does anyone know what could be the issue or how to set up a Fanuc Adapter on a controller with an HSSB connection? All the resources I've found only explain connecting via ethernet.
Figured it out. The adapter was always using a ethernet handle. Changed the source code to check and use both.

client is waiting forever for remote server to return a webpage

I have an application with a server written in F# and serve web files using suave. I remote login using powershell into another machine in the network to run the application (The application is also in one of the network drives). I do that because that machine have access to third party APIs needed for the server. Now when I do [IPAddress_Of_Remote_Machine]/[html_file] or [name_of_pc]/[html_file] then chrome is waiting forever and doesn't ever return the webpage. This wasn't happening before and I ran into this problem recently. I opened a different port and used it instead of the default one 80. This made things work but the problem keeps showing up after a couple of days. I don't think it's a firewall issue but I'm clueless to why this is happening.
When running netstat -an, this is what I get (I hid the IP address):
As you can see all of the connections are either in CLOSE_WAIT or ESTABLISHED but not LISTENING. All of these TCP connections is probably because I have PhantomJS and two other APIs running in the application as well. However the loop back address is also open on the same port 5959:
I'm not sure what is difference between these two but when using PortQryUI to query the remote server it returns a success!
I have already made an inbound rule for port 5959 on the server so it should be allowed. The web page is stuck at Waiting for [name_of_pc]. Also, sometimes this problem disappears and everything works fine.
What is the potential problem behind this? Why would this happen all of a sudden?
UPDATE:
I re-ran the application today and it's working correctly. It could be that something is dynamically set within the firewall? Not really sure what is going on. The machine I'm running the server on has a bunch of applications running on it as well so maybe there is an external process that is affecting it?
I made a hello world app with Suave and deployed it on the network drive to test if it's going to work. I opened inbound rule for port 6001
Then I ran the app:
However, it's still not working and this time it says the site cannot be reached when I do: http://[name_of_pc]:6001.
Moving this to an answer so that it can be closed:
Could you post the bindings section of your suave cfg? I'm guessing you know where that is since you are using a non-standard port but if you need don't, search for HttpBinding. I suspect you will find it pointing to 127.0.0.1 which is not good enough for remote access. You could try changing it to 0.0.0.0 or to the server's actual IP address. I would try 0.0.0.0 first for the flexibility it provides

gethostbyname not working for external server

I am writing an application with C++ to connect to my server.
I am using gethostbyname(). It is working fine when I give host name as 'localhost'. but if i try any other site like google.com, it fails.
Can anyone please tell me what could be going wrong.
I can access those websites through browser. Note: I have proxy set up in my browser.
Is thr proxy causing issue with gethostbyname()? if yes, how can I mention proxy in my C++ code?
Based on what you describe in your question, it appears that your machine is on a corporate network that is firewalled off the Internet, all access to the web is via a web proxy, and that your network does not have Internet DNS resolution.
Even if you managed to succeed in resolving an IP address, you will not be able to make an outbound connection, unless your firewall offers a Socks proxy, or an equivalent.
If your intent is to write a client that accesses web sites via HTTP, you will need to use your corporate HTTP proxy to do that. Contact your system administrator for more information.

Using Fiddler with IIS7 Express

I am using IIS7 Express while developing my web application. I need to use fiddler to investigate an issue and cannot figure out how to configure things so I can get the HTTP stream. It seems that IIS7 express will only listen on localhost which means I cannot access the stream.
This has nothing to do with IIS7 Express and everything to do with the fact that you're using loopback traffic.
Ref: https://www.fiddlerbook.com/fiddler/help/hookup.asp#Q-LocalTraffic
Click Rules > Customize Rules.
Update your Rules file like so:
static function OnBeforeRequest(oSession:Fiddler.Session)
{
if (oSession.HostnameIs("MYAPP")) { oSession.host = "localhost:portnumber"; }
}
Then, just visit http://myapp in your browser.
Or use the address http://localhost.fiddler/ and Fiddler will use the hostname localhost instead of converting to an IP address.
One useful variation of Eric's answer (that was edited by Brett) would be to use oSession.port to build the oSession.host. With this little change, if one needs to capture IIS express traffic on http://localhost:12345, they could use http://iisexpress:12345. That will make it easier to capture traffic for sites with random ports as created by WebMatrix and VS. I tried it out with IE and Firefox and capturing IIS Express traffic was a breeze. Fiddler rocks!.
static function OnBeforeRequest(oSession:Fiddler.Session)
{
//...
// workaround the iisexpress limitation
// URL http://iisexpress:port can be used for capturing IIS Express traffic
if (oSession.HostnameIs("iisexpress")) { oSession.host = "localhost:"+oSession.port; }
//...
}
With the latest version of fiddler, you only need to navigate to localhost.fiddler:port. However, doing that alone didn't help me and I was still getting access denied when using Windows Authentication. To fix this, I found this blog entry: http://www.parago.de/2013/01/fiddler-and-the-401-unauthorized-error-with-asp-net-web-api-using-integrated-windows-authentication-wia/
In short, create this key:
Key Path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Control\Lsa\MSV1_0
Value Name BackConnectionHostNames
Value Type REG_MULTI_SZ
String Value localhost.fiddler
You can use fiddler as a proxy between your clients and the server. This means you start up fiddler, and then access the server using fiddler's port rather then the usual port (default for fiddler2 is 8888 I think). If you need to debug the server "live" vs. real world clients, you can change the IIS binding from :80 to something else, and place fiddler's proxy on port 80.
EDIT: By the way, by default fiddler2 changes the proxy settings on your browsers so that they access everything through fiddler anyway (on the machine in which fiddler is installed only)

Accepting a socket on Windows 7 takes more than a second

Here's what I've done:
I wrote a minimal web server (using Qt, but I don't think it's relevant here).
I'm running it on a legal Windows 7 32-bit.
The problem:
If I make a request with Firefox, IE, Chrome or Safari it takes takes about one second before my server sees that there is a new connection to be accepted.
Clues:
Using other clients (wget, own test client that just opens a socket) than Firefox, IE, Chrome, Safari seeing the new connection is matter of milliseconds.
I installed Apache and tried the clients mentioned above. Serving the request takes ~50ms as expected.
The problem isn't reproducible when running Windows XP (or compiling and running the same code under Linux)
The problem seems to present itself only when connecting to localhost. A friend connected over the Internet and serving the connection was a matter of milliseconds.
Running the server in different ports has no effect on the 1 second latency
Here's what I've tried without luck:
Stopped the Windows Defender service
Stopped the Windows Firewall service
Any ideas? Is this some clever 'security feature' in Windows 7? Why isn't Apache affected? Why are only the browsers affected?
If you're saying "localhost" instead of "127.0.0.1", you're forcing a name lookup before the actual connection attempt, adding delay.
In addition, some browsers, like Firefox 3.5+, don't use the operating system's DNS lookup mechanism, which is why it can have different performance than, say, wget.
You may be running into some automatic proxy discovery problem. In Firefox, you can disable this in Options | Advanced | Network | Settings; select either "No proxy" or give it explicit values. There's also the Internet Properties control panel, which is IE's network settings, but other browsers on Windows may obey settings here, too. Again, disable auto-proxy discovery. This can speed connections outside localhost, too.
For some reason Windows 7 takes 1 second to resolve address localhost regardless of it being in hosts file.
Adding localhost1 to hosts file and using that works around the problem.
When connecting to localhost on a IPv4/IPv6 dual stack host:
A DNS lookup is performed for localhost.
The DNS server (whether IPv6 enabled or not - this doesn't matter) returns both the AAAA record ::1, and the A record 127.0.0.1.
The client first attempts to connect to ::1.
We assume your server program is not IPv6-capable, which is a common case - due to historical reasons, many servers bind their socket to 0.0.0.0 by default rather than [::].
Here an ECONNREFUSED error would be raised for the client. This happens immediately on most platforms; on Windows however, a single call to connect() would try 3 times in 500ms intervals before giving up, hence taking a bit more than one second (See http://stackoverflow.com/q/19440364 for more details).
The client then creates a connection to 127.0.0.1 instead.
This would explain all your clues above:
If you make a request with Firefox, IE, Chrome, Safari or any other IPv6-capable clients, it takes takes about one second trying for ::1 before connecting to 127.0.0.1.
Your own test client just opens a INET socket, so it won't try ::1 at all.
Using a dual-stack server such as Apache, the clients will connect to ::1 happily.
The problem isn't reproducible on Windows XP, of which IPv6 support is not enabled by default.
The problem seems to present itself only when connecting to localhost, as your friend connected with an IPv4-only network.
Running the server in different ports has no effect on the 1 second latency.