The client and server are both inside the firewall sitting on the local network. No issue with either end points to reach one another in terms of routing. The standard monitoring attributes like conn, info,ssh,trends serving through the server for the client page works, but I can't seem to get the *cpu,disk, memory* status from the client to the server to report.

xymonclient.log from the client host is consistently throwing "Whoops ! Failed to send message (timeout)"

*bbd* <http://stlxymon01/xymon-cgi/columndoc.sh?bbd> *clientlog* <http://stlxymon01/xymon-cgi/columndoc.sh?clientlog> *conn* <http://stlxymon01/xymon-cgi/columndoc.sh?conn> *cpu* <http://stlxymon01/xymon-cgi/columndoc.sh?cpu> *disk* <http://stlxymon01/xymon-cgi/columndoc.sh?disk> *files* <http://stlxymon01/xymon-cgi/columndoc.sh?files> *http* <http://stlxymon01/xymon-cgi/columndoc.sh?http> *info* <http://stlxymon01/xymon-cgi/columndoc.sh?info> *inode* <http://stlxymon01/xymon-cgi/columndoc.sh?inode> *memory* <http://stlxymon01/xymon-cgi/columndoc.sh?memory> *msgs* <http://stlxymon01/xymon-cgi/columndoc.sh?msgs> *ports* <http://stlxymon01/xymon-cgi/columndoc.sh?ports> *procs* <http://stlxymon01/xymon-cgi/columndoc.sh?procs> *ssh* <http://stlxymon01/xymon-cgi/columndoc.sh?ssh> *trends* <http://stlxymon01/xymon-cgi/columndoc.sh?trends> *xymond* <http://stlxymon01/xymon-cgi/columndoc.sh?xymond> *xymongen* <http://stlxymon01/xymon-cgi/columndoc.sh?xymongen> *xymonnet* <http://stlxymon01/xymon-cgi/columndoc.sh?xymonnet>

