delimitry
octet_string values being returned as hex values
I'm looking to make use of this script to simulate responses back from a type of device that I don't have in a lab, but do have the snmpwalk output from.
For example, this is a fragment of the snmpwalk output I'm working from:
$ snmpwalk -On -v2c -c public 192.168.27.254 1.3.6.1.2.1.4 | grep 192.168.27.74
.1.3.6.1.2.1.4.22.1.1.3.192.168.27.74 = INTEGER: 3
.1.3.6.1.2.1.4.22.1.2.3.192.168.27.74 = STRING: d0:11:e5:9e:25:8d
.1.3.6.1.2.1.4.22.1.3.3.192.168.27.74 = IpAddress: 192.168.27.74
.1.3.6.1.2.1.4.22.1.4.3.192.168.27.74 = INTEGER: dynamic(3)
.1.3.6.1.2.1.4.35.1.4.3.1.4.192.168.27.74 = STRING: d0:11:e5:9e:25:8d
.1.3.6.1.2.1.4.35.1.5.3.1.4.192.168.27.74 = Timeticks: (680662103) 78 days, 18:43:41.03
.1.3.6.1.2.1.4.35.1.6.3.1.4.192.168.27.74 = INTEGER: dynamic(3)
.1.3.6.1.2.1.4.35.1.7.3.1.4.192.168.27.74 = INTEGER: reachable(1)
.1.3.6.1.2.1.4.35.1.8.3.1.4.192.168.27.74 = INTEGER: active(1)
I've put this into a config file as follows:
DATA = {
'.1.3.6.1.2.1.4.22.1.1.3.192.168.27.74': integer(3),
'.1.3.6.1.2.1.4.22.1.2.3.192.168.27.74': octet_string('d011e59e258d'),
'.1.3.6.1.2.1.4.22.1.3.3.192.168.27.74': ip_address('192.168.27.74'),
'.1.3.6.1.2.1.4.22.1.4.3.192.168.27.74': integer(3),
'.1.3.6.1.2.1.4.35.1.4.3.1.4.192.168.27.74': octet_string('test'),
'.1.3.6.1.2.1.4.35.1.5.3.1.4.192.168.27.74': timeticks(680233835),
'.1.3.6.1.2.1.4.35.1.6.3.1.4.192.168.27.74': integer(3),
'.1.3.6.1.2.1.4.35.1.7.3.1.4.192.168.27.74': integer(3),
'.1.3.6.1.2.1.4.35.1.8.3.1.4.192.168.27.74': integer(1)
}
Yet when I use snmpwalk against snmp-server.py, I'm not getting back "STRING: d0:11:e5:9e:25:8d" as I would expect; instead I'm getting back a hex encoded version of it -- STRING: 64:30:31:31:65:35:39:65:32:35:38:64
# snmpwalk -v 2c -c public 192.168.27.74:1161 .
IP-MIB::ipNetToMediaIfIndex.3.192.168.27.74 = INTEGER: 3
IP-MIB::ipNetToMediaPhysAddress.3.192.168.27.74 = STRING: 64:30:31:31:65:35:39:65:32:35:38:64
IP-MIB::ipNetToMediaNetAddress.3.192.168.27.74 = IpAddress: 192.168.27.74
IP-MIB::ipNetToMediaType.3.192.168.27.74 = INTEGER: dynamic(3)
IP-MIB::ipNetToPhysicalPhysAddress.3.ipv4."192.168.27.74" = STRING: 74:65:73:74
IP-MIB::ipNetToPhysicalLastUpdated.3.ipv4."192.168.27.74" = Timeticks: (680233835) 78 days, 17:32:18.35
IP-MIB::ipNetToPhysicalType.3.ipv4."192.168.27.74" = INTEGER: dynamic(3)
IP-MIB::ipNetToPhysicalState.3.ipv4."192.168.27.74" = INTEGER: delay(3)
IP-MIB::ipNetToPhysicalRowStatus.3.ipv4."192.168.27.74" = INTEGER: active(1)
IP-MIB::ipNetToPhysicalRowStatus.3.ipv4."192.168.28.1".0 = No more variables left in this MIB View (It is past the end of the MIB tree)
I'm wondering what I'm missing here in order to get back STRING: d0:11:e5:9e:25:8d as required?
Hi @tseatah try to use: octet_string('\xd0\x11\xe5\x9e\x25\x8d') or octet_string(bytes.fromhex('d011e59e258d').decode('latin'))
Hi, @delimitry - thanks for the quick reply!
Using octet_string(bytes.fromhex('d011e59e258d')) doesn't seem to work, as I just get an error when trying to start the server:
$ python3 snmp-server.py -p 1161 -c config.py
[ERROR] Config parsing error: 'bytes' object has no attribute 'encode'
That would have been nicer to use, admittedly.
octet_string('\xd0\x11\xe5\x9e\x25\x8d') does seem to work, though isn't as pretty to look at, and requires a bit more effort to put a \x before each pair of characters.