SNMP address values are reversed on little-endian


SNMP PDU bindings generally consist of an object identifier (OID) and a value. In some cases, the value can be an IPv4 address. On a little-endian machine, this address is incorrectly parsed in reverse because the 4 bytes are loaded in network order and not host order. The network_address_to_val() function in src/analyzer/protocol/snmp/snmp-analyzer.pac returns the following.
new AddrVal(network_order);}}

Instead, it should probably return the following to convert the network order to host order, particularly for little-endian machines.
new AddrVal(ntohl(network_order));}}

The network_address_to_val() function is called in two places, by asn1_obj_to_val() when the object tag is APP_IPADDRESS_TAG, and also by build_trap_pdu(). The above change was tested to correct the problem in the first, but the latter case was not tested.

These values are not logged anywhere by default, but can be accessed by utilizing event snmp_response() and using the value$address within a single pdu$bindings object. Here is some sample code to inspect the problem.
@load base/protocols/snmp/main
module SNMP;
event snmp_response(c: connection, is_orig: bool, header: SNMP::Header, pdu: SNMP:DU) {
for (i in pdu$bindings) {
local binding = bindings[i];
if (binding$value?$address) {
print binding$value$address;

Sample traffic can be generated by executing the following command against an SNMP supported system. Some OIDs returned from most systems should contain IP addresses, assuming the version and community are correct.
snmpwalk -v 2c -c public}}

After re-compiling with the ntohl() call included, the problem is resolved correctly, for at least the asn1_obj_to_val() case described above.


Linux 3.2.0-4-amd64 Intel x86_64


Robin Sommer


Anony Mous


External issue ID



Fix versions

Affects versions