This is very straightforward. I have a WebSocketServer project that works great if the uri is http://localhost:8081/ but if I use the local IP instead of localhost http://10.0.0.201:8081/, it refuses to answer requests on that IP. I am sure its a permissions issue or unable to access the port issue but I am, frankly, not getting any errors. It just simply doesn't respond. Can anyone shed some light on this? This is all in c#.
Again this is a SERVER. It is supposed to LISTEN on 10.0.0.201 (and, of course, localhost). Localhost works, but the IP does not from any client.
I am intentionally not posting code (although I could if necessary) because this is a multi-threaded application that supports multiple concurrent clients. And it works flawlessly through localhost. I am only changing the word "localhost" to the machine's IP. The failure feels like a binding or permissions issue.
This is probably due to Http Binding in your webserver (e.g. IIS), the binding could be explicitly requiring localhost and if the URI does not have localhost then it would refuse this connection.
Try changing the binding to empty hostname and URI should be allowed.
This is a suggestion, not an answer. Have you tried hitting the WebServer from a different machine? Even if it's just a static test page?
It could be a perms problem, but this would at least tell you if any machine on the local network can get to it using the IP/Port configuration.
Try binding to *
If using HttpListener try this:
httpListener = new HttpListener();
httpListener.Prefixes.Add("http://*/");
instead of
httpListener.Prefixes.Add("http://localhost/");
httpListener.Prefixes.Add("http://10.0.0.201/");
Binding to localhost will not bind to all the rest, and binding to a specific IP address will not work with localhost or IPv6 for example.
Related
I was trying to connect to a server application I built. However, the annoying part is that the host machine of the server application have a dynamic IP. So, I googled around and found out that I can use Dns.GetHostAddresses. But the problem is Dns.GetHostAddresses actually gives all the target machine's IP Adress. Recently I used Dns.GetHostAddresses("Server_Host_Name")[0], which gives me the 1st IP address.
The method have worked so far. But I will like to know is there any safer way of doing this? or this method is fine?
Thanks for any reply and answer.
I don't think this is duplicate of System.Net.WebRequest not respecting hosts file since I do not believe my issues to be proxy related (and it's making the request to localhost essentially).
So I've got a C# ASP page that makes an HttpWebRequest. Now, on this server I've done some custom mapping of some dev domains to the server's IP address.
HttpWebRequest request = (HttpWebRequest)WebRequest.Create( "http://someproject.dev" );
ERROR:
The remote name could not be resolved: 'someproject.dev' at System.Net.HttpWebRequest.GetResponse()
My Hosts file on the server (and my client) has 10.0.1.115 someproject.dev
I've also tried it with 127.0.0.1 on the server
Another note, both .net apps are running under hosts file/IIS mappings, i.e. one app is making a x-domain request to the other (which is permitted, i know that's not the cause because this works in our production environment).
Also, I'd like to avoid System.Net.Dns, unless you guys agree that's the only way it will work.
I would check your server. Any web calls that are made from the server are checked to see if the DNS is in the hosts file. Sounds like a server problem instead of a programming problem.
Someone once told me that in WCF if you use a net.tcp binding but connect to a service that is actually on the localhost it will actually use a net.pipe binding underneath. I'm not sure if the address of the service needs to be localhost, the local IP, etc.
Is this true? Has anyone tested this? Is there any overhead?
Will using net.tcp inter-process open a socket back to the local machine?
I'm pretty sure it doesn't do that. That would be extremely confusing when things don't work the way you expect them to.
1 - How does it work? This question has come up because I am working with a guy for whom the call to System.Net.Dns.GetHostAddresses does not work. I gave him a sample app that just calls the aforementioned method and displays the IP addresses that are returned. Here is his explanation after using it:
When I try to resolve www.google.com [in the app]
it does not
work on the local workstations,
because our internal DNS do not
resolve external DNS names. [But] If I put
www.google.com in the browser, the
proxy server knows to go to the
external DNS servers for name
resolution and it resolves the name to
the IP address. Even if we put the
proxy server name in the application
it does not work when testing the
resolution.
I have done some packet sniffing on my work computer (which has a proxy server) and my personal computer (which does NOT have a proxy server) and there seem to be no packets sent or received durring the GetHostAddresses call. So, what exactly is that call doing?
2:
What port number is used?
Also asked by the person I am working with. I have no idea about this one. If there are no packets sent then it seems the answer would be there is no port being used, but I am not very savvy when it comes to ports and things like this. If anyone knows how to answer this or even a process for me to find the answer, please let me know.
DNS is a huge subject. Concerning Q1, it depends on how your machine is configured (node type). Googling on this should help you on the general principles.
Here is an answer about the ports: Network Ports Used by DNS
The reason in browser works and in command prompt does not is that browser has been setup to use a proxy and command prompt is not.
In order to see what code is used, use reflector. I have been told off to post any Microsoft code but I looked at the code and it was mainly unsafe and Win32 API calls.
The reason you're not seeing any network traffic when you use the packet sniffer could be that google.com is already in your local client DNS cache. If your browser has resolved it, it'll be in the cache. Try ipconfig /flushdns from the command line, and then use nslookup again to resolve google.com. I think you'll see some network traffic then.
I'm trying to parse a WSDL file which is in another server but has hard codded "localhost" all over the document.
When I fetch it, obviously the program complains "connection refused" because nothing is running in my machine.
My question is: Is it possible to use a webproxy ( such as fiddler ) to redirect those localhost request to my other server so the WSDL references are complete?
:-/
Thanks
p.s. I could always have fixed the remote "wsdl" but the guy on charge will be here until next week and I would like to start working today.
You could use Fiddler as the proxy from your machine, and then have it rewrite the WSDL to change localhost to the correct machine name.
The FiddlerScript CookBook has an example on how to write this sort of script. Go to that page and search for "Remove all DIV tags (and content inside the DIV tag)". Just change the regex to match localhost and set the replace to the machine name you want to use.
If you have SSH access to the machine, you should be able to use SSH port forwarding to accomplish this. I'm assuming you're using Windows (based on the C# tag), so you can use Putty as explained here: Using port forwarding with PuTTY. Just follow those instructions to forward the desired port on "localhost" to the server that serves the WSDL.
Alternatively, if you're on a *nix based machine or a Mac, use SSH w/ the following command:
ssh -L PORTYOUWILLUSE:localhost:PORTONSERVER username#serverhostname
For example, if the WSDL were served on port 80, you could do
ssh -L 80:localhost:80 username#server
Once you're logged in (with either method), any requests to localhost on port 80 will be rerouted to the server.
If you only want to change it for a few minutes while you parse the WSDL, you might be able to change the HOST file and point "localhost" to the remote IP address. The hosts file is in "C:\Windows\System32\drivers\etc" in Windows VISTA/XP.
There's a few ways you could achieve this, none are particularly robust as long-term solutions, but you mention you just want something temporary until the dev gets back.
If everything after the domain matches (if your remote URL is otherwise the same as the localhost one), you can edit your localhost entry in your hosts file.
In system32\drivers\etc, copy the "hosts" file onto your desktop. Open in notepad and change this line:
127.0.0.1 localhost
Change the IP address (127.0.0.1) to your remote domain. Then copy the hosts file back into the etc directory. (Note: it's not possible to edit this file directly, as Administrator or otherwise).
If you have multiple domains on the remote web service, in IIS, you need to change the web site to serve for requests to "localhost", this might seem a bit odd, but it'll work because your machine will make requests to the server's IP address, but specify the request domain as "localhost". Right-click the website in IIS and select properties, then add the domain "localhost" to the list of HTTP-Header values supported by that web site. You can ignore all of this if your web site in IIS will serve content if you access it via an IP address. If that single IP address is shared between multiple web sites (which is usually the case), you'll get a "Bad hostname" error from IIS as it attempts to look up "localhost" and can't find which web site to direct the request to.
Another possibility is to use a personal proxy server called Proxomitron. It's a little old, and no longer under development, but it's very easy to setup and very solid.
Once you've installed it, open it and click "Config" - change the port it listens on to 80. Next you need to create a redirect rule (it's not actually a redirect, more of a rewrite of the url). You'll need to have a quick read of the docs to understand how to add your own redirect, but there's plenty of samples that ship with the app. The rule you're looking for is RDIR:
$RDIR( ) Is more sneaky and redirects the connection in Proxomitron without telling your browser. This is useful when you want your browser to think it going one place when, in reality, it's going somewhere else.