I am trying to use this c socket class, but it only works when I use it on my own computer.
Desktop only
Server is started like this: cSocketServer -p:2030 -i:192.168.178.22
Client connects: cSocketclient -p:2030 -s:192.168.178.22
Works fine.
Desktop server, laptop client
Server: cSocketServer -p:2030 -i:192.168.178.22
Client: cSocketclient -p:2030 -s:192.168.178.22
Exact same as above, but this fires the connect failed: 10060 error. Which essentially means it timed out.
Desktop only (external address)
Server: cSocketServer -p:2030 -i:192.168.178.22
Client: cSocketclient -p:2030 -s:xx.xx.xx.xx
Where xx.xx.xx.xx is my external ip address.
Same error: connect failed: 10060. Port 2030 is definitely open and accessible, because I tested it with a few unrelated applications that allow their users to choose their own ports (like utorrent). While those run, whatismyip.org states port 2030 is open. But when I run my application it sais it Timed-out. Those applications do not have any special privileges in the firewall.
But even if I did mess up some firewall/router settings (which I'm fairly sure I didn't) that wouldn't explain why I can't connect to the server from within my local network. Other services (such as file sharing) work fine so there is definitely a connection between the 2 computers.
Both client and server run on windows 7 64-bit.
Also; for some reason, each client that connects gets their own inbound port assigned or something? Is that normal? When clients connect the server states;
Accepted client: 192.168.178.22:55156
Accepted client: 192.168.178.22:55164
Accepted client: 192.168.178.22:55176
What's that all about?
If two TCP connections have the same source IP, destination IP, source port, and destination port, there would be no way to tell them apart. To ensure they differ somewhere, clients typically assign a unique source port to every outbound connection they make.
As for the errors, you really need to do some troubleshooting. Do the listening sockets show up in a 'netstat'? Do you get the same problem with the firewalls turned off? Are the server and client on the same LAN (for the internal address case)? Is port forwarding enabled and working in the router (for the external address case)?
My bet is that the external address case won't work because you haven't configured the port to be forwarded by your router or your router doesn't support hairpin (local access to external IP). Other programs may work because they support UPnP or don't rely on hairpin (all access to external IPs come from outside your LAN).
I have no immediate explanation for why your desktop-to-laptop won't work inside your LAN. Are you sure both computers are in the same LAN? Can they ping each other?
Get rid of the -i argument to the server, or specify 0.0.0.0 and fix the code so that isn't considered an error, which is itself an error.
Related
I have SQL Server Express 2017 running on Windows Server 2016 Standard (default instance, not named). It has remote connections enabled and is listening on port 1433 and has TCP/IP and Named Pipes enabled. I have several Surface Tablets running Windows 10 and Windows 11. These tablets make a VPN connection to the server to connect to SQL Server. All of the tablets, except one of them, can connect to SQL Server. All tablets connect using the server's IP address and with SQL Server Authentication. All tablets are connected to the same WiFi router - both the ones that CAN connect and the one that CANNOT, so I believe router settings are not the problem.
The tablet that fails to connect can ping the server successfully. It cannot, however, telnet to port 1433 on the server - this times out. All other tablets can make the telnet connection. Also, using sqlcmd to connect (sqlcmd -S ip-address -U user-name -P password) works on all tablets except the one. This returns error 53. Checking the SQL Server logs after attempting to connect using sqlcmd shows no errors. So this tablet is definitely not even reaching SQL Server.
I have disabled all Windows Firewall options on the tablet with no change - still cannot telnet or connect via sqlcmd.
I have walked through multiple remote connection troubleshooting guides step by step, but most of them assume that NO remote systems can connect to SQL Server. In this case, it is just one system. So I know that the server is configured properly to allow remote connections. I just cannot determine what is different about this one tablet that is preventing it from making a connection.
What might be preventing this one system from making this connection? Any settings or other options I should be looking at?
SOLVED: After performing tracert on multiple systems that connect to this server including the problem tablet as well as attempting to telnet to various ports at the server's IP address, I discovered that the WiFi network that the tablet was on had a conflicting IP address with the server. The previous tablets that tested fine were, unbeknownst to me, on different wifi networks that did not have this conflict. As a result, this tablet was attempting to connect to a completely different device despite being properly connected to the server's network via VPN.
So the additional piece of advice to add to this troubleshooting process would be to very closely scrutinize the output of ipconfig /all. Even though you may be connected to the network of the SQL Server system you are trying to connect to remotely, if the IP of the SQL Server system is duplicated on your local network, it can be very difficult to see that all of your connection attempts are actually routing to a different system - that is why the connection is failing.
What to look for in ipconfig /all... check the client system's IP address and the default gateway that it is using. If these are using private IP addresses (as most do) most commonly starting with 192.168.x.x, and you are trying to connect to SQL Server over VPN via which the server also has a private IP address, check if your local subnet is matching the server's subnet. For instance, both the client (tablet) subnet and the server subnet were 192.168.20.x There's a chance for an IP address conflict in these conditions.
Another check that I found was helpful was, on the client, to DISCONNECT from the remote server and then try to ping the SQL Server IP address. If the ping succeeds, the server's IP address is being duplicated by another system.
I want to connect to my server from another network, my server hasn't got an outside ip adress. I want to reach the sql server from where I host my website. I host my website somewhere else (not in my network).
Your SQL Server will have to be visible to the server from which you host your website.
I'm assuming you want to access the data in SQL Server to generate some content for your website.
There are 2 simple ways to do this:
Static IP - Ask your ISP for a static IP address for your local
network, you can use this in the connection string. This is preferable & more stable, since it will always be in sync.
Dynamic DNS - If your ISP won't give you a static address or you don't want to pay for it. You sign up with a DDNS service provider, they give you a domain name, like ferrysqlserver.ddns.org, and your network is visible to the internet via that name. Some routers support DDNS, otherwise you may have to run a service application that keeps your external ip address in sync with your DDNS provider.
Once you have either of those working, your network is now available to the internet, but nothing is likely accessible.
What you have done so far is to create a path from an internet name to your local router.
To make SQL Server accessible, you need to find out which ports your SQL Server uses (default is 1433). It's possible you may need to open other ports as well if you connect to SQL in a different way.
On your router, find the port forwarding options, and enable port forwarding to the local network ip address of your SQL Server, for port 1433.
This step maps connections from the internet to port 1433 of your router, and forwards those connections to port 1433 of your SQL Server.
Good luck.
Sorry if this is not the place to ask, but I am not sure if there is a forum for SQL port questions. It seems that my SQL client is using a random port to connect to the SQL server, in spite of me stipulating a specific port in the ODBC DSN connector. this is from Microsoft Network Monitor I have included the image to better illustrate what I mean.
You are reading it wrong. I see two kinds of connections, from WEBSERVER to 192.*.6 which I assume to be the Sql Server (the requests), and vice versa (the responses from Sql back to the Web Server).
When WEBSERVER is making a request, the DstPort is always 49252. The SrcPort fluctuates in that case because that is just how TCP/IP works (and that is also how multiple parallel connections can be distinguished). The Sql Server then always replies to whatever port number initiated the request.
It is expected that the source port (client) be random. The destination port (server) will be constant. When a TCP/IP client connects, it chooses an unused client port and connects to the server listening on a known port. This is basically how TCP/IP sockets work.
I am trying to connect from a NoMachine client on a Windows 7 machine to an OpenSUSE machine. I can only connect via NX however I keep running into Error 138:Connection Timed out. I can connect via SSH on my Command prompt however Seem to be unable to connect via here. Does anyone know a solution - been doing this since morning with no light in sight!
Routers supporting UPnP or NAT-PMP are configured automatically to pass connections to NoMachine and all required information is displayed at initial screen (Welcome to NoMachine).
Routers not supporting UPnP or NAT-PMP and Firewalls have to be configured manually to pass traffic to port 4000 (NX protocol), 22 (SSH protocol on Linux/MacOSX) or (4022) (SSH protocol on Windows).
So, check the configuration first.
I have a similar issue setting up my ftp server.
There are a couple of possibilities why the connection was not established, but in my case, and perhaps yours, you must allow the service you're trying to execute in your firewall settings.
In my case I allowed the ftp port and some other specific port for tcp communication.
This (and the proper service, router, etc setup) allowed the communication to be established.
I have two instances of SQL Server on my local machine. They both listen to separate ports. The first instance that I installed runs on the default port: 1433. I have set the other to listen to port 1434.
My application is using some old shared code that we have here to generate the connection string. So until now I didn't really know what was happening there. Due to a new requirement I found myself needing to examine the connection strings that I'm using to connect to the SQL Server.
What I found that was that for the connection string be built to connect to each of the SQL instances did not include Network Library, nor did they include the port number as part of the Data Source. The Data Source was just set to <Server Name>/<Instance Name>. I did find in the MS documentation that if the Network Library is not included then it is treated as (local), but it doesn't really explain how (local) is treated.
So my question is why is a connection string in this format able to connect to the SQL Server instance that runs on the non-default port? will this only work if the instances are on the local machine, or local network? Can I put <ip>/<sql instance> without the port if the server is remote?
I just need some clarity on how this works, and when is the port number needed and when it is optional as I'm trying to make my connection UI as simple as possible for our users.
There is such a thing called "SQL Server Browser Service":
http://technet.microsoft.com/en-us/library/ms181087(v=sql.105).aspx
It is intended to provide clients with information about sql server instances, ports. It actually listens on UDP port 1434.
With this service turned off you will still be able to connect to the instance, but you need to specify TCP/IP port.
I have two instances of SQL Server on my local machine. They both listen to separate ports. The first instance that I installed runs on the default port: 1433. I have set the other to listen to port 1434.
Just out of curiousity, why don't you just have them setup as named instances both running on the default of 1433 ?
As for why it works, if you search for SQL Configuration in your start menu, you'll find a screen similar to this.
Sql Server supports a number of different ways of connecting. TCP/IP is one way (ie IP addresses and ports) but it also supports a Shared Memory connection if you're on the local machine. that is, if you SQL Server executable, and management studio/client are also on the same machine.
At a guess I'd say it defaults to shared memory when you specify local and therefore you don't need to specify the port.
You could test this out by temporarily disabling shared memory in the above config, and see if your (local)\InstanceName stops working.