SNMP4J 3.2.0 has been released to fix (D)TLS issues regarding notification sending. As a side effect, the new version makes it easier to control TransportMapping usages for hybrid command responder and command/notification sender applications.
Dependencies
- Java 9 or later
CHANGES
- Fixed [SFJ-202]: CertifiedTarget for SNMPv3 TLS notifications not handled in NotificationOriginatorImpl. This includes fixes to the TlsTmMib regarding (D)TLS target resolving as well as fixes to the SNMP4J MessageDispatcher and TransportMappings in order to be able to use a “client mode” transport mapping with a different source port than the “server” mode TLS transport mapping that acts as command responder.
- Added: TransportMapping.isAddressSupported(Address addressType, boolean exactMatch) to let a TransportMapping decide if a Address class is supported or not. This is necessary to exclude TcpAddress from a TLSTM if exact match is enabled, for example. (This method is used by MessageDispatcherImpl).
- Added: TransportMapping.getSupportedTransportType() to being able to distinguish between sending and receiving transport mappings. By default the TransportType.any is returned. For TransportMappings DefaultTcpTransportMapping, TLSTM, and DTLSTM, ‘any’ is only returned if “server” is enabled, otherwise ‘sender’ is returned.
- Added: Address.isTransportCompatible(Class<?> other) to allow to exclude superclasses from being compatible regarding TransportMapping usage with the implementing class. This is necessary, for example for TlsAddress and DtlsAddress to exclude them from usage on TransportMappings that primarily support ony Tcp or Udp.
- Changed: MessageDispatcherImpl now distinguishes between TransportMappings that can be used to send messages (command generator/notification generator) and those that can be used to receive messages (command responder application).
- Changed: MessageDispatcher.getTransport(A destAddress) is now deprecated and replaced by getTransport(A destAddress, TransportType transportType) in order to be able to select the correct TransportMapping for the requested SNMP application type (command responder -> ‘receiver’ or command generator -> ‘sender’). The deprecated method searches for ‘receiver’ first and will return a ‘sender’ if no receiver was found.
- Fixed: The counter events created for the SnmpTlsTmMib ‘snmpTsmUnknownPrefixes’ and ‘snmpTsmInvalidPrefixes’ have been changed to better match their specification.