[SNMP4J] SNMP4J Digest, Vol 93, Issue 1
Frank Fock
fock at agentpp.com
Wed Oct 15 19:30:31 CEST 2014
Hello Matyas,
I am afraid, that you need to choose another caching key.
Requests can get lost (it's UDP) and then request IDs can
increase randomly. In addition, senders are not required
to increase the ID at all. Some managers reuse the same
request ID when a previous request has been successfully
received (which is legal and works perfectly with a
standard conform agent, although logfiles are hard to read
then ;-))
Best regards,
Frank
Am 15.10.2014 10:20, schrieb Mátyás Kuti:
> Hello,
>
> Thanks for your answer Frank!
> The goal of the whole thing was to create an SNMP agent that accepts
> GETNEXT requests from multiple clients. We built a response cache on the
> first request for each client and based on the request ID of an incoming
> request the proper response was sent. The response itself was determined by
> the request ID. We expected that each ID would be in the range of (First
> ID, First ID+Number of fields to send) but since the IDs are not always
> incremented by 1 this solution would mess things up a bit... It works
> perfectly when tested by hand using the snmpwalk command on Linux but when
> we wrote the automatic tests in Java using SNMP4J the tests failed. Do you
> have any idea how to solve the problem of concurrent GETNEXT requests?
>
> Thanks,
> Matyas
>
> 2014-10-14 12:00 GMT+02:00 <snmp4j-request at agentpp.org>:
>
>> Send SNMP4J mailing list submissions to
>> snmp4j at agentpp.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://oosnmp.net/mailman/listinfo/snmp4j
>> or, via email, send a message with subject or body 'help' to
>> snmp4j-request at agentpp.org
>>
>> You can reach the person managing the list at
>> snmp4j-owner at agentpp.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of SNMP4J digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Question regarding request id when doing getnext (Mátyás Kuti)
>> 2. Re: Question regarding request id when doing getnext (Frank Fock)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 13 Oct 2014 13:23:01 +0200
>> From: Mátyás Kuti <matyas.kuti at gmail.com>
>> To: snmp4j at agentpp.org
>> Subject: [SNMP4J] Question regarding request id when doing getnext
>> Message-ID:
>> <
>> CAP-CjJb0g4Ssy+TEyvgCYUkCNZgjF8cSMQk+f0ALuYPU1mT+LA at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> Hello,
>>
>> We are doing the following:
>>
>> List<VariableBinding> snmpTable = new ArrayList<VariableBinding>();
>> for (TreeEvent event : events) {
>> if (event != null) {
>> if (event.isError()) {
>> logger.info
>> <
>> https://mail.internal.ericsson.com/owa/redir.aspx?C=2ipCqKJBBEyRoKqLqlcn5EPTOE5putEI6g7WPUCTE6ZOVwcy2_JaQ_aA843rf0UcX-2b_mw8x5E.&URL=http%3a%2f%2flogger.info
>>> ("oid
>> [" + oid + "] " + event.getErrorMessage());
>> }
>> VariableBinding[] varBindings =
>> event.getVariableBindings();
>> if (varBindings == null || varBindings.length == 0) {
>> continue;
>> }
>> for (VariableBinding varBinding : varBindings) {
>> snmpTable.add(varBinding);
>> }
>> }
>> }
>> ...
>>
>> And we have enforced the GETNEXT behavior by setting:
>> mTarget.setVersion(SnmpConstants.version1);
>>
>> We experience, that the request IDs increase by 2 instead of the expected
>> 1:
>>
>> Java-log output:
>>
>> 2014-09-30 15:05:05,888 [DEBUG] Received message from /192.168.210.1/30165
>> <
>> https://mail.internal.ericsson.com/owa/redir.aspx?C=2ipCqKJBBEyRoKqLqlcn5EPTOE5putEI6g7WPUCTE6ZOVwcy2_JaQ_aA843rf0UcX-2b_mw8x5E.&URL=http%3a%2f%2f192.168.210.1%2f30165
>> with length 58:
>>
>> 30:38:02:01:00:04:05:74:72:61:70:73:a2:2c:02:04:1b:b0:d2:2d:02:01:00:02:01:00:30:1e:30:1c:06:10:2b:06:01:04:01:81:41:81:37:04:01:03:05:01:08:30:04:08:07:de:09:1e:0d:02:27:1e
>> 2014-09-30 15:05:05,888 [DEBUG] Looking up pending request with handle
>> PduHandle[464572973]
>> 2014-09-30 15:05:05,888 [DEBUG] Cancelling pending request with handle
>> PduHandle[464572973]
>> 2014-09-30 15:05:05,888 [DEBUG] Running pending async request with handle
>> PduHandle[464572975] and retry count left 1
>> 2014-09-30 15:05:05,888 [DEBUG] Sending message to 192.168.210.1/30165
>> <
>> https://mail.internal.ericsson.com/owa/redir.aspx?C=2ipCqKJBBEyRoKqLqlcn5EPTOE5putEI6g7WPUCTE6ZOVwcy2_JaQ_aA843rf0UcX-2b_mw8x5E.&URL=http%3a%2f%2f192.168.210.1%2f30165
>> with length 50:
>>
>> 30:30:02:01:00:04:05:74:72:61:70:73:a1:24:02:04:1b:b0:d2:2f:02:01:00:02:01:00:30:16:30:14:06:10:2b:06:01:04:01:81:41:81:37:04:01:03:05:01:08:30:05:00
>> 2014-09-30 15:05:05,941 [DEBUG] Received message from /192.168.210.1/30165
>> <
>> https://mail.internal.ericsson.com/owa/redir.aspx?C=2ipCqKJBBEyRoKqLqlcn5EPTOE5putEI6g7WPUCTE6ZOVwcy2_JaQ_aA843rf0UcX-2b_mw8x5E.&URL=http%3a%2f%2f192.168.210.1%2f30165
>> with length 58:
>>
>> 30:38:02:01:00:04:05:74:72:61:70:73:a2:2c:02:04:1b:b0:d2:2f:02:01:00:02:01:00:30:1e:30:1c:06:10:2b:06:01:04:01:81:41:81:37:04:01:03:05:01:08:31:04:08:07:de:09:1e:0d:02:27:50
>> 2014-09-30 15:05:05,941 [DEBUG] Looking up pending request with handle
>> PduHandle[464572975]
>> 2014-09-30 15:05:05,941 [DEBUG] Cancelling pending request with handle
>> PduHandle[464572975]
>> 2014-09-30 15:05:05,941 [DEBUG] Running pending async request with handle
>> PduHandle[464572977] and retry count left 1
>> 2014-09-30 15:05:05,941 [DEBUG] Sending message to 192.168.210.1/30165
>> <
>> https://mail.internal.ericsson.com/owa/redir.aspx?C=2ipCqKJBBEyRoKqLqlcn5EPTOE5putEI6g7WPUCTE6ZOVwcy2_JaQ_aA843rf0UcX-2b_mw8x5E.&URL=http%3a%2f%2f192.168.210.1%2f30165
>> with length 50:
>>
>> 30:30:02:01:00:04:05:74:72:61:70:73:a1:24:02:04:1b:b0:d2:31:02:01:00:02:01:00:30:16:30:14:06:10:2b:06:01:04:01:81:41:81:37:04:01:03:05:01:08:31:05:00
>> 2014-09-30 15:05:05,978 [DEBUG] Received message from /192.168.210.1/30165
>> <
>> https://mail.internal.ericsson.com/owa/redir.aspx?C=2ipCqKJBBEyRoKqLqlcn5EPTOE5putEI6g7WPUCTE6ZOVwcy2_JaQ_aA843rf0UcX-2b_mw8x5E.&URL=http%3a%2f%2f192.168.210.1%2f30165
>> with length 58:
>>
>> 30:38:02:01:00:04:05:74:72:61:70:73:a2:2c:02:04:1b:b0:d2:31:02:01:00:02:01:00:30:1e:30:1c:06:10:2b:06:01:04:01:81:41:81:37:04:01:03:05:01:08:32:04:08:07:de:09:1e:0d:02:28:1a
>> 2014-09-30 15:05:05,978 [DEBUG] Looking up pending request with handle
>> PduHandle[464572977]
>> 2014-09-30 15:05:05,978 [DEBUG] Cancelling pending request with handle
>> PduHandle[464572977]
>> 2014-09-30 15:05:05,978 [DEBUG] Running pending async request with handle
>> PduHandle[464572979] and retry count left 1
>> 2014-09-30 15:05:05,978 [DEBUG] Sending message to 192.168.210.1/30165
>> <
>> https://mail.internal.ericsson.com/owa/redir.aspx?C=2ipCqKJBBEyRoKqLqlcn5EPTOE5putEI6g7WPUCTE6ZOVwcy2_JaQ_aA843rf0UcX-2b_mw8x5E.&URL=http%3a%2f%2f192.168.210.1%2f30165
>> with length 50:
>>
>> 30:30:02:01:00:04:05:74:72:61:70:73:a1:24:02:04:1b:b0:d2:33:02:01:00:02:01:00:30:16:30:14:06:10:2b:06:01:04:01:81:41:81:37:04:01:03:05:01:08:32:05:00
>> 2014-09-30 15:05:06,026 [DEBUG] Received message from /192.168.210.1/30165
>> <
>> https://mail.internal.ericsson.com/owa/redir.aspx?C=2ipCqKJBBEyRoKqLqlcn5EPTOE5putEI6g7WPUCTE6ZOVwcy2_JaQ_aA843rf0UcX-2b_mw8x5E.&URL=http%3a%2f%2f192.168.210.1%2f30165
>> with length 58:
>>
>> 30:38:02:01:00:04:05:74:72:61:70:73:a2:2c:02:04:1b:b0:d2:33:02:01:00:02:01:00:30:1e:30:1c:06:10:2b:06:01:04:01:81:41:81:37:04:01:03:05:01:08:33:04:08:07:de:09:1e:0d:02:28:3d
>> 2014-09-30 15:05:06,026 [DEBUG] Looking up pending request with handle
>> PduHandle[464572979]
>> 2014-09-30 15:05:06,026 [DEBUG] Cancelling pending request with handle
>> PduHandle[464572979]
>> 2014-09-30 15:05:06,027 [DEBUG] Running pending async request with handle
>> PduHandle[464572981] and retry count left 1
>> 2014-09-30 15:05:06,027 [DEBUG] Sending message to 192.168.210.1/30165
>> <
>> https://mail.internal.ericsson.com/owa/redir.aspx?C=2ipCqKJBBEyRoKqLqlcn5EPTOE5putEI6g7WPUCTE6ZOVwcy2_JaQ_aA843rf0UcX-2b_mw8x5E.&URL=http%3a%2f%2f192.168.210.1%2f30165
>> with length 50:
>>
>> 30:30:02:01:00:04:05:74:72:61:70:73:a1:24:02:04:1b:b0:d2:35:02:01:00:02:01:00:30:16:30:14:06:10:2b:06:01:04:01:81:41:81:37:04:01:03:05:01:08:33:05:00
>> 2014-09-30 15:05:06,077 [DEBUG] Received message from /192.168.210.1/30165
>> <
>> https://mail.internal.ericsson.com/owa/redir.aspx?C=2ipCqKJBBEyRoKqLqlcn5EPTOE5putEI6g7WPUCTE6ZOVwcy2_JaQ_aA843rf0UcX-2b_mw8x5E.&URL=http%3a%2f%2f192.168.210.1%2f30165
>> with length 50:
>>
>> 30:30:02:01:00:04:05:74:72:61:70:73:a2:24:02:04:1b:b0:d2:35:02:01:05:02:01:00:30:16:30:14:06:10:2b:06:01:04:01:81:41:81:37:04:01:03:05:01:08:33:05:00
>> 2014-09-30 15:05:06,077 [DEBUG] Looking up pending request with handle
>> PduHandle[464572981]
>> 2014-09-30 15:05:06,077 [DEBUG] Cancelling pending request with handle
>> PduHandle[464572981]
>>
>> We expect on the agent side that the request IDs increase by 1 just as with
>> netsnmp's snmpwalk. This behaviour (the request ID increasing by 2) was
>> verified with a TCP dump also.
>> What could cause this behaviour? Any idea how to fix it?
>>
>> Thanks a lot,
>> Matyas
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Mon, 13 Oct 2014 23:04:00 +0200
>> From: Frank Fock <fock at agentpp.com>
>> To: snmp4j at agentpp.org
>> Subject: Re: [SNMP4J] Question regarding request id when doing getnext
>> Message-ID: <543C3E40.6090705 at agentpp.com>
>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>
>> Hi,
>>
>> You cannot expect anything from a request ID other than it is unique
>> as long as the agent is running (and the range of available numbers
>> is not exhausted).
>>
>> SNMP4J (currently) also generates an ID for each response which has the
>> advantage, that even if the response cannot be fully parsed, it cannot
>> accidentially related to an existing request.
>>
>> I will check, if I can remove that ID generation safely. Meanwhile
>> you have two options:
>>
>> 1. Ignore that fact (according to the SNMP standard, it should not be
>> relevant
>> in practice).
>> 2. Generate your own request ID and set it in the PDU before providing it
>> to the Snmp class for sending.
>>
>> Hope this helps.
>>
>> Best regards,
>> Frank
>>
>>
>> Am 13.10.2014 13:23, schrieb Mátyás Kuti:
>>> Hello,
>>>
>>> We are doing the following:
>>>
>>> List<VariableBinding> snmpTable = new ArrayList<VariableBinding>();
>>> for (TreeEvent event : events) {
>>> if (event != null) {
>>> if (event.isError()) {
>>> logger.info
>>> <
>> https://mail.internal.ericsson.com/owa/redir.aspx?C=2ipCqKJBBEyRoKqLqlcn5EPTOE5putEI6g7WPUCTE6ZOVwcy2_JaQ_aA843rf0UcX-2b_mw8x5E.&URL=http%3a%2f%2flogger.info
>>> ("oid
>>> [" + oid + "] " + event.getErrorMessage());
>>> }
>>> VariableBinding[] varBindings =
>> event.getVariableBindings();
>>> if (varBindings == null || varBindings.length == 0) {
>>> continue;
>>> }
>>> for (VariableBinding varBinding : varBindings) {
>>> snmpTable.add(varBinding);
>>> }
>>> }
>>> }
>>> ...
>>>
>>> And we have enforced the GETNEXT behavior by setting:
>>> mTarget.setVersion(SnmpConstants.version1);
>>>
>>> We experience, that the request IDs increase by 2 instead of the
>> expected 1:
>>> Java-log output:
>>>
>>> 2014-09-30 15:05:05,888 [DEBUG] Received message from /
>> 192.168.210.1/30165
>>> <
>> https://mail.internal.ericsson.com/owa/redir.aspx?C=2ipCqKJBBEyRoKqLqlcn5EPTOE5putEI6g7WPUCTE6ZOVwcy2_JaQ_aA843rf0UcX-2b_mw8x5E.&URL=http%3a%2f%2f192.168.210.1%2f30165
>>> with length 58:
>>>
>> 30:38:02:01:00:04:05:74:72:61:70:73:a2:2c:02:04:1b:b0:d2:2d:02:01:00:02:01:00:30:1e:30:1c:06:10:2b:06:01:04:01:81:41:81:37:04:01:03:05:01:08:30:04:08:07:de:09:1e:0d:02:27:1e
>>> 2014-09-30 15:05:05,888 [DEBUG] Looking up pending request with handle
>>> PduHandle[464572973]
>>> 2014-09-30 15:05:05,888 [DEBUG] Cancelling pending request with handle
>>> PduHandle[464572973]
>>> 2014-09-30 15:05:05,888 [DEBUG] Running pending async request with handle
>>> PduHandle[464572975] and retry count left 1
>>> 2014-09-30 15:05:05,888 [DEBUG] Sending message to 192.168.210.1/30165
>>> <
>> https://mail.internal.ericsson.com/owa/redir.aspx?C=2ipCqKJBBEyRoKqLqlcn5EPTOE5putEI6g7WPUCTE6ZOVwcy2_JaQ_aA843rf0UcX-2b_mw8x5E.&URL=http%3a%2f%2f192.168.210.1%2f30165
>>> with length 50:
>>>
>> 30:30:02:01:00:04:05:74:72:61:70:73:a1:24:02:04:1b:b0:d2:2f:02:01:00:02:01:00:30:16:30:14:06:10:2b:06:01:04:01:81:41:81:37:04:01:03:05:01:08:30:05:00
>>> 2014-09-30 15:05:05,941 [DEBUG] Received message from /
>> 192.168.210.1/30165
>>> <
>> https://mail.internal.ericsson.com/owa/redir.aspx?C=2ipCqKJBBEyRoKqLqlcn5EPTOE5putEI6g7WPUCTE6ZOVwcy2_JaQ_aA843rf0UcX-2b_mw8x5E.&URL=http%3a%2f%2f192.168.210.1%2f30165
>>> with length 58:
>>>
>> 30:38:02:01:00:04:05:74:72:61:70:73:a2:2c:02:04:1b:b0:d2:2f:02:01:00:02:01:00:30:1e:30:1c:06:10:2b:06:01:04:01:81:41:81:37:04:01:03:05:01:08:31:04:08:07:de:09:1e:0d:02:27:50
>>> 2014-09-30 15:05:05,941 [DEBUG] Looking up pending request with handle
>>> PduHandle[464572975]
>>> 2014-09-30 15:05:05,941 [DEBUG] Cancelling pending request with handle
>>> PduHandle[464572975]
>>> 2014-09-30 15:05:05,941 [DEBUG] Running pending async request with handle
>>> PduHandle[464572977] and retry count left 1
>>> 2014-09-30 15:05:05,941 [DEBUG] Sending message to 192.168.210.1/30165
>>> <
>> https://mail.internal.ericsson.com/owa/redir.aspx?C=2ipCqKJBBEyRoKqLqlcn5EPTOE5putEI6g7WPUCTE6ZOVwcy2_JaQ_aA843rf0UcX-2b_mw8x5E.&URL=http%3a%2f%2f192.168.210.1%2f30165
>>> with length 50:
>>>
>> 30:30:02:01:00:04:05:74:72:61:70:73:a1:24:02:04:1b:b0:d2:31:02:01:00:02:01:00:30:16:30:14:06:10:2b:06:01:04:01:81:41:81:37:04:01:03:05:01:08:31:05:00
>>> 2014-09-30 15:05:05,978 [DEBUG] Received message from /
>> 192.168.210.1/30165
>>> <
>> https://mail.internal.ericsson.com/owa/redir.aspx?C=2ipCqKJBBEyRoKqLqlcn5EPTOE5putEI6g7WPUCTE6ZOVwcy2_JaQ_aA843rf0UcX-2b_mw8x5E.&URL=http%3a%2f%2f192.168.210.1%2f30165
>>> with length 58:
>>>
>> 30:38:02:01:00:04:05:74:72:61:70:73:a2:2c:02:04:1b:b0:d2:31:02:01:00:02:01:00:30:1e:30:1c:06:10:2b:06:01:04:01:81:41:81:37:04:01:03:05:01:08:32:04:08:07:de:09:1e:0d:02:28:1a
>>> 2014-09-30 15:05:05,978 [DEBUG] Looking up pending request with handle
>>> PduHandle[464572977]
>>> 2014-09-30 15:05:05,978 [DEBUG] Cancelling pending request with handle
>>> PduHandle[464572977]
>>> 2014-09-30 15:05:05,978 [DEBUG] Running pending async request with handle
>>> PduHandle[464572979] and retry count left 1
>>> 2014-09-30 15:05:05,978 [DEBUG] Sending message to 192.168.210.1/30165
>>> <
>> https://mail.internal.ericsson.com/owa/redir.aspx?C=2ipCqKJBBEyRoKqLqlcn5EPTOE5putEI6g7WPUCTE6ZOVwcy2_JaQ_aA843rf0UcX-2b_mw8x5E.&URL=http%3a%2f%2f192.168.210.1%2f30165
>>> with length 50:
>>>
>> 30:30:02:01:00:04:05:74:72:61:70:73:a1:24:02:04:1b:b0:d2:33:02:01:00:02:01:00:30:16:30:14:06:10:2b:06:01:04:01:81:41:81:37:04:01:03:05:01:08:32:05:00
>>> 2014-09-30 15:05:06,026 [DEBUG] Received message from /
>> 192.168.210.1/30165
>>> <
>> https://mail.internal.ericsson.com/owa/redir.aspx?C=2ipCqKJBBEyRoKqLqlcn5EPTOE5putEI6g7WPUCTE6ZOVwcy2_JaQ_aA843rf0UcX-2b_mw8x5E.&URL=http%3a%2f%2f192.168.210.1%2f30165
>>> with length 58:
>>>
>> 30:38:02:01:00:04:05:74:72:61:70:73:a2:2c:02:04:1b:b0:d2:33:02:01:00:02:01:00:30:1e:30:1c:06:10:2b:06:01:04:01:81:41:81:37:04:01:03:05:01:08:33:04:08:07:de:09:1e:0d:02:28:3d
>>> 2014-09-30 15:05:06,026 [DEBUG] Looking up pending request with handle
>>> PduHandle[464572979]
>>> 2014-09-30 15:05:06,026 [DEBUG] Cancelling pending request with handle
>>> PduHandle[464572979]
>>> 2014-09-30 15:05:06,027 [DEBUG] Running pending async request with handle
>>> PduHandle[464572981] and retry count left 1
>>> 2014-09-30 15:05:06,027 [DEBUG] Sending message to 192.168.210.1/30165
>>> <
>> https://mail.internal.ericsson.com/owa/redir.aspx?C=2ipCqKJBBEyRoKqLqlcn5EPTOE5putEI6g7WPUCTE6ZOVwcy2_JaQ_aA843rf0UcX-2b_mw8x5E.&URL=http%3a%2f%2f192.168.210.1%2f30165
>>> with length 50:
>>>
>> 30:30:02:01:00:04:05:74:72:61:70:73:a1:24:02:04:1b:b0:d2:35:02:01:00:02:01:00:30:16:30:14:06:10:2b:06:01:04:01:81:41:81:37:04:01:03:05:01:08:33:05:00
>>> 2014-09-30 15:05:06,077 [DEBUG] Received message from /
>> 192.168.210.1/30165
>>> <
>> https://mail.internal.ericsson.com/owa/redir.aspx?C=2ipCqKJBBEyRoKqLqlcn5EPTOE5putEI6g7WPUCTE6ZOVwcy2_JaQ_aA843rf0UcX-2b_mw8x5E.&URL=http%3a%2f%2f192.168.210.1%2f30165
>>> with length 50:
>>>
>> 30:30:02:01:00:04:05:74:72:61:70:73:a2:24:02:04:1b:b0:d2:35:02:01:05:02:01:00:30:16:30:14:06:10:2b:06:01:04:01:81:41:81:37:04:01:03:05:01:08:33:05:00
>>> 2014-09-30 15:05:06,077 [DEBUG] Looking up pending request with handle
>>> PduHandle[464572981]
>>> 2014-09-30 15:05:06,077 [DEBUG] Cancelling pending request with handle
>>> PduHandle[464572981]
>>>
>>> We expect on the agent side that the request IDs increase by 1 just as
>> with
>>> netsnmp's snmpwalk. This behaviour (the request ID increasing by 2) was
>>> verified with a TCP dump also.
>>> What could cause this behaviour? Any idea how to fix it?
>>>
>>> Thanks a lot,
>>> Matyas
>>> _______________________________________________
>>> SNMP4J mailing list
>>> SNMP4J at agentpp.org
>>> https://oosnmp.net/mailman/listinfo/snmp4j
>> --
>> ---
>> AGENT++
>> Maximilian-Kolbe-Str. 10
>> 73257 Koengen, Germany
>> https://agentpp.com
>> Phone: +49 7024 8688230
>> Fax: +49 7024 8688231
>>
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> SNMP4J mailing list
>> SNMP4J at agentpp.org
>> https://oosnmp.net/mailman/listinfo/snmp4j
>>
>>
>> ------------------------------
>>
>> End of SNMP4J Digest, Vol 93, Issue 1
>> *************************************
>>
> _______________________________________________
> SNMP4J mailing list
> SNMP4J at agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j
--
---
AGENT++
Maximilian-Kolbe-Str. 10
73257 Koengen, Germany
https://agentpp.com
Phone: +49 7024 8688230
Fax: +49 7024 8688231
More information about the SNMP4J
mailing list