Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SnmpTrap cant specify "Generic-Trap" Pysnmp version 4.4.3 #123

Open
srPuebla opened this issue Jan 4, 2018 · 4 comments
Open

SnmpTrap cant specify "Generic-Trap" Pysnmp version 4.4.3 #123

srPuebla opened this issue Jan 4, 2018 · 4 comments

Comments

@srPuebla
Copy link

srPuebla commented Jan 4, 2018

Hello Etingof,

Version pysnmp (4.4.3)

I have an issue with "snmptrap" and you cant specify "Generic-Trap" like the original command "snmptrap".

snmptrap -v1 -c public 192.168.1.1 1.3.6.1.4.1.41019.2.7.1.1 127.0.0.1 3 9 12345 1.3.6.1.4.1.41019.2.7.1.0.5 s "minor" 1.3.6.1.4.1.41019.2.7.1.0.3 s "Test Alarm Request"

//TCPDump
11:12:11.314445 IP carlosexamenrh7.50165 > 192.168.1.1.snmptrap: Trap(92) E:41019.2.7.1.1 127.0.0.1 coldStart 9 E:41019.2.7.1.0.5="minor" E:41019.2.7.1.0.3="Test Alarm Request"

In command line, you can specify "Generic-Trap" with 3 and specific trap with 9. However with library you cannot.

errorIndication, errorStatus, errorIndex, varBinds = next(
    sendNotification(
        SnmpEngine(),
        CommunityData('public', mpModel=0),
        UdpTransportTarget((192.168.1.1 , 162)),
        ContextData(),
        'trap',
        NotificationType(
            ObjectIdentity('1.3.6.1.4.1.41019.2.7.1.1.3.9'),
        ).addVarBinds(
            ('1.3.6.1.2.1.1.3.0', 12345),
            ('1.3.6.1.4.1.41019.2.7.1.0.5', OctetString("minor")),
            ('1.3.6.1.4.1.41019.2.7.1.0.3', OctetString("Test Alarm Request"))
        )
    )
)

When you use this it sends "Generic Trap" with 6

TCPDUMP
11:17:25.814025 IP carlosexamenrh7.44169 > 192.168.1.1.snmptrap: Trap(93) E:41019.2.7.1.1.3 0.0.0.0 enterpriseSpecific s=9 0 E:41019.2.7.1.0.5="minor" E:41019.2.7.1.0.3="Test Alarm Request"

As you can see, you cant send that "Generic Trap". It always is set with "6"

I put another example:

snmptrap -v1 -c public 192.168.1.1 1.3.6.1.4.1.41019.2.7.1.1 127.0.0.1 10 9 12345 1.3.6.1.4.1.41019.2.7.1.0.5 s "minor" 1.3.6.1.4.1.41019.2.7.1.0.3 s "Test Alarm Request"

Generic Trap => 10
Specific Trap => 9

TCPDUMP
11:21:56.493648 IP carlosexamenrh7.47658 > 192.168.1.1.snmptrap: Trap(93) E:41019.2.7.1.1 127.0.0.1 gt=10[specific-trap(9)!=0] 12345 E:41019.2.7.1.0.5="minor" E:41019.2.7.1.0.3="Test Alarm Request"

Pysnmp example:

errorIndication, errorStatus, errorIndex, varBinds = next(
    sendNotification(
        SnmpEngine(),
        CommunityData('public', mpModel=0),
        UdpTransportTarget(('192.168.1.1', 162)),
        ContextData(),
        'trap',
        NotificationType(
            ObjectIdentity('1.3.6.1.4.1.41019.2.7.1.1.10.9'),
        ).addVarBinds(
            ('1.3.6.1.2.1.1.3.0', 12345),
            ('1.3.6.1.4.1.41019.2.7.1.0.5', OctetString("minor")),
            ('1.3.6.1.4.1.41019.2.7.1.0.3', OctetString("Test Alarm Request"))
        )
    )
)

TCPDUMP
11:27:53.239067 IP carlosexamenrh7.44005 > 192.168.1.1.snmptrap: Trap(94) E:41019.2.7.1.1.10 0.0.0.0 enterpriseSpecific s=9 12345 E:41019.2.7.1.0.5="minor" E:41019.2.7.1.0.3="Test Alarm Request"

As you can see, it sends "enterpriseSpecific" like Generic-Trap instead of 10.

Can you help us?

Thank you so!

@etingof
Copy link
Owner

etingof commented Jan 28, 2018

This looks confusing to me. You are sending enterprise OID and generic trap (e.g. coldStart). Is it a valid combination?

Looking at this code, if you pass 1.3.6.1.6.3.1.1.5.1 to NotificationType, that should eventually translate into coldStart(0).

@srPuebla
Copy link
Author

Hi Etingof,

Thanks for replay and my apologies for the delay.

I already read that code,
However, with your library i cant do something like

snmptrap -v1 -c public 192.168.1.1 1.3.6.1.4.1.41019.2.7.1.1 127.0.0.1 **10 9** 12345 1.3.6.1.4.1.41019.2.7.1.0.5 s "minor" 1.3.6.1.4.1.41019.2.7.1.0.3 s "Test Alarm Request"

Watch the bold numbers. You cant specify (by rfc), the last number of the OID (9). It is translated inmediatly into "Generic-Trap". Try to throw the last command and, after, try to throw through your library.

I dont know if you are understanding me

Thank you so!

@etingof
Copy link
Owner

etingof commented Mar 17, 2018

So you want to send trap-type=10 with snmptrap command:

  ...
  -v 1 TRAP-PARAMETERS:
 enterprise-oid agent trap-type specific-type uptime [OID TYPE VALUE]...

However generic trap type 10 does not exist according to RFC1157:

generic-trap        -- generic trap type
                 INTEGER {
                     coldStart(0),
                     warmStart(1),
                     linkDown(2),
                     linkUp(3),
                     authenticationFailure(4),
                     egpNeighborLoss(5),
                     enterpriseSpecific(6)
                 },

That explains why pysnmp resets unknown trap types to enterpriseSpecitic type. So I do not see this as a bug in pysnmp. Do you?

Why do you need to generate SNMP TRAPs with supposedly non-compliant TRAP types?

For reference, this is how you send custom specific-type with pysnmp.

@srPuebla
Copy link
Author

Hello Etingof,

Thanks,

I am agree with you. This is not a bug, cause you are following RFC1157 rules. Maybe this could be a "feature" like command snmptrap does.

Why do we need this?
Cause we already had configured some OIDs in this way. We have some apps that use command "snmptrap" to send traps and now we are developing a Python app which it needs to throw the same trap.

So, dont worry, we should change our OID´s configuration following the RFC. I think so.

Thanks for your time!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants