SNMP(v1) writes fail due to MIB lookup about conpot HOT 9 CLOSED

Get some sleep...

from conpot.

Ain't nobody got time for that :) ..

well ... 30 minutes of investigation - then I'll resign for today :)

from conpot.

snmpset work when using version 3, yes? (the unit test for SET with v3 passes)

from conpot.

Finally I figured it out -
you were right - it "worked" with v3 - but not at first try.

In fact, v3 returns correct reasons, in my case:

Reason: notWritable (That object does not support modification)

or

Reason: noAccess

while v1 responds with my previously mentioned message that indicates
a problem with finding the asset within the MIB.

After iterating through a bunch of objects I found one that accepted modification
with v3 - and therefore also succeeded modifying the same object via v1.

So actually theres no problem with writing but with dealing with problems when
writing over snmp v1 :)

from conpot.

@johnnykv I assume this just another pysnmp weirdness?

from conpot.

not sure

from conpot.

I'd assume that too since I could not find any of these error messages in conpot, .. so handling is obviously done in pysnmp.

from conpot.

My primary goal reporting this issue was to ensure that the snmp implementation in conpot actually behaves the same way other implementations do in order to avoid being discovered as honeypot too easily.

Right now I checked against two other snmp-enabled devices using snmp V1 and both behave the same way, returning reasons that are far away from being helpful. According to that, the behaviour of pysnmp in that special case seems to be perfectly natural ... facepalm ..

I'm sorry that I bothered you guys with this .. sigh

from conpot.

No worries, we all learned something.

from conpot.