On Tue, 10 Jan 2023 17:23:08 +0100 Biselx Nicolas nicolas.biselx@epfl.ch wrote:
I'm not sure but I think that's what you asked me... See in attachement
Yes, the attachment is perfect, showing an snmpwalk of the `ipAddressTable` :)
D:>snmpwalk.exe -v 2c -c XXXXX forti-noc.epfl.ch 1.3.6.1.2.1.4.34 iso.3.6.1.2.1.4.34.1.3.1.10.0.2.49.143 = INTEGER: 143
All the responses seem to show the same problem, but we only need this one response for me to claim that the Fortigate device has an incorrect implementation of the IP-MIB.
This is the definition of an entry in the ipAddressTable:
IP-MIB::ipAddressEntry ipAddressEntry OBJECT-TYPE -- FROM IP-MIB MAX-ACCESS not-accessible STATUS current INDEX { ipAddressAddrType, ipAddressAddr } DESCRIPTION "An address mapping for a particular interface." ::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) ip(4) ipAddressTable(34) 1 }
`iso.3.6.1.2.1.4.34.1.3` from above is a result from the `ipAddressIfIndex` column (column no. 3). The row index is given as `.1.10.0.2.49.143`. The `.1` indicates an address type of IPv4, which according to spec should occupy 4 octets. However, the remaining row index contains 5 octets - An invalid IPv4 address: `10.0.2.49.143`.
This is the type definition:
InetAddressIPv4 ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d" STATUS current DESCRIPTION "Represents an IPv4 network address:
Octets Contents Encoding 1-4 IPv4 address network-byte order The corresponding InetAddressType value is ipv4(1). This textual convention SHOULD NOT be used directly in object definitions, as it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair." SYNTAX OCTET STRING (SIZE (4))
This response perfectly explains the warning/error given by ipdevpoll:
device has strange SNMP implementation of IP-MIB; ignoring retrieved IP address data: IPv4 address length is not 4: OID('.1.10.0.2.49.143')
It seems to me like the Fortigate device appends an actual `ifIndex` value (143, in this case) to all the IP addresses, and is therefore in violation of the MIB definition.
We could potentially work around this in NAV by ignoring the extra data and just interpret the first four octets, but this might cause problems with other devices that have faulty IP-MIB implementations, or it could cause potential problems if the same IP address appears multiple times with different ifIndex values attached to it.
I would at the very least report this as a bug to Fortigate.