Support for loading of MIBS about conpot HOT 11 CLOSED

Conpot now takes a '-m' option to specifiy the path to the compiled MIB files (defaults to current work directory)

build-pysnmp-mib IF-MIB.my > IF-MIB.py
build-pysnmp-mib ianaiftype-mib > IANAifType-MIB.py
conpot -t test.xml

Not really tested it that much, but seems like your value from IF-MIB gets loaded:
2013-05-24 09:44:43,816 Registered: MibScalar((1, 3, 6, 1, 2, 1, 1, 6), DisplayString())
2013-05-24 09:44:43,816 Registered: MibScalar((1, 3, 6, 1, 2, 1, 1, 7), Integer32())
2013-05-24 09:44:43,827 Registered: MibScalar((1, 3, 6, 1, 2, 1, 2, 1), Integer32()) <- this is from IF-MIB
2013-05-24 09:44:43,827 SNMP server started on: ('0.0.0.0', 161)

from conpot.

Closed with 768b77d.

from conpot.

I tested 768b77d and it works perfectly for compiled MIBs as long as their symbols are exactly those specified.

Some symbols are extended by suffixes like ".0", ".1", etc. - some even contain further information described by numbers. Example:

IP-MIB: Symbol "ipAdEntAddr" can also come with suffix "ipAdEntAddr.192.168.0.1".

In my opinion this could be solved by looking up the part before the first "." (if additional fields exist) and prepending the other parts after a successful lookup. Example:

ipAdEntAddr.192.168.0.1
lookup of ipAdEntAddr -> OID (1, 3, 6, 1, 2, 1, 4, 20, 1, 1)
rest prepended -> OID (1, 3, 6, 1, 2, 1, 4, 20, 1, 1, 192, 168, 0, 1)

I think the best way to deal with this would be in command_responder.py -> register()

from conpot.

Trying to fully understand the problem:
ipAdEntAddr.192.168.0.1 would be the same as the xml below?

<mib name="IP-MIB">
 <symbol name="ipAdEntAddr">
  <value>192.168.0.1</value>
 </symbol>
</mib>

Or is the problem that there can exist multiple instances of ipAdEntAddr? Something along the lines of

<mib name="IP-MIB">
 <symbol name="ipAdEntAddr">
 <instance>1</instance>
  <value>192.168.0.1</value>
 </symbol>
</mib>

from conpot.

Basically these are multiple instances, you are right. But they are not always used that way ( so we're not always increasing instances by 1 ).

As a reference, here are proper snips of anonymized real life snmpwalks taken from a programmable logical controller:

IF-MIB::ifNumber.0 = INTEGER: 2
IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifIndex.2 = INTEGER: 2
IF-MIB::ifDescr.1 = STRING: Internal, Rack 0, Slot 1
IF-MIB::ifDescr.2 = STRING: Ethernet Port 1, link, 100 Mbit, full duplex, autonegotiation
IF-MIB::ifType.1 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifType.2 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifPhysAddress.1 = STRING: 00:11:22:33:44:11
IF-MIB::ifPhysAddress.2 = STRING: 00:11:22:33:44:22

As you can see, in the sample above applies the "instances" paradigm,
while...:

TCP-MIB::tcpConnState.0.0.0.0.102 = INTEGER: established(5)
TCP-MIB::tcpConnState.0.0.0.0.443 = INTEGER: listen(2)
TCP-MIB::tcpConnState.0.0.0.0.80 = INTEGER: listen(2)

...here instead of instances, the OID is extended by the IP address the
connection is bound to - in this case to every IP address (0.0.0.0) - while
the value contains the connection state.

So I would not propose a change to the existing XML structure,
since it already supports these OID suffixes:

<mib name="IF-MIB">
    <symbol name="IfDesc.1">
        </value>Internal, Rack 0, Slot 1</value>
    </symbol>
</mib>

<mib name="TCP-MIB">
    <symbol name="tcpConnState.0.0.0.0.102">
        </value>5</value>
    </symbol>
</mib>

.. but instead change the way they are interpreted in case of existing
OID seperators (dots) as described before.

This way, both use cases could be supported and would let the snmp
trap look way more realistic :)

from conpot.

Ok, thanks for the detailed explanation. Makes sense. I have a few busy weeks ahead, so might take some time before i manage to implement this.
(note: we do accept pull requests! :-) )

from conpot.

I'm currently struggling with python - but I'm trying to get warm with it,
maybe this project is a good point to start learning python. From there on I'd happily submit and contribute whatever I can :)

Just don't expect well formed code in the beginning of my journey :P

( Note: funny thing to call it snmp trap while there are .. well .. snmp "traps" ... :P )

from conpot.

Johnny and I got quite some experience regarding code reviews ;) Just send a pull request, we will give feedback and go from there.

from conpot.

I almost finished the adaptions to support instances,
unfortunately you where right and I'll have to do a minor change to the XML structure.
Tomorrow I will commence some further testing before sending another pull req. :)

from conpot.

@creolis sounds awesome! Make sure to ping us if you need help. Also, i recommend using nosetest for running the testcases.

from conpot.

closed with 0982a86 and 0982a86.

from conpot.