-
Notifications
You must be signed in to change notification settings - Fork 5
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
Resolve incoming trap varbinds properly #290
Conversation
The varbinds of an incoming trap message were incorrectly resolved (most likely due to a misunderstanding of PySNMP complexity). In fact, the original resolver only resolved the name of the incoming variable, but the subtype of the value also needs to be resolved according to the MIB definition of the incoming variable. This new resolver ensures the value is also resolved to the correct type. An example: The incoming raw value may be an ASN1 OctetString, but seen in light of the resolved MIB object name, it might actually be resolved as a InetAddress textual convention type instead (which would heavily influence how the incoming value is parsed to a Python value).
🦙 MegaLinter status: ✅ SUCCESS
See detailed report in MegaLinter reports |
Test results 3 files 3 suites 59s ⏱️ Results for commit 42cbb27. ♻️ This comment has been updated with latest results. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #290 +/- ##
==========================================
+ Coverage 98.89% 98.90% +0.01%
==========================================
Files 51 52 +1
Lines 6912 6972 +60
==========================================
+ Hits 6835 6895 +60
Misses 77 77 ☔ View full report in Codecov by Sentry. |
We want to re-use this for other trap tests.
Add trap observer class for Juniper BGP traps
Quality Gate passedIssues Measures |
No comments received in an IRL code review within our team, so I'm merging this now. |
Scope and purpose
The varbinds of an incoming trap message were incorrectly resolved (most likely due to a misunderstanding of PySNMP complexity).
In fact, the original resolver only resolved the name of the incoming variable, but the subtype of the value also needs to be resolved according to the MIB definition of the incoming variable.
This new resolver ensures the value is also resolved to the correct type. An example: The incoming raw value may be an ASN1 OctetString, but seen in light of the resolved MIB object name, it might actually be resolved as a InetAddress textual convention type instead (which would heavily influence how the incoming value is parsed to a Python value).
This issue was discovered during implementation of #288 as incoming BGP operational state values were not translated to names, but stayed as opaque integers
This pull request
Contributor Checklist
Every pull request should have this checklist filled out, no matter how small it is.
More information about contributing to Zino can be found in the
README.