(1) Documentation should be corrected.

Valid mask for IPv4 addresses should be /16 - /30

• https://www.zabbix.com/documentation/1.8/manual/auto-discovery/auto-discovery_rule
• https://www.zabbix.com/documentation/2.0/manual/discovery/network_discovery/rule
• https://www.zabbix.com/documentation/2.2/manual/discovery/network_discovery/rule
• https://www.zabbix.com/documentation/2.4/manual/discovery/network_discovery/rule

sasha ReSOLVED

<dimir> CLOSED

That was made

1. fixed validation of IPv4 masks on frontend side
2. rewritten functions ip_in_list() for support of IP masks
   • added support of IP masks for action conditions (versions 1.8.x, 2.0.x, 2.2.x and 2.3.x)
   • added support of IP masks for cleaning dhosts and dservices (version 2.3.x)
3. fixed processing of IPv6 masks in the network discovery

     mask: 12fc::0/120
   
     old algorithm:
       range: 12fc::1 - 12fc::fe
     new algorithm:
       range: 12fc:: - 12fc::ff
   

     mask: 12fc::0/112
   
     old algorithm:
       range: 12fc::1 - 12fc::fffe
     new algorithm:
       range: 12fc:: - 12fc::ffff
   

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

(2) [S] Suggestion to rename in trunk:

ip_in_list(char *list, const char *ip) ->
ip_in_range(char *range, const char *ip)

ip4_in_list(char *list, const char *ip) ->
ip4_in_range(char *range, const char *ip)

ip6_in_list(char *list, const char *ip) ->
ip6_in_range(char *range, const char *ip)

sasha The first argument is the list of ranges. I think we shouldn't rename the function or rename to ip*_in_ranges(char *ranges, const char *ip).

CLOSED

Next thing noted regarding the range of IPv6 addresses when CIDR format used in Network Discovery rule. E. g. when using range 12fc::28/126

before the fix, resulted in 2 IPs: 12fc::29-12fc::2a

after the fix (correct behavior), 4 IPs: 12fc::28-12fc::2b

(3) [S] The function ip6_str2dig() won't accept (seems to be) valid IPv6 address:

::0:0:0:0:0:0:1

and will accept (seems to be) invalid IPv6 address:

::

asaveljevs Just a quick note: netstat gives "::" as the listening IP address, which probably is analogous to "0.0.0.0" in IPv4 and means all addresses:

$ netstat -tnl | grep ::
tcp6       0      0 :::80                   :::*                    LISTEN     
tcp6       0      0 ::1:25                  :::*                    LISTEN     
tcp6       0      0 :::443                  :::*                    LISTEN

sasha

:: - this is valid address

RFC 6890

+----------------------+---------------------+
| Attribute            | Value               |
+----------------------+---------------------+
| Address Block        | ::/128              |
| Name                 | Unspecified Address |
| RFC                  | [RFC4291]           |
| Allocation Date      | February 2006       |
| Termination Date     | N/A                 |
| Source               | True                |
| Destination          | False               |
| Forwardable          | False               |
| Global               | False               |
| Reserved-by-Protocol | True                |
+----------------------+---------------------+
       Table 18: Unspecified Address

::0:0:0:0:0:0:1 - this address is invalid

RFC 5952

4.2.2. Handling One 16-Bit 0 Field

The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field.
For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
2001:db8::1:1:1:1:1 is not correct.

RESOLVED

<dimir> Thanks for clearing this out! CLOSED

Successfully tested. Please review my small changes in r48154.

Fixed in pre-1.8.21 r48155, pre-2.0.13 r48156, pre-2.2.6 r48157 and pre-2.3.4 (trunk) r48158.