libmysql mysql_real_connect fails with localhost but works with local IP address - c

I am using the libmysql C API, the mysql_real_connect call only works if I use the real IP address of the host - other than localhost. If I use localhost as host I get the
following error:
ERROR 2003 (HY000): Can't connect to MySQL server on 'localhost' (0)
The authentication should be ok, since the used user has all privileges from localhost and any host also.
By the way it is an XAMPP installation on Windows 7.

I had the same problem and the solution is to uninstall and disable IPv6 support, because if I had IPv6 support enabled then ping localhost command returns ::1: instead 127.0.0.1 as i have written in etc\hosts file, and sample mysql connect program written in C using libmysql do not connect when as host parameter to mysql_real_connect() i supplied "localhost". Now, after disabling IPv6 works both options ("localhost" or "127.0.0.1").
P.S.: I have tried this "solution" only in Windows XP SP3 Pro Czech. In Windows 7 and Linux I don't try this.

Either your DNS is broken (Does ping localhost work as expected?)
or the way "localhost" is specially treated is the problem.
The value of host may be either a host name or an IP address. If host
is NULL or the string "localhost", a connection to the local host is
assumed. For Windows, the client connects using a shared-memory
connection, if the server has shared-memory connections enabled.
Otherwise, TCP/IP is used.
see http://dev.mysql.com/doc/refman/5.0/en/mysql-real-connect.html

check if in your /etc/hosts file it's defined something like that: 127.0.0.1 localhost
check how mysql is binding its port:
root#dam2k:~# netstat -natp | grep 3306
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 2215/mysqld

Related

Connect WSL2 SQL Server localhost instance from Windows 10