server [image: bbd:green:15d02h36m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=bbd> [image: clientlog:green:172.31.2.131] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=clientlog> [image: conn:green:14d22h02m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=conn> [image: cpu:green:6d02h08m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=cpu> [image: disk:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=disk> [image: files:clear:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=files> [image: http:green:2d00h06m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=http> [image: info:green:172.31.2.131] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=info> [image: inode:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=inode> [image: memory:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=memory> [image: msgs:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=msgs> [image: ports:green:6d02h40m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=ports> [image: procs:green:3d05h33m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=procs> [image: ssh:green:8d22h29m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=ssh> [image: trends:green:172.31.2.131] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=trends> [image: xymond:green:1d23h14m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=xymond> [image: xymongen:green:9d23h50m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=xymongen> [image: xymonnet:green:20h22m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=xymonnet> ADMIN *conn* <http://stlxymon01/xymon-cgi/columndoc.sh?conn> *info* <http://stlxymon01/xymon-cgi/columndoc.sh?info> *ssh* <http://stlxymon01/xymon-cgi/columndoc.sh?ssh> *trends* <http://stlxymon01/xymon-cgi/columndoc.sh?trends>

client [image: conn:green:10d20h30m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=conn> [image: info:green:172.31.0.13] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=info> [image: ssh:green:10d20h30m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=ssh> [image: trends:green:172.31.0.13] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=trends>

On Wed, May 18, 2016 at 5:19 PM, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:

On Thu, 19 May 2016, 07:27 Wonder fo <wonderfoo2 at gmail.com> wrote:

...

Hi Stef,

Your last tip was helpful to get through with the hump on getting the AIX client compiled and initial install.

...

Will connect to address 172.31.2.131 port 1984

...

9568302 2016-05-18 15:59:14.134814 Closing connection 2016-05-18 15:59:14.134870 Whoops ! Failed to send message (timeout) 2016-05-18 15:59:14.135049 -> 2016-05-18 15:59:14.135099 -> Recipient '172.31.2.131', timeout 15 2016-05-18 15:59:14.135185 -> 1st line: 'test'

It looks like a connectivity problem. Timeouts are usually caused by something n the path between the end points, invariably either a routing problem or a firewall problem. Note that a firewall can be on either host (eg iptables, ipfw, pf, etc).

Check that you can ping from client to server. If so, routing is ok. Then check that you can telnet to the server on port 1984. If not, suspect a firewall.

J

Hi Jeremy,

telnet is disabled by default on xymon server (running Centos 7.2.1511).

Below is probably an expected output consider the security risk of clear text protocol ?

telnet 172.31.2.131 1984

Trying...

*oliver* ohemming at gmail.com <xymon%40xymon.com?Subject=Re%3A%20%5BXymon%5D%20xymon%20for%20AIX&In-Reply-To=%3CCAOAEFMW2t%2B8SPaBvAH1NcmwSM2qG1tH3xiQA8%3DNRzH1AJUKk%3Dg%40mail.gmail.com%3E> *Thu May 19 22:41:32 CEST 2016*

• Previous message: [Xymon] xymon for AIX <http://lists.xymon.com/archive/2016-May/043502.html>
• Next message: [Xymon] Xymon Ticket <http://lists.xymon.com/archive/2016-May/043455.html>
• *Messages sorted by:* [ date ] <http://lists.xymon.com/archive/2016-May/date.html#43503> [ thread ] <http://lists.xymon.com/archive/2016-May/thread.html#43503> [ subject ] <http://lists.xymon.com/archive/2016-May/subject.html#43503> [ author ] <http://lists.xymon.com/archive/2016-May/author.html#43503>

What is the output from: client$ telnet 172.31.2.131 1984

On Thu, May 19, 2016 at 2:31 PM, Wonder fo <wonderfoo2 at gmail.com> wrote:

The client and server are both inside the firewall sitting on the local network. No issue with either end points to reach one another in terms of routing. The standard monitoring attributes like conn, info,ssh,trends serving through the server for the client page works, but I can't seem to get the *cpu,disk, memory* status from the client to the server to report.

xymonclient.log from the client host is consistently throwing "Whoops ! Failed to send message (timeout)"

*bbd* <http://stlxymon01/xymon-cgi/columndoc.sh?bbd> *clientlog* <http://stlxymon01/xymon-cgi/columndoc.sh?clientlog> *conn* <http://stlxymon01/xymon-cgi/columndoc.sh?conn> *cpu* <http://stlxymon01/xymon-cgi/columndoc.sh?cpu> *disk* <http://stlxymon01/xymon-cgi/columndoc.sh?disk> *files* <http://stlxymon01/xymon-cgi/columndoc.sh?files> *http* <http://stlxymon01/xymon-cgi/columndoc.sh?http> *info* <http://stlxymon01/xymon-cgi/columndoc.sh?info> *inode* <http://stlxymon01/xymon-cgi/columndoc.sh?inode> *memory* <http://stlxymon01/xymon-cgi/columndoc.sh?memory> *msgs* <http://stlxymon01/xymon-cgi/columndoc.sh?msgs> *ports* <http://stlxymon01/xymon-cgi/columndoc.sh?ports> *procs* <http://stlxymon01/xymon-cgi/columndoc.sh?procs> *ssh* <http://stlxymon01/xymon-cgi/columndoc.sh?ssh> *trends* <http://stlxymon01/xymon-cgi/columndoc.sh?trends> *xymond* <http://stlxymon01/xymon-cgi/columndoc.sh?xymond> *xymongen* <http://stlxymon01/xymon-cgi/columndoc.sh?xymongen> *xymonnet* <http://stlxymon01/xymon-cgi/columndoc.sh?xymonnet>

server [image: bbd:green:15d02h36m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=bbd> [image: clientlog:green:172.31.2.131] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=clientlog> [image: conn:green:14d22h02m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=conn> [image: cpu:green:6d02h08m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=cpu> [image: disk:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=disk> [image: files:clear:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=files> [image: http:green:2d00h06m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=http> [image: info:green:172.31.2.131] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=info> [image: inode:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=inode> [image: memory:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=memory> [image: msgs:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=msgs> [image: ports:green:6d02h40m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=ports> [image: procs:green:3d05h33m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=procs> [image: ssh:green:8d22h29m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=ssh> [image: trends:green:172.31.2.131] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=trends> [image: xymond:green:1d23h14m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=xymond> [image: xymongen:green:9d23h50m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=xymongen> [image: xymonnet:green:20h22m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=xymonnet> ADMIN *conn* <http://stlxymon01/xymon-cgi/columndoc.sh?conn> *info* <http://stlxymon01/xymon-cgi/columndoc.sh?info> *ssh* <http://stlxymon01/xymon-cgi/columndoc.sh?ssh> *trends* <http://stlxymon01/xymon-cgi/columndoc.sh?trends>

client [image: conn:green:10d20h30m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=conn> [image: info:green:172.31.0.13] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=info> [image: ssh:green:10d20h30m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=ssh> [image: trends:green:172.31.0.13] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=trends>

On Wed, May 18, 2016 at 5:19 PM, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:

...

On Thu, 19 May 2016, 07:27 Wonder fo <wonderfoo2 at gmail.com> wrote:

...

Hi Stef,

Your last tip was helpful to get through with the hump on getting the AIX client compiled and initial install.

...

Will connect to address 172.31.2.131 port 1984

...

9568302 2016-05-18 15:59:14.134814 Closing connection 2016-05-18 15:59:14.134870 Whoops ! Failed to send message (timeout) 2016-05-18 15:59:14.135049 -> 2016-05-18 15:59:14.135099 -> Recipient '172.31.2.131', timeout 15 2016-05-18 15:59:14.135185 -> 1st line: 'test'

It looks like a connectivity problem. Timeouts are usually caused by something n the path between the end points, invariably either a routing problem or a firewall problem. Note that a firewall can be on either host (eg iptables, ipfw, pf, etc).

Check that you can ping from client to server. If so, routing is ok. Then check that you can telnet to the server on port 1984. If not, suspect a firewall.

J

On 25/05/2016 4:14 AM, "Wonder fo" <wonderfoo2 at gmail.com> wrote:

Hi Jeremy,

telnet is disabled by default on xymon server (running Centos 7.2.1511).

As it should be, the telnet daemon is disabled. But not the telnet client. The centos should not allow anyone to connect to it, but shouldn't stop you connecting from it to other devices that use telnet.

As an aside, telnet can be secured using kerberos.

Below is probably an expected output consider the security risk of clear text protocol ?

Actually, no, it's not. Here, you are using the telnet command for something other than the telnet protocol. This is an old sysadmin trick. The telnet command primarily just connects to a TCP service, but that doesn't have to be the telnet service, it can be practically any TCP service. It might be a bit confusing at first, but it works; it's as if the command is really called "socket", and just happens to connect on the telnet port by default. But specify another service port, and you have a primitive tcp client for that other service. In fact people have even used telnet in place of a xymon client binary on systems where compiling or installing binaries is not possible.

For kicks, try using it to connect to the ssh port on the Centos server, from itself.

telnet 127.1 22

If you run an ssh service on the Centos server, then the above command will successfully connect, and also give you an ssh protocol banner. (To disconnect, press ctrl-] and type quit.)

Here, we are using telnet like netcat (aka nc). Netcat is a generic socket connection tool that is much more flexible than the telnet client, but telnet is more universally available, which is why it's so popular as a socket test tool in the sysadmin's toolbox.

telnet 172.31.2.131 1984

Trying...

This should say "connected" almost instantly. The fact that it says neither "connected" nor "refused" tells me that there's a firewall dropping packets. As you say, there's no firewall between the client and server. So the most likely cause is a firewall /on/ the client or server. That would be something like iptables (technically called netfilter) on the Centos Xymon server, restricting incoming connections on port 1984, or something like TCP/IP filters on the AIX Xymon client, restricting outbound connections. Try running "iptables-save" on the Xymon server to see if there are rules defined; try running "lsfilt" on the Xymon client to see if there are rules defined.

Cheers Jeremy

In case you need them, here are the firewall commands I used:

[root at xymontest rc3.d]# firewall-cmd --permanent --zone=public --add-port=80/tcp success [root at xymontest rc3.d]# firewall-cmd --permanent --zone=public --add-port=1984/tcp success [root at xymontest rc3.d]# firewall-cmd --reload

I also just created a service file for startup/shutdown. This may be helpful to you down the road so you won't have to re-invent the wheel. It took me a while and asking a CentOS mailing list to find the answer:

"/usr/lib/systemd/system/xymon.service" 27L, 816C

xymonlaunch.service

systemd file for Fedora 18 and up, or RHEL 7 and up

[Unit] Description=Xymon systems and network monitor Documentation=man:xymon(7) man:xymonlaunch(8) man:xymon(1) After=network.target

[Install]

Compatibility with "xymon" and "xymon-client"

Alias=xymon.service Alias=xymon-client.service WantedBy=multi-user.target

[Service] #EnvironmentFile=/etc/sysconfig/xymonlaunch User=xymon

We wrap in xymoncmd to eliminate the need for the bulk of the old init

script ExecStart=/home/xymon/server/bin/xymoncmd /home/xymon/server/bin/xymonlaunch --no-daemon $XYMONLAUNCHOPTS Type=simple

Kill xymonlaunch, but don't send kills to the underlying procs, since they

might be doing important things (like writing checkpoints and flushing

caches) KillMode=process

SendSIGHUP=yes

SendSIGKILL=no

######################################## - next run the commands below after creating this service file systemctl enable xymon.service systemctl start xymon.service

I had issues where it would only stop or only start. It was not obvious how to write this. Hope you find this helpful

John

On Tue, May 24, 2016 at 6:49 PM, John Langbein <bigbandjohn at gmail.com> wrote:

This sounds like a firewall issue. Search for open poet firewall centos 7 and the command should come up. I just had the same issue. On May 24, 2016 6:46 PM, "Jeremy Laidman" <jlaidman at rebel-it.com.au> wrote:

...

On 25/05/2016 4:14 AM, "Wonder fo" <wonderfoo2 at gmail.com> wrote:

...

Hi Jeremy,

telnet is disabled by default on xymon server (running Centos

7.2.1511).

As it should be, the telnet daemon is disabled. But not the telnet client. The centos should not allow anyone to connect to it, but shouldn't stop you connecting from it to other devices that use telnet.

As an aside, telnet can be secured using kerberos.

...

Below is probably an expected output consider the security risk of clear text protocol ?

Actually, no, it's not. Here, you are using the telnet command for something other than the telnet protocol. This is an old sysadmin trick. The telnet command primarily just connects to a TCP service, but that doesn't have to be the telnet service, it can be practically any TCP service. It might be a bit confusing at first, but it works; it's as if the command is really called "socket", and just happens to connect on the telnet port by default. But specify another service port, and you have a primitive tcp client for that other service. In fact people have even used telnet in place of a xymon client binary on systems where compiling or installing binaries is not possible.

For kicks, try using it to connect to the ssh port on the Centos server, from itself.

telnet 127.1 22

If you run an ssh service on the Centos server, then the above command will successfully connect, and also give you an ssh protocol banner. (To disconnect, press ctrl-] and type quit.)

Here, we are using telnet like netcat (aka nc). Netcat is a generic socket connection tool that is much more flexible than the telnet client, but telnet is more universally available, which is why it's so popular as a socket test tool in the sysadmin's toolbox.

...

telnet 172.31.2.131 1984

Trying...

This should say "connected" almost instantly. The fact that it says neither "connected" nor "refused" tells me that there's a firewall dropping packets. As you say, there's no firewall between the client and server. So the most likely cause is a firewall /on/ the client or server. That would be something like iptables (technically called netfilter) on the Centos Xymon server, restricting incoming connections on port 1984, or something like TCP/IP filters on the AIX Xymon client, restricting outbound connections. Try running "iptables-save" on the Xymon server to see if there are rules defined; try running "lsfilt" on the Xymon client to see if there are rules defined.

Cheers Jeremy

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

Check the “Ghost Clients” report under the Reports menu. If they are there, you may need to add CLIENT:<whatevername> to your hosts.cfg to make it clear that the client name is different than what the server expected. My Solaris clients were like this — they return the short name to Xymon. Probably this could be fixed automatically in the distribution, actually.

On May 25, 2016, at 2:44 PM, L Foo <wonderfoo2 at gmail.com> wrote:

Thank you all for the valuable input! Appreciate it.

The netcat to port 1984 seems to have went through/connected ok based on below output:

nc -v 172.31.2.131 1984

Ncat: Version 6.40 ( http://nmap.org/ncat ) Ncat: Connected to 172.31.2.131:1984.

p.s: The client pages are still not visible for AIX clients.

Thanke!

On Wednesday, May 25, 2016 9:25 AM, John Langbein <bigbandjohn at gmail.com> wrote:

In case you need them, here are the firewall commands I used:

[root at xymontest rc3.d]# firewall-cmd --permanent --zone=public --add-port=80/tcp success [root at xymontest rc3.d]# firewall-cmd --permanent --zone=public --add-port=1984/tcp success [root at xymontest rc3.d]# firewall-cmd --reload

I also just created a service file for startup/shutdown. This may be helpful to you down the road so you won't have to re-invent the wheel. It took me a while and asking a CentOS mailing list to find the answer:

"/usr/lib/systemd/system/xymon.service" 27L, 816C

xymonlaunch.service

systemd file for Fedora 18 and up, or RHEL 7 and up

[Unit] Description=Xymon systems and network monitor Documentation=man:xymon(7) man:xymonlaunch(8) man:xymon(1) After=network.target

[Install]

Compatibility with "xymon" and "xymon-client"

Alias=xymon.service Alias=xymon-client.service WantedBy=multi-user.target

[Service] #EnvironmentFile=/etc/sysconfig/xymonlaunch User=xymon

We wrap in xymoncmd to eliminate the need for the bulk of the old init script

ExecStart=/home/xymon/server/bin/xymoncmd /home/xymon/server/bin/xymonlaunch --no-daemon $XYMONLAUNCHOPTS Type=simple

Kill xymonlaunch, but don't send kills to the underlying procs, since they

might be doing important things (like writing checkpoints and flushing caches)

KillMode=process

SendSIGHUP=yes

SendSIGKILL=no

######################################## - next run the commands below after creating this service file systemctl enable xymon.service systemctl start xymon.service

I had issues where it would only stop or only start. It was not obvious how to write this. Hope you find this helpful

John

On Tue, May 24, 2016 at 6:49 PM, John Langbein <bigbandjohn at gmail.com> wrote: This sounds like a firewall issue. Search for open poet firewall centos 7 and the command should come up. I just had the same issue. On May 24, 2016 6:46 PM, "Jeremy Laidman" <jlaidman at rebel-it.com.au> wrote: On 25/05/2016 4:14 AM, "Wonder fo" <wonderfoo2 at gmail.com> wrote:

...

Hi Jeremy,

telnet is disabled by default on xymon server (running Centos 7.2.1511).

As it should be, the telnet daemon is disabled. But not the telnet client. The centos should not allow anyone to connect to it, but shouldn't stop you connecting from it to other devices that use telnet. As an aside, telnet can be secured using kerberos.

...

Below is probably an expected output consider the security risk of clear text protocol ? Actually, no, it's not. Here, you are using the telnet command for something other than the telnet protocol. This is an old sysadmin trick. The telnet command primarily just connects to a TCP service, but that doesn't have to be the telnet service, it can be practically any TCP service. It might be a bit confusing at first, but it works; it's as if the command is really called "socket", and just happens to connect on the telnet port by default. But specify another service port, and you have a primitive tcp client for that other service. In fact people have even used telnet in place of a xymon client binary on systems where compiling or installing binaries is not possible. For kicks, try using it to connect to the ssh port on the Centos server, from itself.

telnet 127.1 22

If you run an ssh service on the Centos server, then the above command will successfully connect, and also give you an ssh protocol banner. (To disconnect, press ctrl-] and type quit.) Here, we are using telnet like netcat (aka nc). Netcat is a generic socket connection tool that is much more flexible than the telnet client, but telnet is more universally available, which is why it's so popular as a socket test tool in the sysadmin's toolbox.

telnet 172.31.2.131 1984

Trying... This should say "connected" almost instantly. The fact that it says neither "connected" nor "refused" tells me that there's a firewall dropping packets. As you say, there's no firewall between the client and server. So the most likely cause is a firewall /on/ the client or server. That would be something like iptables (technically called netfilter) on the Centos Xymon server, restricting incoming connections on port 1984, or something like TCP/IP filters on the AIX Xymon client, restricting outbound connections. Try running "iptables-save" on the Xymon server to see if there are rules defined; try running "lsfilt" on the Xymon client to see if there are rules defined. Cheers Jeremy

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

--

|| \\UTGERS, |---------------------------*O*--------------------------- ||_// the State | Ryan Novosielski - novosirj at rutgers.edu || \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus || \\ of NJ | Office of Advanced Research Computing - MSB C630, Newark `'

Thanks for ALL your valuable feedback!  The hint from Ryan seemed to have cured the client page reporting issues. As it turned out, the AIX clients in questioned showed up in 'Ghost Clients' list on in short hostname as opposed to it's real FQDN hostname. I've since updated the xymon server side configuration's files for the said AIX clients from FQDN hostname to short hostnames, the client pages were getting proper updates now. Thank you Ryan!!!

On Thursday, May 26, 2016 12:05 AM, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:

On Thu, May 26, 2016 at 4:44 AM L Foo <wonderfoo2 at gmail.com> wrote:

The netcat to port 1984 seems to have went through/connected ok based on below output:

nc -v 172.31.2.131 1984

Ncat: Version 6.40 ( http://nmap.org/ncat )Ncat: Connected to 172.31.2.131:1984.

You ran this on the AIX host?  If this works, then telnet should have also worked, and so should the xymon client. Can you please try the following (on the AIX host):

echo "ping" | nc 127.31.2.131 1984

That should return the xymon version details of the Xymon server. Then try this:

/xymon/bin/xymon 172.31.2.131 ping

You should see the same thing.  Or maybe a timeout If this doesn't work, then can you try this:

truss -f /xymon/bin/xymon 172.31.2.131 ping

I'm particularly interested in the output around socket() and connect() calls, and what responses codes are given. I'm wondering if you have some sort of kernel-based binary restrictions in place, such as Trusted AIX, TCB or Trusted Execution.  From what I can tell, these tools allow one to lock down a server so that no unauthorized binaries can execute, or they might be able to execute but cannot perform certain functions. An alternative to all of this is to use my xymon-rclient script, available on xymonton.org, or http://tools.rebel-it.com.au/xymon-rclient.  Essentially it allows for an clientless client by pushing the Xymon client script to the target from the Xymon server (typically over ssh) and grabs the client data directly.  In this way, it doesn't rely on a xymon client binary.  There are some limitations, which is why it's better to try to get your client working, but it may be easier to get something going this way. CheersJeremy