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').
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.
In our enterprise I don't have access to MSSQL Server, so I can'r access the system tables.
What works for me is:
capture the network traffic Wireshark (run as Administrator, select Network Interface),while opening connection to server.
Find the ip address with ping
filter with ip.dst == x.x.x.x
The port is shown in the column info in the format src.port -> dst.port
If you have elevated rights to SQL but not the OS, you can query the log.
If you don't have access to the OS but can run queries, perhaps try:
USE master
GO
xp_readerrorlog 0, 1, N'Server is listening on'
GO
If you don't have elevated rights to SQL, from the client-side windows machine with an active connection, you could run a netstat command and see on which ports you are connected to the target. Filter on IP address of the host.
netstat -an | find "10.1.10.xxx"
You'll see that I have connections to the host on 3389 and 1433. Maybe this helps narrow it down.
Firewall is turned off but still it is not able to execute put commend on ftp
ftp>cd /web
250 CWM command successful
ftp>binary
200 Type set to I
ftp>put C:\sample.xml
200 PORT command successful
425 Unable to build data connection: No route to host
Your script works in active mode, e.g. the client gives the server a client side ip and port using the PORT command and the server tries to connect to it. Because the server replies, that it has no route to your host my guess is, that
you are in an internal network, e.g. using a private IP which is not directly accessible from the internet. This IP is used in the PORT command.
the server is on the internet
from the internet the server of course can not connect into a private network, thus you get this error message
Fix: use passive mode (e.g. you should see a PASV not a PORT command)
Windows ftp.exe operates in passive mode and your FTP server may need active FTP transfers.
Test your commands on a different FTP server to see if it works elsewhere.
I installed Oracle 11g Standard Edition on my machine ( Windows 7 X64 ) and configured a listener. While being on the network , when I tried to connect through Jdev 11g , connection was successful. But when I'm off the network , I'm not able to connect to the Database thru Jdev. EM console is not opening too.
Is there any way I can connect to Database while I'm not on the network ?
Your listener has to be configured to listen to your localhost internal interface, 127.0.0.1, for you to be able to connect when not on a network.
If it's only configured with your network adapter's IP address you will only be able to connect while on the network. When you unplug your LAN cable the interface associated with that IP is disabled and no longer reachable, even from within your PC. You will also have problems if your IP is allocated by DHCP, and would need to use a DNS name that follows reallocation; that's why servers usually have fixed IPs.
You can configure the listener to use both addresses if you need to be able to connect locally when off the network, but have other clients connect to your database when you are on the network. Having a DB that others need to access on a machine that isn't always connected would be a bit odd though.
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