| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This change introduces "wildcard" SNMP engine ID (0x00000000). Right
before deciding on firing up SNMP engine ID discovery and key
localization procedure, originating SNMP engine will check for
the presence of this magical engine ID (5 zeros), if it is present
in LCD along with the user name being used, localized keys from that
entry will be used.
Does this have security implications?
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This SNMP engine ID discovery procedure is spread across message
processing and security modules. This is weird!
Anyway, this change moves SNMP message rewriting, associated with
starting out SNMP discovery sequence, to security module. The
motivation is to let security module making the ultimate decision
whether or not SNMP engine discovery is required.
For example, if localized keys are committed directly to the DB,
security module may just use them without engine discovery phase.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Added new optional parameters to `addUsmUser()` and
`hlapi.UsmUserData()` functions allowing specifying key material
type being passed to the respective routines.
Plain-text pass-phrase remains the default, while user can change that
to `master` or `localized` types.
Refer to RFC3414 for technical details on SNMP USM key localization
algorithm.
|
| |
|
|
|
|
|
|
|
| |
Previously, MIB resolution errors were ignored (whenever possible)
for objects we were sending and receiving. This change tightens
outgoing objects MIB compliance (send will fail), but tolerate
non quite compliant objects we receive.
Also, extend the same policy onto `NotificationOriginator`.
|
| |
|
|
| |
This patch massively reformats the whole codebase mainly wrapping
long lines and eliminating dundered private attributes.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Also, consistency ensuring code unified with v3arch piece what
has the side effect of *requiring* snmpTrapOID to be always
present anywhere among user-supplied variable-bindings.
|
| | |
|
| |
|
|
|
| |
The hlapi.v1arch asyncio API is intended to be very similar to
hlapi.v3arch.asyncio from its signature viewpoint, however it
should be faster at the expense of no SNMPv3 support.
|
| | |
|
| | |
|
| |
|
|
| |
To make them PEP8-compliant
|
| | |
|
| | |
|
| |
|
|
| |
Perhaps previous commits have already broken older Python
support. This commit mostly declares Python 2.6+ support.
|
| |
|
|
|
| |
This is a follow up to 588b9b902d191d8010cb6b247fcb07887d59542c
fixing a couple of improperly named constants.
|
| |
|
|
|
|
|
|
|
| |
This is a massive patch essentially upper-casing global/class attributes
that mean to be constants.
Some previously exposed constants have been preserved for compatibility
reasons (notably, in `hlapi`), though the rest might break user code relying
on pysnmp 4.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The primary motivation behind this redesign is to allow asynchronous
operations between SNMP responder and the data source feeding its
MIB.
This is achieved by redesigning all `read*`, `write*`, `create*` and
`destroy*` methods of the `SNMPv2-SMI` MIB objects to return
immediately and deliver their results via a call back.
This modification brings significant and backward incompatible
changes to the low-level MIB operations.
The pysnmp MIB modules compiled for older pysnmp remain compatible.
|
| |
|
|
|
| |
The hlapi/v1arch GETNEXT command crashes when hitting end-of-mib
condition. This patch fixes this.
|
| |
|
|
| |
The retrying mechanism never worked, apparently.
|
| |
|
|
|
|
|
|
|
| |
Fixed hlapi LCD configurator to include `contextName`.
Prior to this fix sending SNMPv3 TRAP with non-default
`contextName` would fail.
This change modifies the signature of the internal
LCD methods.
|
| | |
|
| |
|
|
|
| |
Fix hlapi/v3arch transport target caching to ensure transport targets
are different even if just timeout/retries options differ.
|
| |
|
|
| |
target being re-configured (#194)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add `hlapi.v1arch` API
Introduce new sub-package `pysnmp.hlapi.v1arch` which
wraps otherwise very detailed packet-level SNMP
messaging into a handful of convenience functions.
As a side effect, the `pysnmp.hlapi.*` sub-packages
moved under `pysnmp.hlapi.v3arch` though `pysnmp.hlapi`
still exposes `pysnmp.hlappi.v3arch.*` symbols to
retain some degree of backward compatibility.
The signature of the hlapi `.sendNotification()` call
has changed to accept `*varBinds` instead of a sequence
of `varBinds`. The rationale is to unify this method
call with similar methods of CommandGenerator.
* Add v1arch docs and reshuffle hlapi docs
|
| |
|
|
|
|
| |
Fixed out-of-scope OIDs possibly leaking at the end of
SNMP table at hlapi `nextCmd` and `bulkCmd` calls when
`lexicographicMode = False`.
|
| |
|
|
| |
This reverts commit 23d1aa7bf5139d05c29ef27f6a5f68948c93a9df.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This is a prerequisite for pyasn1 0.4.x
|
| |
|
|
|
|
|
| |
* Clarify varBindTable returned by bulkCmd() in docs
* Fix bulkCmd() examples
* Abbreviate endOfMibView
* Fix fixed-width markup of Get{BulkRequest,Response}-PDU
|
| | |
|
| |
|
|
|
|
|
| |
Previously an exceptions raised by vbProcessor.unmakeVarBinds() fell
through, and asyncio base event loop caught and reported it on stderr,
while the original cmdgen's future went unfinished, causing the call to
hang forever. Match the synchronous version's behavior, which is to
raise the exception for the caller of the cmdgen to catch.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
