webadmin-list

[webmin-l] Strange issues with ICMP monitoring

[Joaquim H. <jo...@we...>]

Hello, hope everyone is safe from the stuff that's going on.


I seem to have come across a really strange issue with ICMP monitoring 
or "Ping".

On a host running Webmin 1.960 and Ubuntu 18.04.LTS, I get error reports 
from *all* monitors of the type "Ping", indicating the monitor is down.

It only happens on this particular host.

What's strange is that other monitors, like HTTP/WEB (80/443) monitors 
all work, even those to the same hosts. Doing a check with mtr -r -c 10 
<host> from the Webmin host to any of the failing monitored hosts, 
everything looks good.

If I do a "manual" ping, using "ping <host>", everything looks good.

Re-starting Webmin does not help. Doing a "shutdown -r now" on the 
Webmin host works.

Time to wait for response is set to 10s.

I've tried using both hostnames and IP-addresses, no difference. All 
hostnames resolve to IPv4 addresses only.

I would really like to nail this odd behavior ... is there any way I can 
configure some more debug output from Webmin monitors?

There are no weird entries in /var/webmin/webmin.log

The only "error looking" entries in /var/webmin/miniserv.error I can see 
are these, but they don't appear to be related to this issue:


[06/Nov/2020:00:30:50 +0200] IPv6 support cannot be enabled without the 
Socket6 perl module
[06/Nov/2020:00:30:50 +0200] Using MD5 module Digest::MD5
[06/Nov/2020:00:30:50 +0200] Using SHA512 module Crypt::SHA
[06/Nov/2020:00:30:50 +0200] PAM authentication enabled
Use of uninitialized value in numeric ne (!=) at 
/usr/share/webmin/bind8/bind8-lib.pl line 2406.
[08/Nov/2020:20:55:12 +0200] miniserv.pl started
[08/Nov/2020:20:55:12 +0200] IPv6 support cannot be enabled without the 
Socket6 perl module
[08/Nov/2020:20:55:12 +0200] Using MD5 module Digest::MD5
[08/Nov/2020:20:55:12 +0200] Using SHA512 module Crypt::SHA
[08/Nov/2020:20:55:12 +0200] PAM authentication enabled
Use of uninitialized value in numeric ne (!=) at 
/usr/share/webmin/bind8/bind8-lib.pl line 2406.
[10/Nov/2020:21:22:06 +0200] miniserv.pl started
[10/Nov/2020:21:22:06 +0200] IPv6 support cannot be enabled without the 
Socket6 perl module
[10/Nov/2020:21:22:06 +0200] Using MD5 module Digest::MD5
[10/Nov/2020:21:22:06 +0200] Using SHA512 module Crypt::SHA
[10/Nov/2020:21:22:06 +0200] PAM authentication enabled



-joho

Re: [webmin-l] Strange issues with ICMP monitoring

[Joaquim H. <jo...@we...>]

So, this keeps happening even after upgrading the server to Ubuntu 
20.04.1.LTS and Webmin 1.962.

While Webmin fails, access into the server using SSH works, as does the 
Webmin web interface, as does outbound network access (i.e. ping <remote 
host>, and so on). But Webmins internal ICMP/ping "checking code" does not.

If I re-boot the server, all is well.

Could it be the number of "ping monitors" (21) that's causing this ... ?


-joho


On 2020-11-10 20:29, Joaquim Homrighausen wrote:
> I seem to have come across a really strange issue with ICMP monitoring 
> or "Ping".
>
> On a host running Webmin 1.960 and Ubuntu 18.04.LTS, I get error 
> reports from *all* monitors of the type "Ping", indicating the monitor 
> is down.
>
> It only happens on this particular host.
>

Re: [webmin-l] Strange issues with ICMP monitoring

[Eric T. <eri...@tr...>]

Sorry new to the list, but what are you running?
VirtualMin, Webmin, Cloudmin?

My first guess would be a fail2ban issue as that is a popular dictionary attack mitigation method, so a cluster of webmin servers with an incorrect password on one would cause this.

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300

> On Dec 8, 2020, at 4:49 PM, Joaquim Homrighausen <jo...@we...> wrote:
> 
> 
> 
> So, this keeps happening even after upgrading the server to Ubuntu 20.04.1.LTS and Webmin 1.962.
> 
> While Webmin fails, access into the server using SSH works, as does the Webmin web interface, as does outbound network access (i.e. ping <remote host>, and so on). But Webmins internal ICMP/ping "checking code" does not.
> 
> If I re-boot the server, all is well.
> 
> Could it be the number of "ping monitors" (21) that's causing this ... ?
> 
> 
> 
> -joho
> 
> 
> 
> On 2020-11-10 20:29, Joaquim Homrighausen wrote:
>> I seem to have come across a really strange issue with ICMP monitoring or "Ping".
>> On a host running Webmin 1.960 and Ubuntu 18.04.LTS, I get error reports from *all* monitors of the type "Ping", indicating the monitor is down.
>> 
>> It only happens on this particular host.
>> 
> 
> -
> Forwarded by the Webmin mailing list at web...@li...
> To remove yourself from this list, go to
> http://lists.sourceforge.net/lists/listinfo/webadmin-list

Re: [webmin-l] Strange issues with ICMP monitoring

[Joaquim H. <jo...@we...>]

Hi there

As stated in the post(s), Webmin 1.962 on Ubuntu 20.04.LTS.

We do indeed use fail2ban on the servers being "pinged", but the ping 
interval is set rather high.

