I have been using the NTP protocol for a while. Lately, I have encountered a strange issue. Namely, when I try to print a list of the peers known to the server it takes around 20 seconds. Earlier it took less time.
[root#centos-test centos]# time ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*ntp1.tp.pl .MRS. 1 u 18 64 3 2.093 -0.021 0.098
ntp2.tp.pl .MRS. 1 u 22 64 3 2.404 0.120 0.041
96-7.cpe.smnt.p 149.156.70.75 2 u 27 64 3 22.526 -2.296 0.089
ntp.wide-net.pl 194.146.251.101 2 u 30 64 3 65.808 -8.530 0.049
real 0m20.180s
user 0m0.017s
sys 0m0.011s
I have restarted everything. I have changed the pools but without any significant effect.
It looks like it may be an issue with your DNS resolvers.
When you ask ntp for peer or host details by default it will try and resolve the reverse DNS names for any listed hosts. If your resolvers are slow, or there are DNS issues then that will hang your response and explain the situation you are seeing.
If you try the same command with the -n flag that will tell ntp to only return the IP addresses and not attempt a DNS lookup.
The command in your case would be; time ntpq -p -n I'd suggest that you check what DNS servers you have setup in /etc/resolv.conf and change them - but do note, if your host gets its own IP address via DHCP then the resolv.conf might get updated when your address refreshes, or changes.
Related
I am attempting to run the FreeRTOS+TCP demo (release 10.1.1):
The code is written for the Windows Simulator, but I am attempting to target the Xilinx Zynq, emulated by QEMU (version 4.2.0). The host machine is Ubuntu 16.04. There exists a
Network Interface port for the TCP part of FreeRTOS+TCP, so this should be possible.
One of the obvious modifications to the demo is changing the way messages are printed, and removing calls to the Windows Sleep function. Also, I am using ARM semihosting to view the output of the print statements.
Besides these changes, what changes will I need to make to the command line call? The demo creates a TCP echo server and client. If these are tied together, then no traffic should need to go to the host, right? Is there anything special I would need to do to get this to work? I don't have a ton of experience with networking.
Since this is technically a baremetal application, CLI options like -nic user,hostfwd=tcp::5022-:22 give the warning qemu-system-arm: warning: nic cadence_gem.1 has no peer.
(Found at How to replace `qemu-system -redir` command argument?).
If I ever did want to send traffic between the host and guest (like having a ncat echo server, instead of in FreeRTOS), how would I go about doing that?
Here is a related problem, with no solution:
Running LWIP TCP/IP Stack with QEMU
Current command line arguments:
qemu-system-arm -semihosting --semihosting-config enable=on,target=native -nographic -serial mon:stdio -machine xilinx-zynq-a9 -m 512M -cpu cortex-a9 -nic user,hostfwd=tcp::12346-:7 -kernel build/rtos_demo_tcp/rtos_demo_tcp.elf
Current output (I enabled extra debug messages):
qemu-system-arm: warning: nic cadence_gem.1 has no peer
Seed for randomiser: 1591112953
Random numbers: 00001294 00001925 000022D0 00005CC3
FreeRTOS_IPInit
vTaskStartScheduler
prvIPTask started
Network buffers: 30 lowest 30
IP Address: 10.2.118.223
Subnet Mask: 255.255.255.0
Gateway Address: 10.2.118.1
DNS Server Address: 208.67.222.222
Socket 7 -> 0ip:0 State eCLOSED->eTCP_LISTEN
Then this next bit repeats indefinitely, with a different socket number each time:
FreeRTOS_connect: 14207 to a0276dfip:7
Socket 14207 -> a0276dfip:7 State eCLOSED->eCONNECT_SYN
ARP for a0276dfip (using a0276dfip): rc=0 00:00:00 00:00:00
Network buffers: 30 lowest 29
Connect[a0276dfip:7]: next timeout 1: 500 ms
ARP for a0276dfip (using a0276dfip): rc=0 00:00:00 00:00:00
Connect[a0276dfip:7]: next timeout 2: 500 ms
ARP for a0276dfip (using a0276dfip): rc=0 00:00:00 00:00:00
Connect[a0276dfip:7]: next timeout 3: 500 ms
Connect: giving up a0276dfip:7
Socket 14207 -> a0276dfip:7 State eCONNECT_SYN->eCLOSE_WAIT
FreeRTOS_closesocket[14207 to a0276dfip:7]: buffers 30 socks 1
Summary: How do I change the way I am calling QEMU so that the TCP client and server can connect to each other?
I would recommend trying out all of the options enumerated in the qemu networking guide:
- SLIRP: -netdev user,id=mynet0,net=192.168.76.0/24,dhcpstart=192.168.76.9
- TAP: -netdev tap,id=mynet0
- SOCKET: -netdev socket,id=mynet0,listen=:1234 and -netdev socket,id=mynet0,connect=:1234
And there is much more in the guide. Something you might also consider is that it might be difficult for you to port-forward directly from the VM you care about to the host, and it might be easier to connect that VM to another VM and port-forward from that second VM to your host.
Sounds a bit odd, but that's something I've needed to do before. To talk between two VM's I find sockets to be the best method. They work sort of like a "virtual crossover cable".
This VM to VM method would allow you to simply have to set up corresponding static IP's and subnets on each VM and then ncat's would work between them. Do away with all of the complexity of a DHCP server and any sort of port-forwarding.
I can't seem to get nmap brute force to work. I ran a scan with nmap which told me there is an open http port. This is just an example though, I've never got it to work. Anyways, I run this script:
nmap -p 81 --script rlogin-brute <IP> on the the target.
But unlike what it's supposed to to, this is the only response I am getting:
Host is up (0.070s latency).
PORT STATE SERVICE
81/tcp open hosts2-ns
Nmap done: 1 IP address (1 host up) scanned in 4.01 seconds
What am I doing wrong here? Like I said, I always get the same thing, no matter what script I am running or if it's tcp, ftp, http etc.
Thanks
You are using the rlogin-brute script, which works with the rlogin Unix service on port 513. Because the service name hosts2-ns and number 81 do not match, the script will not run. If you happen to know that the rlogin service is really running on this port, then adding -sV to your scan will detect the service and allow the script to run.
Take a look at the portrule:
portrule = shortport.port_or_service(513, "login", "tcp")
This means that it needs to detect port 513 as open. Since you specified -p 81, you're only scanning port 81 (bypassing 513).
You can't just pick which port you want to use no matter what servive if any is running on it and use a script developed for a different port and service.
I've installed Postgresql 9.4 on a windows server 2008. I am writing an application that will access this server from our Windows 7 machines. I also installed PGAdminIII on one workstation where I am developing.
I am not able to connect from the workstations. I get a "Server doesn't listen" message. I've looked online for some solutions but none seemed to help me.
On the Server where the service is running. I've tried and change the values through paAdminIII for the files pg_hba.conf and
It looks like pg_hba.conf was setup to listen to the loopback and then a range of ip addresses on the same computer. When I change the "host" key value of the ip_address range from 127.0.0.1/32 to 192.168.2.1/128 (and keep the other values the same -> all, all, md5) the service starts and then stop immediately.
If I leave it with 127.0.0.1/32 then it starts fine but I can not connect from the workstation.
I left the listen_addresses on the postgresql.conf file as the default "*" which is trying to listen to all addresses.
I am trying to develop a client/server app before moving it to the cloud and this is step 0.
I did install on my Windows 7 machine an "add_on" the VisualStudio to help me get a connect string down the line but I am only using the PostgreSql "tools" at this time.
I did some search to see if this question was asked before in this client/server scenario and did not find one. If it has already been answered I'd appreciate some pointers directing me to the correct way to configure server access, if not, then an answer on how to do it would be great.
I can ping the server with no problems from the workstation(s).
The IP address/CIDR mask specification of 192.168.2.1/128 is wrong. The last value indicates the number of bits to be masked, not an IP address range. If you want (most of) the range 192.168.2.1 - 192.168.2.128, the entry in pg_hba.conf should be 192.168.2.0/25 (meaning: take the three highest bytes 192.128.2 (24 bits), plus the highest order bit 0 of the last byte and let the 7 remaining bits vary (values 0 to 127).
Note that this includes 192.168.2.0 and excludes 192.168.2.128, but that is just how bit masking of IP addresses works. You could add 192.168.2.128 with a separate entry in pg_hba.conf, but you cannot get 192.168.2.0 out.
I have a CentOS 7 VPS which I had multiple sites on its Apache, and these days I faced a strange problem, CentOS lost its interface many times a day! and I should restart the interface to recover this situation! I've take a snapshot from Web console interface of my VPS, any idea? thanks in advance
grep dhclient /var/log/messages ferquently give me this error (also I have BOOTPROTO="dhcp" in my config file) :
Apr 30 15:12:56 vultr dhclient[8962]: dhclient.c:2676: Failed to send 300 byte long packet over fallback interface.
Apr 30 15:13:15 vultr dhclient[8962]: DHCPREQUEST on eth0 to 169.254.169.254 port 67 (xid=0x5f5ca74d)
Apr 30 15:13:15 vultr dhclient[8962]: send_packet: Network is unreachable
Apr 30 15:13:15 vultr dhclient[8962]: send_packet: please consult README file regarding broadcast address.
(I work for the host in this case)
There was an issue with the DHCP server that was causing some instances to lose their IP address on DHCP lease renewal. Specifically, the DHCP server would intermittently respond with a NAK, which would cause the server to lose it's IP address. Oddly, CentOS 7 doesn't seem to handle this nicely (nice behavior would be trying to obtain a new lease, rather then breaking connectivity until the interface was restarted).
You should no longer see issues with this.
i have a strange Problem with Nagios. After restart everything runs perfectly fine.
Then some hours later, Hosts are shown down and a minute later up again(see History log below). After that all Services fail with a timeout.
This doesn´t happen with all Servers at the same time. It seems rather randomly which Server fails.
History log:
[2013-06-26 19:19:07] SERVICE ALERT: HyperV 1;Check CPU HyperV 1;CRITICAL;SOFT;1;CHECK_NRPE: Socket timeout after 120 seconds.
[2013-06-26 19:17:27] HOST ALERT: HyperV 1;UP;SOFT;2;PING OK - Packet loss = 0%, RTA = 3.01 ms
[2013-06-26 19:16:17] HOST ALERT: HyperV 1;DOWN;SOFT;1;PING CRITICAL - Packet loss = 100%
What i have tried so far.
-Increased the timeouts
-Changed the Host check, so that it get checked more often before fail (5 times instead of 1)
-Executed the scripts from command line -> Also fail (maybe Ubuntu problem?)
-Checked Logs on both sides for errors (nothing found)
After a restart everything is fine again.
System Infos:
-Nagios is running on an Ubuntu 13.04
-Some clients are running different Windows with NSClient++
-ESX with Versions from 4.0 to 5.1
Plugins:
-check_nrpe
-check_vmfs from Nagios Exchange
I sth. is unclear don´t hesitate to ask.
Thx & Best,
Pille
You seem to have a networking issue, not a Nagios issue. Possibly a bad cable, failing NIC, routing problem, switch flapping, arp table overflow, could be any number of things.
Since this affects all hosts/services, and intermittently, and clears itself up, I would suggest you start looking for a problem on your local connections first. If it only affects some items and not others, then find which hosts have common network components and check there.