I had setup a WSL2 Ubuntu. Now I am running a local SQL Server instance on the 1401 port using Docker.
Container port:
0.0.0.0:1401->1433/tcp
I would like to connect this instance from SSMS but I am getting following error:
Server name: localhost, 1401
Error:
Cannot connect to localhost,1401.
A network-related or instance-specific error occurred while
establishing a connection to SQL Server.
The server was not found or was not accessible. Verify that the
instance name is correct and that SQL Server is configured to allow
remote connections.
(provider: TCP Provider, error: 0 - The wait operation timed out.)
(Microsoft SQL Server, Error: 258)
[Solution]
I am able to connect it via the WSL2 IP. I run "hostname -I" command in WSL2 and use the same IP in SSMS. And, I am able to make a connection
First question -- Is there a VPN running/connected in Windows? If so, ignore the rest of this and suspect that first. Make sure the VPN is not running, stop Docker, issue a wsl --shutdown, restart and try again.
Assuming that's not the problem ...
Normally, WSL2 provides a feature known as "localhost forwarding" which allows services/apps on Windows to communicate with the virtualized WSL2 IP using localhost. It essentially takes any localhost traffic that isn't directed to a port bound under Windows and forwards it to the Hyper-V virtual network for WSL2.
All WSL2 instances (including the Docker instance) share the same WSL2 network interface as they are all running in the same virtual machine/kernel.
So you seem to be doing the right thing in attempting to connect to localhost from SSMS.
But ... sometimes that localhost forwarding breaks. There are two common (related) scenarios that can cause this (and perhaps others):
Hibernation of the Windows host
Having Windows Fast Startup enabled in Power Manager
First check to make sure you can access 1401 from within WSL2:
nc -zv localhost 1401
^^^ assumes netcat is installed, which it is by default in the WSL2 Ubuntu distribution. For other distributions, install it or check connectivity via other methods.
If that doesn't succeed, then I'd suspect some configuration issue in SQL Server.
If that does succeed, then run the same test from the Windows host in PowerShell:
Test-NetConnection -ComputerName "localhost" -Port 1401
If that doesn't succeed, then I'd suspect a localhost forwarding issue.
Side note: I'm assuming you are running Docker Desktop, but if you are just running Docker Engine in a WSL2 instance, that's no problem. Just ignore the Docker Desktop instructions below.
First, check if you have a /etc/wsl.conf in any of your running WSL2 instances that mention disabling localhostForwarding. I'm assuming no, since that is not the default. However, if you happen to, make sure you set these to true.
Stop all WSL2 services, instances, shells, apps, etc. (including Docker Desktop)
From PowerShell:
wsl --shutdown
Then restart Docker Desktop and/or your container and try again
If localhost doesn’t work, try use [::1] in the server name. In WSL2, port 1433 is using IP/TCPv6, SSMS some times is not able to resolve localhost to loopback IP [::1].
Source: https://jayfuconsulting.wordpress.com/2020/11/14/sql-server-2019-docker-wsl-2/
One last thing which you could try is to modify the windows host file. I almost tried all the steps mentioned over different link, but all goes in vain. Then I opened the host file which could be accessed using
C:\Windows\System32\Drivers\Etc
Open the host file and uncomment(remove # sign) from the localhost name resolution section

Connection to the database failed - server closed the connection unexpectedly. This probably means the server terminated abnormally

The rest of the error is "before or while processing the request."
I have a CentOS server running Postgres on an internal network scheme 192.168.11.0/24 for which I also have pgAdmin4 also installed and running. pgAdmin is connecting via localhost and I can successfully connect to my database.
I am running a windows 10 client on 192.168.11.100 with Lazarus trying to get a TPQConnection object to connect. This error comes up when I click the "Connected" property with all the connection information filled in.
The server is running on 192.168.11.25.
I have the Postgres client libraries extracted and in my system path (the bin directory) for the version of Postgres I'm running (12.5)
My pg_hba.conf file is set up to allow the connecton - Here are the relevant lines:
# "local" is for Unix domain socket connections only
local all all peer
# IPv4 local connections:
host all all 127.0.0.1/32 md5
host all all 192.168.11.0/24 md5
# IPv6 local connections:
host all all ::1/128 md5
I've set the password for the postgres user and verified that the account works with pgAdmin.
I'm not sure if this has to do with Lazarus or if this is a postgres client library problem.
I have also tried installing the Postgres ODBC client and attempted to create a DSN and was unsuccessful with that as well. I'm guessing this could be a configuration problem on the server not sure though.
Rich
I figured it out finally - been struggling with this for 2 days! By default Postgres only listens on localhost.
I had to edit postgresql.conf listen_addresses parameter and set it to '*' or equivalent IP address if I want to be more restrictive. With the pg_hba.conf restricting from which addresses login can happen on it seems perfectly sufficient to use '*' for listen_addresses.
After that I was able to connect from Lazarus.
Rich

ipmiutil is not able to discover server on lan connection

My goal is to get some IPMI based data from a HP Server through a local pc. I am using ipmiutil. I have installed the ipmiutil on local pc. I tried the following command to discover the server from local pc.
ipmiutil discover -b XXX.XXX.XXX.XXX.
But it says 1 ping sent 0 responses.
I have also tried the following command:
ipmiutil.exe fru -N XXX.XXX.XXX.XXX -U username -P mypassword
But I got the following error:
ipmiutil fru version 3.12
Connecting to node XXX.XXX.XXX.XXX
ipmilan_open_session error, rv = -3
ipmilan receive from BMC failed
ipmi_open error = -3 receive from BMC failed
ipmiutil fru, receive from BMC failed
I think it may be connection problem. I have checked the lan connection, the server is connected to the lan. Even through putty i can access that particular server. So What may be the reason to not able to connect the server through ipmiutil???
There must be something wrong with the IPMI LAN configuration on the HP server.
My guess is that the IPMI LAN configuration was only partially complete.
So perhaps the IPMI LAN gateway IP/MAC is not set, or the LAN Access Mode is incorrect.
Another possibility is that the IPMI LAN IP address is not set to something unique.
Its IP must be different from the OS IP address, and from other systems on that LAN.
You can see all of the relevant parameters by running 'ipmiutil lan' from the HP server, and comparing the IP and Gateway with that of the HP OS (If Linux: 'ip addr', 'ip route').

SQL Server TCP/IP times out

I have to connect to a fresh SQL Server Express 2017 on a machine not part of my domain. I have configured
Mixed Mode Installation with sa with password
SSMS -> Server -> Properties -> Connections -> Allow remote connections
SQL Configuration Manager -> Instance "EXPRESS2017" -> TCP/IP: Enable and Active and Port 1438
Restarted the "SQL Server (EXPRESS2017)" service.
I now tried to access from a remote computer, and got a timeout. I then tried to connect from the local SSMS, which works without special settings, but when under options, forced "Protocol: TCP/IP" is set, with the same credentials as before, I also got a timeout.
So am I right that I can rule out the firewall or problems finding the instance, and everything points towards a configuration issue in TCP/IP protocol, or did I overlook some setting?
EDIT: I have disabled Windows firewall, and no other firewall is installed on the computer. I have restarted the computer. I also found this article about PortQry and had a check - locally:
C:\Users\Administrator\Downloads>PortQry.exe -n 172.17.41.124 -p UDP -e 1434
Querying target system called:
172.17.41.124
Attempting to resolve IP address to a name...
IP address resolved to WIN-AECL8CJVS7E.test.local
querying...
UDP port 1434 (ms-sql-m service): NOT LISTENING
EDIT: I have run NETSTAT and it seems no port in the 14xx range is open at all, although the SQL Server Browser service is running. I must be missing something there...
You did not show your connection string, but I suppose you use your instance name here.
In order to connect to SQL Server the network library has to know 2 things: IP address and a port. Your instance is named and uses non-default port 1438.
So your connection string should use 172.17.41.124,1438 as server name, or, alternatively, you can use instance name like this: 172.17.41.124\EXPRESS2017 but SQL Server Browser should run.

What does a client need to connect remotely to an SQL Server?

i have set up a Microsoft SQL Server 2008 R2 Express on my home computer. My home computer has Windows 7 and is behind a router. I configured it i think ok, because i can connect to him from work through management studio. Means - i opened all necessary ports, i configured SQL to accept connections on TCP. I have also on my router set up DynDNS and i connect through my DNS name and it works.
I use also Microsoft PortQueryUI [ http://www.microsoft.com/download/en/details.aspx?id=24009 ] to test if the server is visible and from my work computer and it is visible. My PortQueryUI output at work is ok (attached bloew) but people from other networks cannot connect to my server.They have in the test to port 1434 UDP (big bold) an error code 0x00000002 where i have it correct - 0x00000000.
What is the reason, is there something that needs to be done on their computers? Maybe their network is blocking something?
My PortQueryUI output from work:
=============================================
Starting portqry.exe -n myhome.dyndns.net -e 1434 -p UDP ...
Querying target system called:
myhome.dyndns.net
Attempting to resolve name to IP address...
Name resolved to 83.xxx.xxx.xxx
querying...
UDP port 1434 (ms-sql-m service): LISTENING or FILTERED
Sending SQL Server query to UDP port 1434...
Server's response:
ServerName ROBERT-KOMPUTER
InstanceName SQL2008R2
IsClustered No
Version 10.50.1600.1
tcp 1433
np \\ROBERT-KOMPUTER\pipe\MSSQL$SQL2008R2\sql\query
==== End of SQL Server query response ====
UDP port 1434 is LISTENING
portqry.exe -n myhome.dyndns.net -e 1434 -p UDP exits with return code 0x00000000.
=============================================
Starting portqry.exe -n myhome.dyndns.net -e 1433 -p TCP ...
Querying target system called:
myhome.dyndns.net
Attempting to resolve name to IP address...
Name resolved to 83.xxx.xxx.xxx
querying...
TCP port 1433 (ms-sql-s service): LISTENING
portqry.exe -n myhome.dyndns.net -e 1433 -p TCP exits with return code 0x00000000.
Make sure port 1433 is open on your firewall where SQL is, you should probably put some sort of IP range/scope on that too for security.
You need to set your database to Accept Remote Connections in the DB properties.
You need to setup a username and password and give it access to the database so your remote connection recognizes it.
Here's an example of allowing the connection:
http://blogs.msdn.com/b/walzenbach/archive/2010/04/14/how-to-enable-remote-connections-in-sql-server-2008.aspx
Here's an example of connecting:
http://www.youtube.com/watch?v=hT9p_FPt720
I had the same problem but I had already setup open ports on 1433 on the firewall. The solution for me was simple on SQL 2012:
Goto "Sql Server Connection Manager"
Drop down SQL server network configuration
Protocols for MSSQLSERVER > Right click TCIP/IP
on every "TCP Port" entered 1433 or whatever port you wish
done
I have a non-default named instance. So I`ve had to enable and start the SQL Server Browser service on services.msc
Make sure to check Microsoft's troubleshooting below:
https://learn.microsoft.com/en-us/archive/blogs/sql_protocols/steps-to-troubleshoot-sql-connectivity-issues

Resources