The checking server all of a sudden starts reporting monitors as being 
down, but they are actually not. If I ssh into that checking server, and 
issue ping to the servers reported as being down by Webmin, I get a 
response. Every time.

If I reboot the checking server, which takes about 10-15 seconds, 
everything goes back to normal.

It sounds/looks to me like a "build-up" issue, but I've only ever seen 
this on that particular server. It happened with Ubuntu 18.04.LTS, and 
it's happening with Ubuntu 20.04.1.LTS.

It happens frequently, but not every day.

The checking server is not logging in to the remote servers, it's simply 
sending ICMP/pings.


-joho


On 2020-12-08 23:04, Eric Tykwinski wrote:
> Sorry new to the list, but what are you running?
> VirtualMin, Webmin, Cloudmin?
>
> My first guess would be a fail2ban issue as that is a popular 
> dictionary attack mitigation method, so a cluster of webmin servers 
> with an incorrect password on one would cause this.

Re: [webmin-l] Strange issues with ICMP monitoring

[Joaquim H. <jo...@we...>]

So this is still happening with 1.979. I'm now bumping to 1.980, but not 
expecting much to change.

I've switched from Webmin's internal "ping" to using "Use command 
suitable for Linux or FreeBSD". No change.

I've moved the "ping monitors" to another host. No change.

Is there a way to enable some sort of debugging for "System and server 
status" pings ... ?

I run a self-written Python script on the same server, that basically 
does the same type of ping monitoring, and it *never* reports a "down" 
when Webmin does.

I'm confused :-)


-joho



On 2020-12-08 23:12, Joaquim Homrighausen wrote:
>
> Hi there
>
> As stated in the post(s), Webmin 1.962 on Ubuntu 20.04.LTS.
>
> We do indeed use fail2ban on the servers being "pinged", but the ping 
> interval is set rather high.
>
> The checking server all of a sudden starts reporting monitors as being 
> down, but they are actually not. If I ssh into that checking server, 
> and issue ping to the servers reported as being down by Webmin, I get 
> a response. Every time.
>
> If I reboot the checking server, which takes about 10-15 seconds, 
> everything goes back to normal.
>
> It sounds/looks to me like a "build-up" issue, but I've only ever seen 
> this on that particular server. It happened with Ubuntu 18.04.LTS, and 
> it's happening with Ubuntu 20.04.1.LTS.
>
> It happens frequently, but not every day.
>
> The checking server is not logging in to the remote servers, it's 
> simply sending ICMP/pings.
>
>
> -joho
>
>
> On 2020-12-08 23:04, Eric Tykwinski wrote:
>> Sorry new to the list, but what are you running?
>> VirtualMin, Webmin, Cloudmin?
>>
>> My first guess would be a fail2ban issue as that is a popular 
>> dictionary attack mitigation method, so a cluster of webmin servers 
>> with an incorrect password on one would cause this.

Re: [webmin-l] Strange issues with ICMP monitoring

[Jamie C. <jca...@we...>]

So if you switched to the "Use command" mode, Webmin will just run
a command like :

ping -c 1 -w 5 remote-host

and check it's exit status. You could try creating an "execute commmand"
monitor to do the same thing, and see if that works better?

On 23/Aug/2021 00:47 Joaquim Homrighausen <jo...@we...> wrote ..
> 
> So this is still happening with 1.979. I'm now bumping to 1.980, but not 
> expecting much to change.
> 
> I've switched from Webmin's internal "ping" to using "Use command 
> suitable for Linux or FreeBSD". No change.
> 
> I've moved the "ping monitors" to another host. No change.
> 
> Is there a way to enable some sort of debugging for "System and server 
> status" pings ... ?
> 
> I run a self-written Python script on the same server, that basically 
> does the same type of ping monitoring, and it *never* reports a "down" 
> when Webmin does.
> 
> I'm confused :-)
> 
> 
> -joho
> 
> 
> 
> On 2020-12-08 23:12, Joaquim Homrighausen wrote:
> >
> > Hi there
> >
> > As stated in the post(s), Webmin 1.962 on Ubuntu 20.04.LTS.
> >
> > We do indeed use fail2ban on the servers being "pinged", but the ping 
> > interval is set rather high.
> >
> > The checking server all of a sudden starts reporting monitors as being 
> > down, but they are actually not. If I ssh into that checking server, 
> > and issue ping to the servers reported as being down by Webmin, I get 
> > a response. Every time.
> >
> > If I reboot the checking server, which takes about 10-15 seconds, 
> > everything goes back to normal.
> >
> > It sounds/looks to me like a "build-up" issue, but I've only ever seen 
> > this on that particular server. It happened with Ubuntu 18.04.LTS, and 
> > it's happening with Ubuntu 20.04.1.LTS.
> >
> > It happens frequently, but not every day.
> >
> > The checking server is not logging in to the remote servers, it's 
> > simply sending ICMP/pings.
> >
> >
> > -joho
> >
> >
> > On 2020-12-08 23:04, Eric Tykwinski wrote:
> >> Sorry new to the list, but what are you running?
> >> VirtualMin, Webmin, Cloudmin?
> >>
> >> My first guess would be a fail2ban issue as that is a popular 
> >> dictionary attack mitigation method, so a cluster of webmin servers 
> >> with an incorrect password on one would cause this.
> 
> 
> 
> -
> Forwarded by the Webmin mailing list at web...@li...
> To remove yourself from this list, go to
> http://lists.sourceforge.net/lists/listinfo/webadmin-list