I have 2 Virtual Machines. One is a Windows(say client). The other one is a CentOS(say server).
My Windows (Client) IP is 1.1.1.1
My CentOS (Server) has an app running and is listening on port 12345. IP address of the CentOS VM is 2.2.2.2.
I want to generate multiple pings from the windows VM from specific IP/ports to CentOS VM specific IP/ports.
i.e generate multiple pings from a certain port + source IP of 1.1.1.1 to destination IP of 2.2.2.2 + destination port number 12345.
I am looking for something like the foll:
**** ping DIP D.Port SIP S.Port -count 1000 ****
Please note: I need to run this ping from my windows CMD.
Is there a way I can do this from my windows CMD line?
check your system docs, on mine it is:
Mac_3.2.57$ping -S 10.0.0.148 -c 100000 1.1.1.1
PING 1.1.1.1 (1.1.1.1) from 10.0.0.148: 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=59 time=25.521 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=18.837 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=16.605 ms
Related
I find it costs one more seconds that ssh exec a simple command, does it normal? if not, how to speed up it?
[root#ops-test-vm-154:~]# time ssh root#10.17.1.155 'echo "hello,world!"'
hello,world!
real 0m1.805s
user 0m0.009s
sys 0m0.005s
there is low latency between vm-154 and vm-155
[root#ops-test-vm-154:~]# ping 10.17.1.155
PING 10.17.1.155 (10.17.1.155) 56(84) bytes of data.
64 bytes from 10.17.1.155: icmp_seq=1 ttl=64 time=0.142 ms
64 bytes from 10.17.1.155: icmp_seq=2 ttl=64 time=0.136 ms
64 bytes from 10.17.1.155: icmp_seq=3 ttl=64 time=0.129 ms
64 bytes from 10.17.1.155: icmp_seq=4 ttl=64 time=0.110 ms
^C
--- 10.17.1.155 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4421ms
rtt min/avg/max/mdev = 0.110/0.128/0.142/0.014 ms
BTW: I need check service status real time by executing a script in vm-155, so vm-154 execute command ssh vm-155 status.sh every second. But even a simple command echo helloworld cost one more second. So the solution is terrible. I hope speed up it, or may be a better solution.
Best Wishes!
There is vm-155 /etc/ssh/sshd_config, I add UseDNS no and execute service sshd restart, but still need one more second to echo hello,world!
Protocol 2
SyslogFacility AUTHPRIV
PasswordAuthentication yes
ChallengeResponseAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
UsePAM yes
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
X11Forwarding yes
UseDNS no
Subsystem sftp /usr/libexec/openssh/sftp-server
One thing that you could try is to run SSH in verbose mode and see at which stage it wastes the most time.
ssh -vvv root#10.17.1.155 'echo "hello,world!"'
And then based on your findings adopt your ssh config file to exclude slow cipher suites and other CPU intensive things. Some tips about that here.
However, you will not be able to achieve close to real-time performance over ssh if you establish a new connection every time. You could put your script/command into a loop and set seep value to 1s.
ssh root#10.17.1.155 'while true; do echo "Hello, world!"; sleep 1s; done'
But I would use something that is designed for such application like SNMP protocol. Here is an example configuration:
https://www.incredigeek.com/home/snmp-and-shell-script/
One source of delays during the SSH connection process is DNS lookups by the server. When a client connects to the server, the server can optionally look up the IP address of the client to get its hostname. Depending on a variety of issues, the query may take anywhere from a fraction of a second to ten seconds or more to complete.
The most widely deployed SSH server is OpenSSH. The OpenSSH sshd server has a setting named UseDNS which controls whether it performs DNS queries on incoming connections or not:
UseDNS
Specifies whether sshd(8) should look up the remote host name, and to check that the resolved host name for the remote IP address maps back to the very same IP address.
You should check that UseDNS is set to "no" on the server which you're connecting to.
I currently have a shell script which simply takes a URL as an argument and then sends a ping request to it as follows:
ping -c 5 $1
It is required of me to ping to the site using IPv4 and IPv6 where possible, I will then compare results. I have read the man page of ping and cannot see a flag which specifies which protocol to use, I was expecting it to accept a flag -4 for IPv4 and -6 for IPv6 but this does not seem to be the case.
I came across the DNS lookup utility dig which looks promising but have not managed to implement it in my code. My script must take a URL as an argument and no other arguments. I hope this is clear and thanks for your help.
Use ping and ping6 that are available in most distributions.
/tmp $ dig google.com A google.com AAAA +short
172.217.4.174
2607:f8b0:4007:801::200e
/tmp $ ping -c 2 172.217.4.174
PING 172.217.4.174 (172.217.4.174): 56 data bytes
64 bytes from 172.217.4.174: icmp_seq=0 ttl=53 time=35.619 ms
64 bytes from 172.217.4.174: icmp_seq=1 ttl=53 time=34.220 ms
/tmp $ ping6 -c 2 2607:f8b0:4007:801::200e
PING6(56=40+8+8 bytes) 2602:306:b826:68a0:f40e:abca:efdb:71f --> 2607:f8b0:4007:801::200e
16 bytes from 2607:f8b0:4007:801::200e, icmp_seq=0 hlim=55 time=77.735 ms
16 bytes from 2607:f8b0:4007:801::200e, icmp_seq=1 hlim=55 time=81.518 ms
I'm trying to understand the behaviour of ping command. Trying to experiment on a windows 7 PC.
On the command prompt, I issued the following command:
ping <some hostname> -l 4096
The output I get is
Pinging <some hostname> [xx.xx.xxx.xx] with 4096 bytes of data:
General failure.
General failure.
General failure.
General failure.
Ping statistics for xx.xx.xxx.xx:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
However, ping <same hostname> -l 32 works just fine.
So my question is why is the server behaving differently for different packet sizes? Is it related to thwart? Or is that my local ping program is configured by default in such a way so as to not sent bigger packets?
Note that -l flag lets you specify the ping req's buffer size.
Your ping packet is probably larger than the local media's MTU, and it's on a network type where fragmentation isn't allowed. Ethernet IPv6 would be one such configuration.
I am using LFTP to transfer files from a server, which unfortunately does not recognize the PORT command. I do not have control over the server (do not know in detail what server is) and I have to use the active mode.
This is the command line as:
lftp -e 'debug 10;set ftp:passive-mode off; set ftp:auto-passive-mode no; ls; bye;' -u user,password ftp://ftp.site.com
This is the debug output:
<--- 200 Using default language en_US
---> OPTS UTF8 ON
<--- 200 UTF8 set to on
---> OPTS MLST modify;perm;size;type;UNIX.group;UNIX.mode;UNIX.owner;
<--- 200 OPTS MLST modify;perm;size;type;UNIX.group;UNIX.mode;UNIX.owner;
---> USER xxxxx
<--- 331 Password required for xxxxx
---> PASS xxxxxx
<--- 230 User xxxxx logged in
---> PBSZ 0
<--- 200 PBSZ 0 successful
---> PROT P
<--- 200 Protection set to Private
---> PORT 172,16,133,11,146,168
<--- 500 Illegal PORT command
---> LIST
---> ABOR
---- Closing aborted data socket
---- Chiusura del socket di controllo
It seems that LFTP renounces to connect to data socket because the remote server does not support the PORT command. Is there a way to convince LFTP can still connect to port 20? By FTP manual obviously no problem.
The issue, I think, is not that the FTP server doesn't support the PORT command (it does), but rather, it doesn't like the IP address/port that your FTP client is sending in the PORT command.
PORT 172,16,133,11,146,168
...tells the server to connect to address 172.16.133.11, port 37544*. The interesting part here is the IP address: it's an RFC 1918 address (i.e. it's a private network address). That, in turn, suggests that your FTP client is in a LAN somewhere, and is connecting to an FTP server using a public IP address.
That remote FTP server cannot connect to a private network address; by definition, RFC 1918 address are not publicly routable.
Thus it very well could be that the FTP server is trying to make a connection to the address/port given in your PORT command, fails, thus that is why the FTP server fails the command, saying:
500 Illegal PORT command
To make a PORT command work with that FTP server, you would need to discover the public IP address that that server can connect to, to reach your client machine. Let's say that this address is 1.2.3.4. Then you would need to tell lftp to use that address in its PORT command, using the ftp:port-ipv4 option.
Chances are, though, that public IP address is the address of a NAT/router/firewall, and that that NAT/router/firewall will not allow connections, from the outside world to a high numbered port (e.g. 37544), to be routed to a machine within the LAN. This is one of the issues with active FTP data transfers, i.e. FTP data transfers which use the PORT (or EPRT) commands: they are not considered "firewall-friendly".
Hope this helps!
* - why 146,168 translates to port 37544?
According to FTP's RFC959 those parameters are:
(...) 16-bit TCP port address. This address information is broken into
8-bit fields and the value of each field is transmitted as a decimal
number (in character string representation).
146 dec = 10010010 bin = A
168 dec = 10101000 bin = B
A B
10010010 10101000 bin = 37544 dec
I have a url to a site and I vaguely remember there being a Windows console command that you can use to find the IP address of the server the site is deployed to. Can someone remind me? Also, can you tell me how to use it?
if you ping the server using the Windows command prompt, it will gives you the server IP.
ex.: ping www.google.com
C:\Users\Deleu>ping www.google.com
Pinging www.l.google.com [177.99.189.241] with 32 bytes of data:
Reply from 177.99.189.241: bytes=32 time=34ms TTL=58
Reply from 177.99.189.241: bytes=32 time=36ms TTL=58
Reply from 177.99.189.241: bytes=32 time=38ms TTL=58
Reply from 177.99.189.241: bytes=32 time=38ms TTL=58
Ping statistics for 177.99.189.241:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 34ms, Maximum = 38ms, Average = 36ms
C:\Users\Deleu>
You need nslookup.
Nslookup.exe is a command-line administrative tool for testing and
troubleshooting DNS servers. This tool is installed along with the
TCP/IP protocol through Control Panel. This article includes several
tips for using Nslookup.exe.
c:\Temp>nslookup google.com
Server: BoB.Orcon
Address: 10.1.1.1 <------ Name server
Non-authoritative answer:
Name: google.com
Addresses: 2404:6800:4006:804::1004 <----- Answer in ipv6
74.125.237.128 <----- Answer in ipv4
74.125.237.137 <----- Other answers....
74.125.237.134 .
74.125.237.132 .
74.125.237.135 .
74.125.237.133 etc
74.125.237.136 .
74.125.237.142 .
74.125.237.130 .
74.125.237.131 .
74.125.237.129