Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-7576

(1) There are differences between fping versions how broadcast addresses for which no answers are received are handled in the summary:

For instance, version 2.4b2_to does not output ping results for the broadcast address:

$ sudo fping -v
fping: Version 2.4b2_to $Date: 2002/01/16 00:33:42 $
fping: comments to [email protected]
$ echo 192.168.1.255 | sudo fping -C3

192.168.1.255 :

However, version 3.8 outputs results. Sometimes it outputs all dashes and sometimes it outputs what seems to be a random value as the first number:

$ sudo fping -v
fping: Version 3.8
fping: comments to [email protected]
$ echo 192.168.1.255 | sudo fping -C3

192.168.1.255 : - - -
$ echo 192.168.1.255 | sudo fping -C3

192.168.1.255 : 21140988.88 - -

Do we wish to do something about it? For instance, by parsing lines for each ping result, rather than the summary line? Or parsing the summary line, but checking that there were lines for each ping result, too?

wiper We have to parse summary line anyway to get the timeouts. So that leaves the second option.

wiper Actually we can parse the individual results and just use the summary line as 'EOF' marker.

wiper RESOLVED in r41456

asaveljevs It might be better to start parsing the response time one character later. That I changed in r41492, please take a look.

asaveljevs Another thing is that individual ping results have less precision (see sprint_tm() function in fping source). For instance:

...
192.168.1.1 : [21], 84 bytes, 1819 ms (260 avg, 69% loss)
192.168.1.1 : [22], 84 bytes, 818 ms (330 avg, 65% loss)
192.168.1.1 : [23], 84 bytes, 0.51 ms (293 avg, 62% loss)
...

This corresponds to the following numbers in the summary line:

192.168.1.1 : 0.57 1.05 0.49 0.98 0.26 0.92 - - - - - - - - - - - - - - - 1819.74 818.80 0.51 0.96 0.26 ...

Does not seem to be good from our side to compromise on precision... REOPENED.

wiper RESOLVED in r41500

asaveljevs CLOSED

We have reported the issue with fping described above at https://github.com/schweikert/fping/issues/56 .

Released in:
pre-2.2.2rc1 r41522
pre-2.3.0 r41523

The fping issue at https://github.com/schweikert/fping/issues/56 was fixed and is scheduled to be released in version 3.9.

Due to a request in ZBX-8250, we shall port the fix to Zabbix 2.0, too.

Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-7576 .

Successfully tested

Released in:
pre-2.0.13rc1 r46000

(2) changelog entry does not follow the guidelines (does not start with a verb)

asaveljevs Fixed in r50191. RESOLVED.

wiper CLOSED

Hi,

I'm experiencing this bug as well by using multiple /16 in my discovery. Host are discovered on their main address (10.1.1.1 for example) but also on the .0 and .255. Zabbix creates a single interface for the main address but adds multiple .255 interfaces, but it seems a bit random when Zabbix adds an interface.

My configuration

• Discovery rule:
  • IP range:
    • 10.1.0.0/16
    • 10.2.0.0/16
    • ...(total of 10 times a /16)
  • Checks:
    • SNMPv2 agent "1.3.6.1.2.1.47.1.1.1.1.11.1" (Serial)
    • SNMPv2 agent "1.3.6.1.2.1.47.1.1.1.1.13.1" (Device type)
  • Device uniqueness criteria: SNMPv2 agent "1.3.6.1.2.1.47.1.1.1.1.11.1"
• Discovery Action:
  • Discovery check = Routers: SNMPv2 agent "1.3.6.1.2.1.47.1.1.1.1.13.1"
  • Discovery rule = Routers
  • Received value like CISCO887VA-SEC-K9
  • Discovery status = Up
  • Service type = SNMPv2 agent

There are multiple ways to currently solve this, although all will result in a lot of rules:

• Only add 10.1.1.1-254 discovery rules
  • Results in 2550 discovery rules, which is unmanageable.
• Add a extra condition in the discovery action
  • Impossible as there is only one received value and I need to check if it is the correct device
  • Host.ip only allows for equals and not equals. With a not like you could add 'host.ip not like .255' although that filters out 10.255.1.1

I "fixed" it by adding 5100 rules to iptables with: iptables -A OUTPUT -d 10.1.1.255 -j DROP