[SNMP4J] Closing Message

2019-04-27 Thread Frank Fock
Hi All,

The new AGENTPP forum which will now immediately replace these mailing lists - 
which worked quite well for over 20 years.
Thank you for your participation and support!

I hope the new forum can seamlessly tie into this success story. In any case 
you are welcome to join it at
https://support.snmp.app

Invitation emails had been sent out already. I you missed it, you can simply 
visit the above link and register. 

This mailing list(s) will now be stopped (in a few minutes) and all login data 
will be then deleted - no further action is required from your side. 
The mailing list archives will remain available at:

* SNMP4J Mailing List Archive: https://agentpp.com/support/listarchives/snmp4j
* AGENT++ Mailing List Archive: https://agentpp.com/support/listarchives/agentpp
* MIB Designer Mailing List Archive: 
https://agentpp.com/support/listarchives/mibdesigner
* MIB Explorer Mailing List Archive: 
https://agentpp.com/support/listarchives/mibexplorer

Best regards,
Frank Fock


___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] OS

2019-04-23 Thread Frank Fock
Hi,

You should use SNMP4J 3.1.0 instead any 1.x version (which is out of support 
and probably not compatible with latest Java SE editions).

Best regards,
Frank


> On 23. Apr 2019, at 05:25, liname...@outlook.com wrote:
> 
> Hello, I am doing an investigation.
> Does Windows Server 2019 support the following products:
> 
> SNMP4J 1.11.5
> 
> Can it be installed on windows2019?
> Is the other version supported?
> Can you tell me, thank you very much.
> 
> 
> 
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


[SNMP4J] SNMP4J/AGENTPP mailing lists replacement

2019-04-22 Thread Frank Fock
Dear AGENTPP Mailing List Members,

After more than 20 years providing SNMP API and tool related support through 
these mailing lists “snmp4j”, “agentpp”, “mibexplorer”, and “mibdesigner", it 
is now time to switch to a new technology that hopefully better fits our needs 
for low entry barriers to informal support and knowledge exchange today. 

AGENTPP will therefore continue to provide discussion, questions and answers 
through the AGENTPP Forum from now on:
https://forum.snmp.app 

By end of April 2019, the mailing list service will be discontinued and shut 
down. The email addresses and other data (password hashes etc.) will be deleted 
immediately after final shutdown. Thus, you do not need to unsubscribe yourself 
- you will be unsubscribed automatically.  

The >20 years of mailing list archives will be saved and then made accessible 
from the AGENTPP web site at:
https://agentpp.com/support/listarchives/[listname]

Within 16 hours after this posting, you will receive invitations for the new 
AGENTPP forum by email. If you do not want to participate in the new AGENTPP 
forum, you can simply ignore that email. You will then not be registered and 
not member of the new forum.

Otherwise I would be glad if you join the new forum to exchange SNMP knowledge 
on standards, the AGENTPP APIs and tools!
Finally, I would like to thank you for your trust and loyalty partly ranging 
over decades now!

Best regards,
Frank Fock



 



___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Timeout issue with snmp4j-2.3.4.jar

2019-04-16 Thread Frank Fock
Hi Mark,

Increasing the timeout is only helpful, if the agent could be in a CPU overload 
situation or if there is a network congestion by large IP packets. 
In your case, the agent seems to simply “forget” to process the request, maybe 
by an overload or other task, maybe because the UDP receive buffer is flooded.

To be sure, that the agent is the problem you could sniff on the network with 
Wireshark for example.   

Your code seems to be creating a Snmp instance and USM for each requests, which 
is total overkill. Especially, the calling “listen()” is very “expensive” 
because it binds a network port. Doing this every second could easily block all 
ports on your system and might cause a high CPU load - because the SNMPv3 keys 
need to be calculated each time fresh.
Please reuse the Snmp and the associated USM for all subsequent requests.

Best regards,
Frank


> On 16. Apr 2019, at 18:55, Mark Ponthier  wrote:
> 
> I have a program that does an SNMP GET every second against a network device 
> using SNMPv3. It is random, but after around a thousand or so requests, it 
> times out, and then it starts working again. Regardless of the specified 
> timeout or the number of retries, it waits the entire time period and then 
> returns a null response PDU. If I have a timeout of 1000ms and retries of 1, 
> it will timeout after 2sec. If I have a timeout of 2ms and retries of 1, 
> it will timeout after 40sec. So the amount of the timeout is not the issue 
> here. When it decides to timeout it will do so regardless if I wait 2 seconds 
> or 40 seconds. The typical response time is usually 5-10ms. I'm wondering if 
> this is normal behavior, an issue in the library, or if I just have something 
> wrong in my code (see below). Less frequently this is also a problem with 
> SNMPv2. I really appreciate any help or ideas you may have!
> 
> 
> OctetString localEngineId = new OctetString(MPv3.createLocalEngineID());
> USM usm = new USM(SecurityProtocols.getInstance(), localEngineId, 0);
> SecurityModels.getInstance().addSecurityModel(usm);
> 
> String oid = "1.3.6.1.2.1.1.1.0";
> PDU result = new ScopedPDU();
> result.setType(PDU.GET);
> result.add(new VariableBinding(new OID(oid)));
> Snmp snmp = new Snmp(new DefaultUdpTransportMapping());
> usm.addUser(securityNameOctet, new UsmUser(securityNameOctet, authProtocol, 
> new OctetString(authPassPhrase), privProtocol, new 
> OctetString(privPassPhrase)));
> snmp.listen();
> 
> String addrStr = "10.0.22.33/161";
> Address targetAddress = GenericAddress.parse(addrStr);
> 
> UserTarget userTarget = new UserTarget();
> userTarget.setAddress(targetAddress);
> userTarget.setRetries(numRetries);
> userTarget.setTimeout(timeout);
> userTarget.setVersion(SnmpConstants.version3);
> userTarget.setSecurityName(new OctetString(securityName));
> userTarget.setSecurityLevel(SecurityLevel.AUTH_PRIV);
> 
> ResponseEvent responseEvent = snmp.send(pdu, target);
> PDU responsePDU = responseEvent.getResponse();
> 
> if (responsePDU == null) {
> LOGGER.error(;
> LOGGER.error("SNMP GET timed out: addrStr[" + addrStr + "], oid[" + oid + 
> "]");
> }
> 
> 
> 
> Mark Ponthier | Senior Vice President, Engineering
> 
> www.firescope.com | Office: 214.296.9243 x451 | 
> Mobile: 214.578.3676
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] USMTable and thread safety

2019-03-11 Thread Frank Fock

Hi Girish,

The UsmUserTable (USMUserTable does not exists either) addUser and 
removeAllUsers methods are both synchronised.
Thus, where exactly do you see a concurrency issue?

Best regards,
Frank


> On 11. Mar 2019, at 14:32, Girish Venkatasubramanian  
> wrote:
> 
> Hi Frank.
> Yes, I had the incorrect class name. Thanks for pointing that out.
> 
> The class I was asking about was USMUserTable. Same questions however.
> 
> Thanks
> Girish
> 
> 
> On Sun, Mar 10, 2019, 8:59 AM Frank Fock  <mailto:f...@agentpp.com>> wrote:
> Hello Girish,
> 
> A class USMTable does not exists in SNMP4J. Do you meant another class or is 
> this class from a third party?
> 
> Best regards,
> Frank
> 
> > On 8. Mar 2019, at 16:57, Girish Venkatasubramanian  > <mailto:giris...@gmail.com>> wrote:
> > 
> > Hello
> > I was wondering if the USMTable is thread safe.
> > 
> > I see that the USMTable uses a TreeMap which itself is not synchronized
> > (say, unlike a concurrent hash map).
> > 
> > Even though the functions that access it are synchronized it would not
> > prevent a scenario where one thread is calling removeAllUsers() and another
> > thread is invoking addUser() - yes ? Is there some synchronization
> > mechanism that I am missing ?
> > 
> > Would appreciate your response.
> > Thanks
> > Girish
> > ___
> > SNMP4J mailing list
> > SNMP4J@agentpp.org <mailto:SNMP4J@agentpp.org>
> > https://oosnmp.net/mailman/listinfo/snmp4j 
> > <https://oosnmp.net/mailman/listinfo/snmp4j>
> 

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] USMTable and thread safety

2019-03-10 Thread Frank Fock
Hello Girish,

A class USMTable does not exists in SNMP4J. Do you meant another class or is 
this class from a third party?

Best regards,
Frank

> On 8. Mar 2019, at 16:57, Girish Venkatasubramanian  
> wrote:
> 
> Hello
> I was wondering if the USMTable is thread safe.
> 
> I see that the USMTable uses a TreeMap which itself is not synchronized
> (say, unlike a concurrent hash map).
> 
> Even though the functions that access it are synchronized it would not
> prevent a scenario where one thread is calling removeAllUsers() and another
> thread is invoking addUser() - yes ? Is there some synchronization
> mechanism that I am missing ?
> 
> Would appreciate your response.
> Thanks
> Girish
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Usage of Diffie Hellman key exchange using SNMP4j

2019-02-15 Thread Frank Fock
Hello Girish,

Thank you for being interested in the Diffie Hellman key exchange capabilities 
of SNMP4J (it was hard to implement it, so I am glad to here that someone wants 
to use it).
I have put together same sample code at:
https://doc.snmp.app/pages/viewpage.action?pageId=38633473

Please let me know if you have additional questions. 
The sample code could be probably simplified for your use case. If you provide 
us a description of your use case, I could help to get a matching 
implementation.

Best regards,
Frank

> On 14. Feb 2019, at 18:29, Girish Venkatasubramanian  
> wrote:
> 
> Hello
> I see that, as of version 3.0.2, "Diffie Hellman key exchange support with
> the new commands usmDHKey, usmDHKickstartInit, and usmDHKickstartRun" has
> been aded to the command line tool.
> 
> Are there any usage examples available for performing these from a Java
> program using the SNMP4J Java library ?
> Thanks
> Girish
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Question about receiving SNMPv3 traps

2019-01-07 Thread Frank Fock
Hello Girish,

You can use approach (1) with autoDiscoveryEnabled.
if it is not enabled, you will have to use approach (2).

Having a different user ID (you mean securityName) for each trap sender won’t 
help,
because the SNMPv3 USM lookup uses the engineID anyway.

Best regards,
Frank  

> On 7. Jan 2019, at 01:11, Girish Venkatasubramanian  
> wrote:
> 
> Hello
> I am seeking some clarification about receiving SNMPv3 traps using SNMP4J.
> 
> In my setup, I have a few network devices configured for SNMPv3. They all
> use the *same* userName and auth and priv keys. They are configured to use
> authentication and privacy when sending traps.
> 
> In my trap receiver, which I plan to write using SNMP4J, the userName and
> credentials are known.
> 
> 1) In order to receive the traps from these devices, is it sufficient to
> add an entry in the USM cache of my TrapReceiver as below  ?
> 
> *snmp*.getUSM().addUser( *new *OctetString(username),
> 
>   *new *UsmUser(*new *OctetString(username), AuthMD5.
> *ID*, *new *OctetString(authpassphrase), PrivAES128.*ID*, *new *
> OctetString(privacypassphrase)));
> 
> 
> From this email thread,
> http://oosnmp.net/pipermail/snmp4j/2013-April/005042.html I quote
> "
> 
> If you set the autoDiscovery property of the USM to true, then it is
> even easier.
> You do not have to add localized USM users (thus you do not have to know the
> engineIDs of the notification senders), you simply add the users without
> engineID.
> 
> "
> To clarify, do I need to set the autoDiscovery property on the USM of the
> trap receiver ?
> 
> 2) If I have to add a localized user for each of these trap senders, then
> should Snmp.discoverAuthoritativeEngineID(..) be used and then a
> per-trap-sender target be added using this engine ID ? That is, the key
> localization approach as shown
> https://doc.snmp.app/pages/viewpage.action?pageId=1441800
> 
> Ideally, I would like to avoid having to discover the authoritative engine
> ID as that will restrict the ability of my trap receiver to receive traps
> only from known targets . Would having a different userName (but same
> authentication and privacy keys) for each of the trap sender help ?
> 
> Any clarifications on these would be greatly appreciated.
> Thanks
> Girish
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] help: multiple context

2019-01-07 Thread Frank Fock
Hi Yu,
That is intended behavior. The SNMP4J-Agent default context (empty context 
name) is visible in all SNMPv3 contexts although the explicit context takes 
precedence if there are registrations for the same OID in requested context and 
the default context. 

If you want strict separation, you need to put the objects in a second non-null 
context.

The default context is a kind of fallback context. 

Hope this helps.

Best regards 
Frank

> Am 07.01.2019 um 06:39 schrieb Liu, Yu M. (NSB - CN/Beijing) 
> :
> 
> Hi experts,
> 
> We are using Snmp4J to develop our Subagent. Recently, we need to support 
> multiple context function in our subagent and we follow below reference to 
> achieve that.
> https://doc.snmp.app/pages/viewpage.action?pageId=14155780
> 
> But in our testing, we observe that when we configure context "contexta" and 
> ""(empty) together, then snmpwalk context "contexta" MIB table, it will get 
> some OIDs from context ""(empty) MIB table.
> Below is an example, the id "60" and "61" belong to context "contexta", id 
> "64" and "65" belong to context ""(empty).
> [root@ ~]# snmpwalk -n contexta -v 3 -u test1 -a MD5 -A 12345678 -x DES -X 
> 12345678 -l authPriv 10.76.84.132:31101 1.3.6.1.4.1.94.7.1.4.2.1
> SNMPv2-SMI::enterprises.94.7.1.4.2.1.1.60 = INTEGER: 60
> SNMPv2-SMI::enterprises.94.7.1.4.2.1.1.61 = INTEGER: 61
> SNMPv2-SMI::enterprises.94.7.1.4.2.1.2.60 = STRING: 
> "system-system-test/host-host/container-container/service-service/process-process"
> SNMPv2-SMI::enterprises.94.7.1.4.2.1.2.61 = STRING: 
> "system-system-test/host-host/container-container/service-service/process-process"
> SNMPv2-SMI::enterprises.94.7.1.4.2.1.3.60 = Hex-STRING: 07 E2 02 0A 01 24 21 
> 00 2D 00 00
> SNMPv2-SMI::enterprises.94.7.1.4.2.1.3.61 = Hex-STRING: 07 E2 02 0A 01 24 21 
> 00 2D 00 00
> SNMPv2-SMI::enterprises.94.7.1.4.2.1.4.60 = INTEGER: 600033
> SNMPv2-SMI::enterprises.94.7.1.4.2.1.4.61 = INTEGER: 600034
> ...
> SNMPv2-SMI::enterprises.94.7.1.4.2.1.20.64 = ""
> SNMPv2-SMI::enterprises.94.7.1.4.2.1.20.65 = ""
> 
> 
> Would you please help to check if it's normal. Thanks!
> 
> 
> Best Regards,
> Liu Yu
> Tel: +86 10 64798176 (2736 8176)
> Email : yu.m@nokia-sbell.com
> 
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Implementing an SNMP trap receiver in Java EE

2018-12-28 Thread Frank Fock
Hello Nick,

There is already something prepared for that, see 
http://www.snmp4j.org/doc/org/snmp4j/SNMP4JSettings.html#setThreadFactory-org.snmp4j.util.ThreadFactory-
 


Hope this helps.

Best regards,
Frank


> On 28. Dec 2018, at 22:06, Nick Sell  wrote:
> 
> Hello,
> 
> I’m wondering if it is possible to implement a trap receiver in a Java EE 
> environment. Would I need to override or extend the existing classes to use a 
> managed thread pool? Or is a way to handle that already in place? Any 
> information you could provide would be extremely helpful.
> 
> Thanks,
> 
> Nick Sell
> Critical Labs
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] SNMP4J Digest, Vol 140, Issue 3

2018-12-21 Thread Frank Fock
Hi Brett, 
Ok, but please also include the version you are using.
Best regards 
Frank

> Am 21.12.2018 um 10:14 schrieb Brett Wooldridge :
> 
> Thanks, Frank.
> 
> I'll post here after the holidays (first week of January).  I have a
> Wireshark capture of the issue as well as a proposed fix -- which does fix
> the issue in my environment, but of which I am not 100% confident it is
> correct.
> 
> Happy holidays.
> 
> -Brett
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Issue tracker?

2018-12-18 Thread Frank Fock
Hi Brett,

If you have a support subscription, then you can use the AGENT++ JIRA server. 
Otherwise, you can use this mailing list.

Best regards,
Frank

> On 18. Dec 2018, at 11:24, Brett Wooldridge  
> wrote:
> 
> Where can users report issues, and proposed patches?
> 
> Regards,
> Brett Wooldridge
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Multiple SNMPv3 Agents running within same Java process

2018-12-12 Thread Frank Fock


Hi Stu,

The code you quote from https://github.com/joescii/snmp4s/blob/master/core/ 
 seems to be old and not 
production ready.
It is not related to the original SNMP4J and should not be used a reference!

The problem you are facing is caused by the SNMPv3 security standards, thus it 
is not a bug! I t is a feature.
Each SNMP agent (engine) has to have a (world) unique engine ID. And each agent 
needs its own USM.

For tips how to implement this with SNMP4J in the same Java process see the 
“USM separation” section of the FAQ at:
https://doc.snmp.app/pages/viewpage.action?pageId=1441800 


Best regards,
Frank



> On 12. Dec 2018, at 22:30, Stuart Bonsey  wrote:
> 
> Hi,
> 
> I am writing a Java application that creates multiple instances of SNMPv3 
> Agents using SNMP4j-Agent 2.3.1 – a lot like a simulator.
> 
> It is working correctly when I instantiate a single agent, however whenever I 
> start multiple agents, only the last agent responds correctly…all other 
> agents respond with “Unknown user name”
> 
> If I create multiple agents running in separate Java processes, then both 
> agents work as expected.
> 
> Is this a known issue / limitation of SNMP4J-Agent? Or am I doing something 
> wrong?
> 
> I have reproduced the issue using the TestAgent code provide here 
> https://github.com/joescii/snmp4s/blob/master/core/src/test/java/org/snmp4s/TestAgent.java
>  and starting two agents, only the last one responds correctly to v3 requests.
> 
> public static void main(String[] args) {
>TestAgent.start("192.168.178.100/1610");
> TestAgent.start("192.168.178.103/1610");
> }
> 
> Any help here would be greatly appreciated.
> 
> Thanks
> Stu
> 
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] RuntimeException on shutdown

2018-11-15 Thread Frank Fock
Hi Mark,

The following snapshot 2.7.0 release should provide a fix for this issue:
https://snmp.app/dist/snapshot/org/snmp4j/snmp4j/2.7.0-SNAPSHOT/snmp4j-2.7.0-20181115.204944-10.jar
 


Best regards,
Frank

> On 15. Nov 2018, at 18:08, fo...@friendlysnmp.org wrote:
> 
> I implemented notification 'appShutdown' as follows:
> 1. NotificationOriginatorImpl -> notify() with 'appShutdown' notification.
> 2. Snmp -> close() to release all resources.
> 3. Close application.
> 
> The result is exception (line numbers are for SNMP4J v2.6.2):
> java.lang.RuntimeException: java.net.SocketException: socket closed
>  at 
> org.snmp4j.transport.DefaultUdpTransportMapping$ListenThread.run(DefaultUdpTransportMapping.java:455)
>  at java.lang.Thread.run(Thread.java:748)
> Caused by: java.net.SocketException: socket closed
>  at java.net.DualStackPlainDatagramSocketImpl.socketReceiveOrPeekData(Native 
> Method)
>  at 
> java.net.DualStackPlainDatagramSocketImpl.receive0(DualStackPlainDatagramSocketImpl.java:124)
>  at 
> java.net.AbstractPlainDatagramSocketImpl.receive(AbstractPlainDatagramSocketImpl.java:143)
>  at java.net.DatagramSocket.receive(DatagramSocket.java:812)
>  at 
> org.snmp4j.transport.DefaultUdpTransportMapping$ListenThread.run(DefaultUdpTransportMapping.java:397)
>  at java.lang.Thread.run(Thread.java:748)
> 
> I think the reason for the exception thrown is the 'appShutdown' notification 
> confirmation packet comes *after* all resources are closed. The packet is 
> processed in DefaultUdpTransportMapping.ListenThread.run() line-397 
> socketCopy.receive(packet).
> This method throws SocketException because the resources are closed, and the 
> catch at line-455 re-throws RuntimeException.
> As the result DefaultUdpTransportMapping.ListenThread is not stopped and 
> application fails to exit.
> 
> What would you suggest to fix the exception in this scenario?
> Maybe additional boolean flag in TransportMapping could be added to signal 
> WorkerTask not to process any packets if TransportMapping is closed?
> 
> Thanks,
> Mark
> 
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] SNMPv3 -> SNMP4J 3.0.2 (also 3.0.x?)

2018-10-15 Thread Frank Fock
Hi Marian,
Have you added a localized user to the USM? It seems that not the code is wrong 
but the localization of the passphrases is missing.
Best regards 
Frank

> Am 15.10.2018 um 10:16 schrieb Marian Wendt :
> 
> Hi,
> 
> I experience some behaviour that makes me think there is something wrong with 
> USM.java
> Near line 380 the authetication key and privacy key is not retrieved from 
> "UsmUser" and result in NULL.
> I corrected this with the following changes...
> 
>AuthenticationProtocol auth = 
> securityProtocols.getAuthenticationProtocol(user.getUsmUser().getAuthenticationProtocol());
>PrivacyProtocol priv = 
> securityProtocols.getPrivacyProtocol(user.getUsmUser().getPrivacyProtocol());
> 
>usmSecurityParams.setAuthenticationProtocol(auth);
>usmSecurityParams.setPrivacyProtocol(priv);
> 
>
> //usmSecurityParams.setAuthenticationKey(user.getAuthenticationKey());
>
> usmSecurityParams.setAuthenticationKey(user.getUsmUser().getAuthenticationPassphrase().toByteArray());
>//usmSecurityParams.setPrivacyKey(user.getPrivacyKey());
>
> usmSecurityParams.setPrivacyKey(user.getUsmUser().getPrivacyPassphrase().toByteArray());
> 
>usmSecurityParams.setUserName(user.getUsmUser().getSecurityName());
>usmSecurityParams.setAuthoritativeEngineID(secEngineID.getValue());
> 
> After that, the SNMPv3 trap sending is working correct but still has:
> 
> trace: usm_parse_security_parameters(): snmpusm.c, 2052:
> dumph_recv: msgAuthenticationParameters
> trace: usm_process_in_msg(): snmpusm.c, 2385:
> usm: Parsing failed (rc -1).
> trace: snmpv3_parse(): snmp_api.c, 3784:
> dumph_recv: ScopedPDU
> trace: _snmp_parse(): snmp_api.c, 4162:
> snmp_parse: Parsed SNMPv3 message (secName:your-security-name, 
> secLevel:authPriv): USM parse error
> trace: _sess_process_packet(): snmp_api.c, 5249:
> sess_process_packet: received message id#6744 reqid#0 len 210
> trace: _sess_process_packet(): snmp_api.c, 5252:
> sess_process_packet: parse fail
> trace: _sess_read(): snmp_api.c, 5542:
> sess_read: not reading 7 (fdset 0x7ffce2c22a60 set 0)
> trace: _sess_read(): snmp_api.c, 5542:
> sess_read: not reading 5 (fdset 0x7ffce2c22a60 set 0)
> trace: _sess_read(): snmp_api.c, 5542:
> sess_read: not reading 3 (fdset 0x7ffce2c22a60 set 0)
> trace: snmp_sess_select_info2_flags(): snmp_api.c, 6051:
> sess_select: for all sessions: 9 7 5 3
> 
> (log output from snmptrapd on linux)
> So I think there is still something wrong with the library...
> 
> Best regards
> 
> ibes AG - we create more value with IT.
> 
> Management board: Tino M?ller, Jens Schwendel, Frank Lippmann
> Chairman of the supervisory board: Prof. Dr. Reinhardt Nindel
> Trade register: Amtsgericht Chemnitz HRB 28538
> i...@ibes.ag | www.ibes.ag | www.sercam.de
> 
> This e-mail may contain confidential and/or privileged information. If you 
> are not the intended recipient (or have received this e-mail in error) please 
> notify the sender immediately and destroy this e-mail. Any unauthorized 
> copying, disclosure or distribution of the material in this e-mail is 
> strictly forbidden.
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


[SNMP4J] AGENT++ Notifications on Platform Updates

2018-10-13 Thread Frank Fock
Hi,

Please be advised that FastSpring, our e-commerce partner, will be performing a 
scheduled maintenance for an infrastructure upgrade that will require a brief 
interruption of the services on the FastSpring platform:

Date:  Saturday October 20, 2018

Start Time:  8:00 PM Pacific Time
End Time:   9:00 PM Pacific Time

Impact: During this maintenance window you will not be able to complete a 
purchase from our store. Thank you for your patience during our upgrade. 

For any questions / concerns, please contact ord...@fastspring.com 
<mailto:ord...@fastspring.com>.

In addition, the AGENT++ Wiki, the free MIB checker, and the evaluation license 
service have been already moved to new infrastructure and domain.
Former available under https://oosnmp.net <https://oosnmp.net/>, these services 
are now available from https://snmp.app <https://snmp.app/> and 
https://doc.snmp.app <https://doc.snmp.app/> respectively. 
The SNMP4J distribution files and Maven repo are now available at 
https://snmp.app/dist <https://snmp.app/dist> too. 

The support JIRA will follow to the new infrastructure on November, 3rd.  

Best regards,
Frank Fock


___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Java9+ required now?

2018-10-03 Thread Frank Fock
Hi,

As there is already Java 10 available, we do not need to talk about.Java 9 
anymore ;-)

DTLS works as expected although the interoperability with OpenSSL DTLS and its 
NET-SNMP implementation of that was not easy, because NET-SNMP sends some 
packets in a way the Java DTLS SSLEngine leaves the API user in a state where 
the SSLEngine documentation lacks information how to continue processing. I 
figured it out finally, but it was not straight forward. 

Nevertheless, DTLS works fine. With Java 10, the implementation seems to have 
improved further regarding error handling and debugging. 
If you need encryption on UDP, then why not using plain SNMPv3? Its handshake 
and privacy is much faster and uses much less bandwidth than using 
(unoptimised) DTLS.  
With DTLS you should reduce the number of offered algorithms to a minimum on 
both communication ends to reduce handshake packet sizes.
But even then, SNMPv3 is more lightweight. 
DTLS advantage is using certificate chains. If you do not already have them in 
place, plain SNMPv3 over UDP would be the better choice.

Best regards,
Frank

> On 2. Oct 2018, at 11:11, Maayan, Elhanan  wrote:
> 
> Hi, I'd like to "hijack" this thread, if it's ok, and ask a few questions 
> about DTLS
> 
> We have a java app that communicates with device over UDP, with custom binary 
> protocol, and we are considering a few options on how to encrypt them. 
> 
> One of them was DTLS, but this was rejected, because of several reasons. 
> 
> 1. DTLS was only recently inserted into java, so we don't really know how 
> stable it is 
> 2. the java implementation, still leaves you with a lot of "low level" 
> implementation like message ordering, (I'm not sure if this can be handled on 
> any other level with UDP and DTLS) 
> 3. java 9 itself is considered broken, eol, and on top of that migrating to 
> it , extremely problematic , I suspect many organizations won't go for it due 
> to those reasons. 
> 
> 
> How hard was it to integrate DTLS? Have you considered other options? 
> 

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Java9+ required now?

2018-10-01 Thread Frank Fock
Hio Jeremy,

DTLS, which is new in SNMP4J 3.x, is supported by Java 9+ only.

Best regards,
Frank 


> On 1. Oct 2018, at 22:53, Jeremy Norris  wrote:
> 
> Hi,
> 
> I was just curious as to the reasoning behind requiring Java9+, instead of 
> say Java8+?
> 
> Thanks,
> Jeremy
> 
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


[SNMP4J] SNMP4J 3.0.0 Released

2018-09-17 Thread Frank Fock
Hi,

After several delays due to implementation difficulties regarding the DTLS 
support, SNMP4J 3.0 has been finally released today.
The DTLS implementation has been successfully tested with NET-SNMP 5.8 using 
the Java 10 DTLSv1.2 protocol implementation.

Besides the long awaited DTLS support it provides:

* Diffie Hellman key exchange.
* New/improved command line tool “SnmpCommand” which support TLS and DTLS.
* Java 9 module support.

RELEASE NOTES

SNMP4J 3.0.0

* Added [SFJ-114]:Implemented DTLS support according to RFC 6353 by DTLSTM.
* Added [SFJ-175]: Support for Java 9 modules.
* Improved [SFJ-88]: Replaced Vector return Value in PDU.getVariableBindings() 
with List and removed Vector from
  other inner usages, i.e. by listener lists.
* Fixed [SFJ-132]: TableUtils is caught in a notify when agent does not return 
VBs in lexicographic order.
* Fixed [SFJ-133]: DefaultUdpTransportMapping getListenAddress() does not 
return the local IP address.
* Fixed [SFJ-134]: DefaultUdpTransportMapping listen() fails to run if socket 
timeout is non-zero.
* Fixed [SFJ-169]: Removed log4j dependency because Log4j is no further 
maintained.
* Added: New TableUtils retrieval operation modes to better support dense table 
operations.
* Improved: Optimized wait time for sync responses.
* Changed: SNMP4J 3.x depends on Java 9 (or later).
* Improved: Optimised OID BER decoding and made some OID helper methods public.
* Added: Added OID.toUnsignedLongArray().
* Added: Added OID.getSuffix method. Improved logging for USM.
* Improved: Removed SHA and MD5 from default protocols and fixed unit tests 
accordingly.
* Improved: 3DES test prints warning when protocol is not supported by JRE 
instead bailing out.
* Changed: Changed removePrivacyProtocol method signature to use OID instead 
protocol object.
* Improved: SecurityProtocols now ignore custom mapping with zero size custom 
OID.
* Changed: Moved setLocalEngineID and getLocalEngineID methods from Snmp to 
Session.
* Improved: ConsoleLogAdapter now optionally (but by default) prints out time 
and always log level.
* Changed: SnmpRequest class by a completely new implementation 'SnmpCommand' 
using the SnmpConfigurator class.
  The new implementation provides better help and command syntax as well as 
support for TLS and DTLS.
  Its syntax and command support is similar to SNMP4J-CLT which provides MIB, 
USM user management,
  and Diffie Hellman operations in addition.
* Changed: Removed SSH related transport mapping classes.

SNMP4J-CLT 3.0, SNMP4J-Agent and SNMP4J-Agent-DB 3.0 as well as SNMP4J-AgentX 
3.0 will be released 2018-09-24.

Best regards 
Frank Fock

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


[SNMP4J] Release of SNMP4J 3.0 Deferred

2018-09-10 Thread Frank Fock
Hi,

Due to interoperability issues with NET-SNMP DTLS agent regarding DTLS 
connection establishment, the release of SNMP4J 3.0 has to be shifted by one 
week (at least).
The release is now scheduled for 17.9.2018.

Best regards,
Frank Fock


___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


[SNMP4J] New Releases AgenPro 4.2.3 / MIB Designer 4.2.3 / MIB Explorer Pro/Lite 4.3.2

2018-08-17 Thread Frank Fock

Hi,

There are new releases of AgenPro, MIB Designer, and MIB Explorer available for 
download. The new releases now detect if Java FX is available in the Java 
runtime. If not, the local browser is used to display the help. You can 
override the autodetection with the -Dcom.agentpp.jfx=true or 
-Dcom.agentpp.jfx=false JRE parameter.

Besides that, SNMP4J 3.0 beta (SNAPSHOT) release is available with DTLS support 
which has been successfully tested with NET-SNMP 5.8 (DTLSv1.2).
See https://oosnmp.net/dist/snapshot/org/snmp4j/snmp4j/3.0.0-SNAPSHOT/ 
<https://oosnmp.net/dist/snapshot/org/snmp4j/snmp4j/3.0.0-SNAPSHOT/>

The releases for SNMP4J 3.0, SNMP4J-Agent 3.0, SNMP4J-Agent-DB 3.0, and 
SNMP4J-AgentX 3.0 are scheduled for 10.09.2018.

Best regards,
Frank Fock


___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Consecutive SNMPv3 GET Requests using same User

2018-08-08 Thread Frank Fock
Hi Ulrich,

A SNMP entity is any command generator or command responder instance. An 
instance of org.snmp4j.Snmp is a SNMP entity too.

Bes regards,
Frank

> On 8. Aug 2018, at 09:16, ulrich berl  wrote:
> 
> Hi Frank,
>  
> Thanks for your explanation.
>  
>>>> With non-localised users, you can use a single user entry for several SNMP 
>>>> entities. To be able to do so,
> the agent must know the passphrase which is stored unencrypted in the local 
> persistent storage.
>  
> What exactly do you mean by 'SNMP entities' ? Is this an instance of class 
> org.snmp4j.Snmp ?
> In this sentence the 'agent' is the SnmpManager ?
> 
>>>> With localised users, you will not have this security drawback. The stored 
>>>> key, is only usable with a target it has been localised for.
> No passphrase is stored persistently (only the localised key).
> 
> Yep, i saw this during debugging of a snmp request.
>  
>>>> You can mix both approaches too, but that would require more additional 
>>>> management overhead, because localised instances of a generic user need to 
>>>> be explicitly deleted if the generic user is updated.
> Thats the case using snmp.getUSM().addUser(...): user must be removed in case 
> of update.
>  
> br, Ulrich
>  
> 
> Gesendet: Dienstag, 07. August 2018 um 19:46 Uhr
> Von: "Frank Fock" mailto:f...@agentpp.com>>
> An: "ulrich berl" mailto:ulrich.b...@gmx.net>>
> Cc: snmp4j@agentpp.org <mailto:snmp4j@agentpp.org>
> Betreff: Re: [SNMP4J] Consecutive SNMPv3 GET Requests using same User
> Hi Ulrich,
> 
> If you need highest security, then use localised users only.
> With non-localised users, you can use a single user entry for several SNMP 
> entities. To be able to do so,
> the agent must know the passphrase which is stored unencrypted in the local 
> persistent storage.
> 
> With localised users, you will not have this security drawback. The stored 
> key, is only usable with a target it has been localised for.
> No passphrase is stored persistently (only the localised key).
> 
> SNMP4J offers both approaches, users have to choose which one best fits to 
> their requirements.
> You can mix both approaches too, but that would require more additional 
> management overhead, because localised instances of a generic user need to be 
> explicitly deleted if the generic user is updated.
> 
> Best regards,
> Frank
> 
> 
>> On 7. Aug 2018, at 14:30, ulrich berl  wrote:
>> 
>> Take the following:
>> 
>> A SnmpManager application creates one (global) instance of class 
>> org.snmp4j.Snmp after startup.
>> 
>> SnmpManager application will do consecutive SNMPv3 GET Requests (sysDescr) 
>> with user MD5 using global snmp instance.
>> The authPassphrase for user MD5 is changeable between GET Requests.
>> 
>> 
>> If i do an snmp.getUSM().addUser(...) in the getRequest(...):
>> 
>> [OK] Request 1 - CorrectAuthPassphrase -> sysDescr returned
>> --- change authPassphrase in SnmpManager application
>> [NOK] Request 2 - WrongAuthPassphrase -> sysDescr returned <-- should be an 
>> authentication failure
>> 
>> 
>> If i do an snmp.getUSM().addLocalizedUser(...) in the getRequest(...):
>> 
>> [OK] Request 1 - CorrectAuthPassphrase -> sysDescr returned
>> --- change authPassphrase in SnmpManager application
>> [OK] Request 2 - WrongAuthPassphrase -> error
>> 
>> So for such an application i should always use localized users 
>> (https://oosnmp.net/confluence/pages/viewpage.action?pageId=1441800) or 
>> clearing the user table before next request ?
>> What about the snmp.getUSM().addUser(...) method - when to use this method ?
>> 
>> br, Ulrich
>> 
>> 
>> ___
>> SNMP4J mailing list
>> SNMP4J@agentpp.org
>> https://oosnmp.net/mailman/listinfo/snmp4j[https://oosnmp.net/mailman/listinfo/snmp4j
>>  
>> <https://oosnmp.net/mailman/listinfo/snmp4j[https://oosnmp.net/mailman/listinfo/snmp4j>]

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Consecutive SNMPv3 GET Requests using same User

2018-08-07 Thread Frank Fock
Hi Ulrich,

If you need highest security, then use localised users only. 
With non-localised users, you can use a single user entry for several SNMP 
entities. To be able to do so,
the agent must know the passphrase which is stored unencrypted in the local 
persistent storage. 

With localised users, you will not have this security drawback. The stored key, 
is only usable with a target it has been localised for.
No passphrase is stored persistently (only the localised key).

SNMP4J offers both approaches, users have to choose which one best fits to 
their requirements. 
You can mix both approaches too, but that would require more additional 
management overhead, because localised instances of a generic user need to be 
explicitly deleted if the generic user is updated.   

Best regards,
Frank


> On 7. Aug 2018, at 14:30, ulrich berl  wrote:
> 
> Take the following:
> 
> A SnmpManager application creates one (global) instance of class 
> org.snmp4j.Snmp after startup.
> 
> SnmpManager application will do consecutive SNMPv3 GET Requests (sysDescr) 
> with user MD5 using global snmp instance.
> The authPassphrase for user MD5 is changeable between GET Requests.
> 
> 
> If i do an snmp.getUSM().addUser(...) in the getRequest(...):
> 
> [OK] Request 1 - CorrectAuthPassphrase -> sysDescr returned
> --- change authPassphrase in SnmpManager application
> [NOK] Request 2 - WrongAuthPassphrase -> sysDescr returned <-- should be an 
> authentication failure
> 
> 
> If i do an snmp.getUSM().addLocalizedUser(...) in the getRequest(...):
> 
> [OK] Request 1 - CorrectAuthPassphrase -> sysDescr returned
> --- change authPassphrase in SnmpManager application
> [OK] Request 2 - WrongAuthPassphrase -> error
> 
> So for such an application i should always use localized users 
> (https://oosnmp.net/confluence/pages/viewpage.action?pageId=1441800) or 
> clearing the user table before next request ?
> What about the snmp.getUSM().addUser(...) method - when to use this method ?
> 
> br, Ulrich
> 
> 
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Unit Test SNMP v3 Agent with TestSnmpManager

2018-08-06 Thread Frank Fock
Hi Ulrich,

You can use the description for your case too:
https://oosnmp.net/confluence/pages/viewpage.action?pageId=1441800 
<https://oosnmp.net/confluence/pages/viewpage.action?pageId=1441800>

Hope this helps.

Best regards,
Frank Fock

> On 6. Aug 2018, at 14:44, ulrich berl  wrote:
> 
> Hi!
>  
> I wrote a SNMP v3 Agent. The agent was tested using a third-party 
> SnmpManager, works fine if configured with the allowed usm users; additional 
> if vor a valid user a wrong authpassphrase is supplied, the request is not 
> successful.
>  
> So i wrote some unit tests for the agent, BUT the problem is, that using a 
> TestSnmpManager - using snmp4j too - allows only one instance of 
> SecurityModels, which will be written by Agent and the TestSnmpManager 
> (having same id SECURITY_MODEL_USM, so will be overwritten).
> 
> So in this scenario in my test i can successful query eg. sysDescr from agent 
> using an allowed v3 user with wrong authpassphrase ...
> 
> How to successful write such an unit test using Agent AND TestSnmpManager 
> (snmp4j) to eg. verify get request for valid v3 user with correct/wrong 
> passphrases ?
> Or i have to create binary for TestSnmpManager and use it as external tool ?
> 
> br, Ulrich
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] max-bindings with big tables

2018-07-23 Thread Frank Fock
Hi Steffen,

OK, I understand the difference. Nevertheless, the current snapshot already 
fixes this issue too. 
Although SNMP4J TableUtils could probably handle this kind of scenario smarter, 
the scenario you describe is very rare:
1. You configured max-rep-count*max-bindings = 6 > max columns (=5). The 
opposite is recommended. 
2. The agent seems to cut off a whole row (a whole repetition) to return a PDU 
below maxResponsePDUSize (or MTU). According to the SNMPv2c/v3 standard, only 
those VBs should be removed from the response, that actually break the limit. 
Thus, in your case the agent should most likely return at least one column of 
the first part of row “1” instead of returning none.

Have you tried the latest 3.0 SNAPSHOT already?
Both dense table modes: 
* denseTableDoubleCheckIncompleteRows
* denseTableDropIncompleteRows
should return your row “1” in one TableEvent.

Best regards,
Frank


> On 23. Jul 2018, at 19:23, Steffen Brüntjen  
> wrote:
> 
> Hi!
> 
>> However the problem you described should not happen with a static 
>> (unchanged) table, because of the inner logic of TableUtils.
> 
> I'm sorry, but I still believe I was unable to make the problem clear. You 
> wrote, this problem should not appear in tables that don't change OR it may 
> appear when the agent doesn't return rows in lexicographic order. The latter 
> case is perceived just like row creation or row deletion is happening while 
> retrieving the table. I understand that and I can't rule out the possibility 
> that there's an error in the agent, although I have analyzed all the packets 
> in Wireshark. I was also debugging the TableUtils and I still think, the bug 
> is there. So let me try to explain it one last time.
> 
> Let's say we have this configuration:
> 
> max-repetition-count = 2
> max-bindings = 3
> requested table columns = 5
> 
> IDX |  A  |  B  |  C  |  D  |  E  |
> +-+-+-+-+-+
> 0   |  1  |  2  |  3  |  4  |  5  |
> 1   |  6  |  7  |  8  |  9  | 10  |
> 2   | 11  | 12  | 13  | 14  | 15  |
> 3   | 16  | 17  | 18  | 19  | 20  |
> 
> SNMP4J will ask for A, B, C (max-bindings=3)
> DEVICE will return A.0=1, B.0=2, C.0=3 (DEVICE decides to not send a 2. row 
> because of MTU size) 
> SNMP4J will ask for D, E
> DEVICE will return D.0=4, E.0=5, D.1=9, E.1=10 (max-repetition-count = 2)
> 
> And here we're running into the problem. TableUtils "creates" an inner table 
> in this state:
> 
> IDX |  A  |  B  |  C  |  D  |  E  |
> +-+-+-+-+-+
> 0   |  1  |  2  |  3  |  4  |  5  |
> 1   |null |null |null |  9  | 10  |
> 
> 
> Now we'll continue:
> 
> SNMP4J will ask for A.0, B.0, C.0 (GETNEXT)
> DEVICE will return A.1=6, B.1=7, C.1=8
> 
> What TableUtils now does is:
> 
> IDX |  A  |  B  |  C  |  D  |  E  |
> +-+-+-+-+-+
> 0   |  1  |  2  |  3  |  4  |  5  |
> 1   |null |null |null |  9  | 10  |
> 1   |  6  |  7  |  8  |null |null |
> ...
> 
> 
> This is the phenomenon I'm actually observing and that I am trying to 
> describe. So once again: The table doesn't change and the problem is 100% 
> reproducable. In my case:
> 
> - 100% of table retrievals with max-bindings != 4 is ok
> - 100% of table retrievals with max-bindings == 4 is broken 
> 
> 
> This problem will never appear with max-bindings=1 or max-bindings=infinite, 
> and it will never appear when the agent always sends the exact requested 
> repetitions.
> 
> Best regards
> Steffen Brüntjen
> 
> 
> -Original Message-
> From: Frank Fock [mailto:f...@agentpp.com] 
> Sent: Donnerstag, 19. Juli 2018 19:35
> To: Steffen Brüntjen 
> Cc: snmp4j@agentpp.org
> Subject: Re: [SNMP4J] max-bindings with big tables
> 
> Hi Steffen 
> I think I understood your description correctly from the beginning. However 
> the problem you described should not happen with a static (unchanged) table, 
> because of the inner logic of TableUtils. 
> I assume, that the agent does not return the rows in lexicographic order. 
> That would have the same effect as if a row is dynamically appearing during 
> retrieval. 
> 
> I do not want to exclude an off-by-one error in TableUtils but all unit tests 
> I run so far do not indicate that. 
> 
> What agent are you using?
> 
> Nevertheless, the new version will not show the issue you observed with the 
> mode denseTableDoubleCheckIncompleteRows
> 
> Best regards 
> Frank
> 
>> Am 19.07.2018 um 17:20 schrieb Steffen Brüntjen 
>> :
>> 
>> Hi Frank
>> 
>> 
>> I'm not sure whether we're talking about the same thing. The problem I 
>> described is *not* a timinig problem with row

Re: [SNMP4J] max-bindings with big tables

2018-07-18 Thread Frank Fock
Hi Steffen,

The latest SNMP4J-3.0.0-SNAPSHOT contains a getTable method in TableUtils with 
a new parameter SparseTableMode which can be used to control the behaviour for 
tables that do not contain Null (not-accessible) cells (= dense tables). 

Even for the situation, that rows appear or disappear during the retrieval, a 
solution could be implemented. In this case, a GET will fetch the missing 
columns. If they cannot be fetched, the row is ignored (because it disappeared).

Hope this helps?

Best regards,
Frank


> On 12. Jul 2018, at 08:40, Frank Fock  wrote:
> 
> Hi Steffen,
> 
> If the agent sends a tooBig error on a GETBULK request, then this is an error 
> in the agent. See RFC3416 4.2.3:
>   
>   If the size of the message encapsulating the Response-PDU
> containing the requested number of variable bindings would be
> greater than either a local constraint or the maximum message
> size of the originator, then the response is generated with a
> lesser number of variable bindings.  This lesser number is the
> ordered set of variable bindings with some of the variable
> bindings at the end of the set removed, such that the size of
> the message encapsulating the Response-PDU is approximately
> equal to but no greater than either a local constraint or the
> maximum message size of the originator.  Note that the number
> of variable bindings removed has no relationship to the values
> of N, M, or R.
> 
> For the issue you reported, there is no general solution, because it 
> interferes with sparse tables. 
> A solution would either decrease the performance for sparse tables or will 
> filter out sparse rows. 
> The latter is not acceptable for intentionally sparse tables. 
> For dense tables, the filtering could be the best option. Although it would 
> hide new rows although the command generator already detected them.
> 
> I am currently about to add an option for getDenseTable to activate a 
> filtering for new rows that appear during the table retrieval and are 
> therefore incompletely received. Would that help you?
> 
> Best regards,
> Frank 
> 
>> On 9. Jul 2018, at 19:45, Steffen Brüntjen  
>> wrote:
>> 
>> Hi Frank
>> 
>> Thank you for having a look at it. I agree, the performance with many 
>> bindings is indeed *much* higher and yes, values should be retrieved 
>> row-by-row in order to avoid data inconsistencies. But there are also 
>> problems with many bindings:
>> 
>> 1. Since the agent can not - in the contrast to max-repetition-count - 
>> decide how many values to send, the packet size might get too big if you 
>> have a table with many (big) columns.
>> 
>> 2. There are agents that get into trouble when many columns are requested. 
>> This often results in timeouts (no tooBig error) and then there's no other 
>> option to requesting fewer bindings.
>> 
>> Maybe the proposed change is the way to go, it's decent, but effective (I 
>> believe).
>> 
>> Best regards
>> Steffen 
>> 
>> 
>> -Original Message-
>> From: Frank Fock [mailto:f...@agentpp.com] 
>> Sent: Freitag, 6. Juli 2018 18:55
>> To: Steffen Brüntjen 
>> Cc: snmp4j@agentpp.org
>> Subject: Re: [SNMP4J] max-bindings with big tables
>> 
>> Hi Steffen,
>> I will try to reproduce this issue. 
>> Independent from the result, the parameters for TableUtils are not suitable 
>> for your setup. The maxNumColumnsPerPDU has to be as large as possible. 
>> Otherwise the overall performance will be bad and the likelihood of 
>> incomplete table rows increases significantly (through changes in the agent 
>> while TableUtils operate).
>> Best regards 
>> Frank
>> 
>>> Am 06.07.2018 um 10:20 schrieb Steffen Brüntjen 
>>> :
>>> 
>>> Hi!
>>> 
>>> I'm using SNMP4J version 2.6.2.
>>> 
>>> Best regards
>>> Steffen
>>> 
>>> -Original Message-
>>> From: Frank Fock [mailto:f...@agentpp.com] 
>>> Sent: Donnerstag, 5. Juli 2018 19:37
>>> To: Steffen Brüntjen 
>>> Cc: snmp4j@agentpp.org
>>> Subject: Re: [SNMP4J] max-bindings with big tables
>>> 
>>> Hi Steffen 
>>> What SNMP4J version are you using?
>>> Best regards 
>>> Frank
>>> 
>>>> Am 05.07.2018 um 17:04 schrieb Steffen Brüntjen 
>>>> :
>>>> 
>>>> Hi Frank
>>>> 
>>>> I believe I found an issue in the TableUtils class. In certain scenarios, 
>&g

Re: [SNMP4J] max-bindings with big tables

2018-07-12 Thread Frank Fock
Hi Steffen,

If the agent sends a tooBig error on a GETBULK request, then this is an error 
in the agent. See RFC3416 4.2.3:

If the size of the message encapsulating the Response-PDU
 containing the requested number of variable bindings would be
 greater than either a local constraint or the maximum message
 size of the originator, then the response is generated with a
 lesser number of variable bindings.  This lesser number is the
 ordered set of variable bindings with some of the variable
 bindings at the end of the set removed, such that the size of
 the message encapsulating the Response-PDU is approximately
 equal to but no greater than either a local constraint or the
 maximum message size of the originator.  Note that the number
 of variable bindings removed has no relationship to the values
 of N, M, or R.

For the issue you reported, there is no general solution, because it interferes 
with sparse tables. 
A solution would either decrease the performance for sparse tables or will 
filter out sparse rows. 
The latter is not acceptable for intentionally sparse tables. 
For dense tables, the filtering could be the best option. Although it would 
hide new rows although the command generator already detected them.

I am currently about to add an option for getDenseTable to activate a filtering 
for new rows that appear during the table retrieval and are therefore 
incompletely received. Would that help you?

Best regards,
Frank 

> On 9. Jul 2018, at 19:45, Steffen Brüntjen  
> wrote:
> 
> Hi Frank
> 
> Thank you for having a look at it. I agree, the performance with many 
> bindings is indeed *much* higher and yes, values should be retrieved 
> row-by-row in order to avoid data inconsistencies. But there are also 
> problems with many bindings:
> 
> 1. Since the agent can not - in the contrast to max-repetition-count - decide 
> how many values to send, the packet size might get too big if you have a 
> table with many (big) columns.
> 
> 2. There are agents that get into trouble when many columns are requested. 
> This often results in timeouts (no tooBig error) and then there's no other 
> option to requesting fewer bindings.
> 
> Maybe the proposed change is the way to go, it's decent, but effective (I 
> believe).
> 
> Best regards
> Steffen 
> 
> 
> -Original Message-
> From: Frank Fock [mailto:f...@agentpp.com] 
> Sent: Freitag, 6. Juli 2018 18:55
> To: Steffen Brüntjen 
> Cc: snmp4j@agentpp.org
> Subject: Re: [SNMP4J] max-bindings with big tables
> 
> Hi Steffen,
> I will try to reproduce this issue. 
> Independent from the result, the parameters for TableUtils are not suitable 
> for your setup. The maxNumColumnsPerPDU has to be as large as possible. 
> Otherwise the overall performance will be bad and the likelihood of 
> incomplete table rows increases significantly (through changes in the agent 
> while TableUtils operate).
> Best regards 
> Frank
> 
>> Am 06.07.2018 um 10:20 schrieb Steffen Brüntjen 
>> :
>> 
>> Hi!
>> 
>> I'm using SNMP4J version 2.6.2.
>> 
>> Best regards
>> Steffen
>> 
>> -Original Message-
>> From: Frank Fock [mailto:f...@agentpp.com] 
>> Sent: Donnerstag, 5. Juli 2018 19:37
>> To: Steffen Brüntjen 
>> Cc: snmp4j@agentpp.org
>> Subject: Re: [SNMP4J] max-bindings with big tables
>> 
>> Hi Steffen 
>> What SNMP4J version are you using?
>> Best regards 
>> Frank
>> 
>>> Am 05.07.2018 um 17:04 schrieb Steffen Brüntjen 
>>> :
>>> 
>>> Hi Frank
>>> 
>>> I believe I found an issue in the TableUtils class. In certain scenarios, 
>>> the returned List from getTable(Target target, OID[] 
>>> columnOIDs, OID lowerBoundIndex, OID upperBoundIndex) will contain 
>>> incomplete and duplicate rows.
>>> 
>>> 
>>> Here's an extract of an exemplary List for a "good" result:
>>> 
>>> [1.3.6.1.2.1.31.1.1.1.1.278 = VLAN105, [...], 1.3.6.1.2.1.31.1.1.1.18.278 = 
>>> service]
>>> [1.3.6.1.2.1.31.1.1.1.1.279 = VLAN106, [...], 1.3.6.1.2.1.31.1.1.1.18.279 = 
>>> reception]
>>> [1.3.6.1.2.1.31.1.1.1.1.283 = VLAN110, [...], 1.3.6.1.2.1.31.1.1.1.18.283 = 
>>> voice]
>>> [1.3.6.1.2.1.31.1.1.1.1.373 = VLAN200, [...], 1.3.6.1.2.1.31.1.1.1.18.373 = 
>>> clients]
>>> [1.3.6.1.2.1.31.1.1.1.1.774 = VLAN601, [...], 1.3.6.1.2.1.31.1.1.1.18.774 = 
>>> VLAN601]
>>> [1.3.6.1.2.1.31.1.1.1.1.783 = VLAN610, [...], 1.3.6.1.2.1.31.1.1.1.18.783 = 
>>> lab6]
>>> 
>>> 
>>> But 

Re: [SNMP4J] snmp4j TestAgent example v3 trap configuration faulty ?

2018-07-12 Thread Frank Fock
Hi Ulrich,

I was intended to test/illustrate how VACM security works for notifications and 
traps. Many users are not aware that SNMP4J-Agent checks the access rights for 
outgoing variable bindings of a trap.

The AgenPro configuration template does not contain this (intended) 
inconsistency. Nevertheless, even this template is not a ready to use 
configuration for a production deployment, because it uses standard passwords 
and may not match your security requirements, because SNMPv1 and v2c are 
enabled by default.

Best regards,
Frank


> On 11. Jul 2018, at 14:54, ulrich berl  wrote:
> 
> Hi!
> 
> I try to receive the v3 trap coldStartNotification from TestAgent sample.
> 
> Using the TestAgent from test folder (2.6.3) i get the known vacm access 
> denied error:
> 
> Found group name 'v3group' for secName 'v3notify' and secModel 3
> Access denied by VACM for 1.3.6.1.6.3.1.1.5.1
> 
> After inspecting the code i can see, that
> 
> TargetParams for "v3notify" are set to NOAUTH_NOPRIV but VACM for "v3group" 
> is set to AUTH_PRIV.
> User "v3notify" has no AUTH/PRIV params configured.
> 
> Working configurations:
> 
> setting group of v3notify to v3restricted (this group has NOAUTH_NOPRIV and 
> allows reading 1.3.6.1.6.3.1.1.5.1)
> 
> or
> 
> for TargetParams of "v3notify" setting SecurityLevel to AUTH_PRIV and secName 
> to "SHADES", so outgoing message will be encrypted
> (the usm user has to be configured in the manager application)
> 
> Was this intentionally configured or i miss something ?
> 
> br, Ulrich
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] max-bindings with big tables

2018-07-06 Thread Frank Fock
Hi Steffen,
I will try to reproduce this issue. 
Independent from the result, the parameters for TableUtils are not suitable for 
your setup. The maxNumColumnsPerPDU has to be as large as possible. Otherwise 
the overall performance will be bad and the likelihood of incomplete table rows 
increases significantly (through changes in the agent while TableUtils operate).
Best regards 
Frank

> Am 06.07.2018 um 10:20 schrieb Steffen Brüntjen :
> 
> Hi!
> 
> I'm using SNMP4J version 2.6.2.
> 
> Best regards
> Steffen
> 
> -Original Message-
> From: Frank Fock [mailto:f...@agentpp.com] 
> Sent: Donnerstag, 5. Juli 2018 19:37
> To: Steffen Brüntjen 
> Cc: snmp4j@agentpp.org
> Subject: Re: [SNMP4J] max-bindings with big tables
> 
> Hi Steffen 
> What SNMP4J version are you using?
> Best regards 
> Frank
> 
>> Am 05.07.2018 um 17:04 schrieb Steffen Brüntjen 
>> :
>> 
>> Hi Frank
>> 
>> I believe I found an issue in the TableUtils class. In certain scenarios, 
>> the returned List from getTable(Target target, OID[] columnOIDs, 
>> OID lowerBoundIndex, OID upperBoundIndex) will contain incomplete and 
>> duplicate rows.
>> 
>> 
>> Here's an extract of an exemplary List for a "good" result:
>> 
>> [1.3.6.1.2.1.31.1.1.1.1.278 = VLAN105, [...], 1.3.6.1.2.1.31.1.1.1.18.278 = 
>> service]
>> [1.3.6.1.2.1.31.1.1.1.1.279 = VLAN106, [...], 1.3.6.1.2.1.31.1.1.1.18.279 = 
>> reception]
>> [1.3.6.1.2.1.31.1.1.1.1.283 = VLAN110, [...], 1.3.6.1.2.1.31.1.1.1.18.283 = 
>> voice]
>> [1.3.6.1.2.1.31.1.1.1.1.373 = VLAN200, [...], 1.3.6.1.2.1.31.1.1.1.18.373 = 
>> clients]
>> [1.3.6.1.2.1.31.1.1.1.1.774 = VLAN601, [...], 1.3.6.1.2.1.31.1.1.1.18.774 = 
>> VLAN601]
>> [1.3.6.1.2.1.31.1.1.1.1.783 = VLAN610, [...], 1.3.6.1.2.1.31.1.1.1.18.783 = 
>> lab6]
>> 
>> 
>> But in some specific circumstances, I get results like these:
>> 
>> [ ... 75 normal rows ... ]
>> [1.3.6.1.2.1.31.1.1.1.1.278 = VLAN105, [...], 1.3.6.1.2.1.31.1.1.1.18.278 = 
>> service] 
>> [1.3.6.1.2.1.31.1.1.1.1.279 = VLAN106, [...], 1.3.6.1.2.1.31.1.1.1.18.279 = 
>> reception]
>> [null, null, null, null, 1.3.6.1.2.1.31.1.1.1.14.283 = 2, 
>> 1.3.6.1.2.1.31.1.1.1.15.283 = 0, 1.3.6.1.2.1.31.1.1.1.18.283 = voice]
>> [null, null, null, null, 1.3.6.1.2.1.31.1.1.1.14.373 = 2, 
>> 1.3.6.1.2.1.31.1.1.1.15.373 = 0, 1.3.6.1.2.1.31.1.1.1.18.373 = clients]
>> [null, null, null, null, 1.3.6.1.2.1.31.1.1.1.14.774 = 2, 
>> 1.3.6.1.2.1.31.1.1.1.15.774 = 0, 1.3.6.1.2.1.31.1.1.1.18.774 = VLAN601]
>> [null, null, null, null, 1.3.6.1.2.1.31.1.1.1.14.783 = 2, 
>> 1.3.6.1.2.1.31.1.1.1.15.783 = 0, 1.3.6.1.2.1.31.1.1.1.18.783 = lab6]
>> [1.3.6.1.2.1.31.1.1.1.1.283 = VLAN110, 1.3.6.1.2.1.31.1.1.1.17.283 = 2, 
>> 1.3.6.1.2.1.31.1.1.1.6.283 = 0, 1.3.6.1.2.1.31.1.1.1.10.283 = 0, null, null, 
>> null]
>> [1.3.6.1.2.1.31.1.1.1.1.373 = VLAN200, 1.3.6.1.2.1.31.1.1.1.17.373 = 2, 
>> 1.3.6.1.2.1.31.1.1.1.6.373 = 0, 1.3.6.1.2.1.31.1.1.1.10.373 = 0, null, null, 
>> null]
>> [1.3.6.1.2.1.31.1.1.1.1.774 = VLAN601, 1.3.6.1.2.1.31.1.1.1.17.774 = 2, 
>> 1.3.6.1.2.1.31.1.1.1.6.774 = 0, 1.3.6.1.2.1.31.1.1.1.10.774 = 0, null, null, 
>> null]
>> [1.3.6.1.2.1.31.1.1.1.1.783 = VLAN610, 1.3.6.1.2.1.31.1.1.1.17.783 = 2, 
>> 1.3.6.1.2.1.31.1.1.1.6.783 = 0, 1.3.6.1.2.1.31.1.1.1.10.783 = 0, null, null, 
>> null]
>> [ ... everything normal ... ]
>> 
>> 
>> Here we find some rows split into two: One block with the first 4 columns 
>> set null, and another block with the last 3 columns set null.
>> 
>> 
>> Here's the setting which produces the second result:
>> 
>> - max-bindings is set to 4 - TableUtils.setMaxNumColumnsPerPDU(int)
>> - max-repetitions is set to 30 - TableUtils.setMaxNumRowsPerPDU(int)
>> - the device returns many rows (like 120)
>> - the table request contains more columns than max-bindings
>> - the table request contains not a multiple of max-bindings
>> - the problem will also depend on MTU size, but that's not important here
>> 
>> 
>> This is what happens:
>> 
>> 1. TableUtils will request the first 4 columns
>> 2. device returns 60 variable bindings, that's 15 cells per column
>> 3. TableUtils will request the latter 3 columns
>> 4. device returns 60 variable bindings, that's 20 cells per column
>> 
>> This is repeating until all bindings are retrieved. So far, so good. The 
>> problem is now, that all second requests (step 3) will receive more rows, 
>> and so these requests will reach index 283 (as in the example above) 
>> earlier. I d

Re: [SNMP4J] max-bindings with big tables

2018-07-05 Thread Frank Fock
Hi Steffen 
What SNMP4J version are you using?
Best regards 
Frank

> Am 05.07.2018 um 17:04 schrieb Steffen Brüntjen :
> 
> Hi Frank
> 
> I believe I found an issue in the TableUtils class. In certain scenarios, the 
> returned List from getTable(Target target, OID[] columnOIDs, OID 
> lowerBoundIndex, OID upperBoundIndex) will contain incomplete and duplicate 
> rows.
> 
> 
> Here's an extract of an exemplary List for a "good" result:
> 
> [1.3.6.1.2.1.31.1.1.1.1.278 = VLAN105, [...], 1.3.6.1.2.1.31.1.1.1.18.278 = 
> service]
> [1.3.6.1.2.1.31.1.1.1.1.279 = VLAN106, [...], 1.3.6.1.2.1.31.1.1.1.18.279 = 
> reception]
> [1.3.6.1.2.1.31.1.1.1.1.283 = VLAN110, [...], 1.3.6.1.2.1.31.1.1.1.18.283 = 
> voice]
> [1.3.6.1.2.1.31.1.1.1.1.373 = VLAN200, [...], 1.3.6.1.2.1.31.1.1.1.18.373 = 
> clients]
> [1.3.6.1.2.1.31.1.1.1.1.774 = VLAN601, [...], 1.3.6.1.2.1.31.1.1.1.18.774 = 
> VLAN601]
> [1.3.6.1.2.1.31.1.1.1.1.783 = VLAN610, [...], 1.3.6.1.2.1.31.1.1.1.18.783 = 
> lab6]
> 
> 
> But in some specific circumstances, I get results like these:
> 
> [ ... 75 normal rows ... ]
> [1.3.6.1.2.1.31.1.1.1.1.278 = VLAN105, [...], 1.3.6.1.2.1.31.1.1.1.18.278 = 
> service] 
> [1.3.6.1.2.1.31.1.1.1.1.279 = VLAN106, [...], 1.3.6.1.2.1.31.1.1.1.18.279 = 
> reception]
> [null, null, null, null, 1.3.6.1.2.1.31.1.1.1.14.283 = 2, 
> 1.3.6.1.2.1.31.1.1.1.15.283 = 0, 1.3.6.1.2.1.31.1.1.1.18.283 = voice]
> [null, null, null, null, 1.3.6.1.2.1.31.1.1.1.14.373 = 2, 
> 1.3.6.1.2.1.31.1.1.1.15.373 = 0, 1.3.6.1.2.1.31.1.1.1.18.373 = clients]
> [null, null, null, null, 1.3.6.1.2.1.31.1.1.1.14.774 = 2, 
> 1.3.6.1.2.1.31.1.1.1.15.774 = 0, 1.3.6.1.2.1.31.1.1.1.18.774 = VLAN601]
> [null, null, null, null, 1.3.6.1.2.1.31.1.1.1.14.783 = 2, 
> 1.3.6.1.2.1.31.1.1.1.15.783 = 0, 1.3.6.1.2.1.31.1.1.1.18.783 = lab6]
> [1.3.6.1.2.1.31.1.1.1.1.283 = VLAN110, 1.3.6.1.2.1.31.1.1.1.17.283 = 2, 
> 1.3.6.1.2.1.31.1.1.1.6.283 = 0, 1.3.6.1.2.1.31.1.1.1.10.283 = 0, null, null, 
> null]
> [1.3.6.1.2.1.31.1.1.1.1.373 = VLAN200, 1.3.6.1.2.1.31.1.1.1.17.373 = 2, 
> 1.3.6.1.2.1.31.1.1.1.6.373 = 0, 1.3.6.1.2.1.31.1.1.1.10.373 = 0, null, null, 
> null]
> [1.3.6.1.2.1.31.1.1.1.1.774 = VLAN601, 1.3.6.1.2.1.31.1.1.1.17.774 = 2, 
> 1.3.6.1.2.1.31.1.1.1.6.774 = 0, 1.3.6.1.2.1.31.1.1.1.10.774 = 0, null, null, 
> null]
> [1.3.6.1.2.1.31.1.1.1.1.783 = VLAN610, 1.3.6.1.2.1.31.1.1.1.17.783 = 2, 
> 1.3.6.1.2.1.31.1.1.1.6.783 = 0, 1.3.6.1.2.1.31.1.1.1.10.783 = 0, null, null, 
> null]
> [ ... everything normal ... ]
> 
> 
> Here we find some rows split into two: One block with the first 4 columns set 
> null, and another block with the last 3 columns set null.
> 
> 
> Here's the setting which produces the second result:
> 
> - max-bindings is set to 4 - TableUtils.setMaxNumColumnsPerPDU(int)
> - max-repetitions is set to 30 - TableUtils.setMaxNumRowsPerPDU(int)
> - the device returns many rows (like 120)
> - the table request contains more columns than max-bindings
> - the table request contains not a multiple of max-bindings
> - the problem will also depend on MTU size, but that's not important here
> 
> 
> This is what happens:
> 
> 1. TableUtils will request the first 4 columns
> 2. device returns 60 variable bindings, that's 15 cells per column
> 3. TableUtils will request the latter 3 columns
> 4. device returns 60 variable bindings, that's 20 cells per column
> 
> This is repeating until all bindings are retrieved. So far, so good. The 
> problem is now, that all second requests (step 3) will receive more rows, and 
> so these requests will reach index 283 (as in the example above) earlier. I 
> did some debugging and I think I found the reason: When the first results 
> with index 283 are received (step 3), TableUtils creates a row for this 
> index. That row is filled up with null values for the first 4 columns so that 
> it's size equals 7 (and not 3). Having size=7, the row is considered finished 
> too soon. TableUtils then prunes these incomplete but finished rows from 
> rowCache. When TableUtils receives the other 4 columns for row 283, it 
> creates a new row with the same index.
> 
> 
> How to fix?
> 
> I believe a moderately easy, but not very good way to fix this is to have the 
> little part contain the first 3 columns, not the remaining last 3 columns:
> 
> max-bindings = 4
> columns: .1, .2, .3, .4, .5, .6, .7
> 1. packet should contain: .1, .2, and .3
> 2. packet should contain: .4, .5, .6, and .7
> 
> Number of columns for the first packet is NumColumnsTotal % maxBindings.
> Number of columns for the other packets is maxBindings.
> 
> 
> Please tell me if you need more information or if my method invocation is 
> wrong.
> 
> 
> Best regards
> Steffen Brüntjen
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] SNMP4J CLT - compiling MIBs

2018-05-10 Thread Frank Fock
Hi Dave,

It is probably simpler than you image: You can use SNMP4J-CLT to compile a MIB 
file.
Run 

java -jar snmp4j-clt.jar -M  mib add  is a text file with one or more MIB module 
definitions.

 can be an empty directory, but is preferably the path to the 
“mibrespository” directory
That comes with the SNMP4J-CLT distribution ZIP.

Hope that helps.

Best regards,
Frank

> On 10. May 2018, at 18:08, David Artus  wrote:
> 
> Using the command line tool. I see the option
> 
> -MmibRepositoryPath Set the path to the MIB repository to be used
> to resolve
> object names (OIDs) and parse/format object values ('repository' is the
> default). The repository directory must contain compiled MIB modules files
> only.
> 
> What does a compiled MIB file look like? How do I make one?
> 
> I haven't found a utility to produce compiled files.
> 
> I can see SNMP4J classes for parsing a MIB, in effect compiling into
> memory, but haven't yet found anything for writing a file; anyway surely I
> don't need to write my own tool for this?
> 
> 
> 
> Thanks,
> 
> Dave
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


[SNMP4J] False positives reported by "OWASP Dependency check"

2018-04-26 Thread Frank Fock
Hi,

In the last days many question reached me about false positives reported by the 
OWASP Dependency check about SNMP4J libraries. The reports read as follows:

The snmp_pdu_parse function in snmp_api.c in net-snmp 5.7.2 and earlier does 
not remove the varBind variable in a netsnmp_variable_list item when parsing of 
the SNMP PDU fails, which allows remote attackers to cause a denial of service 
(crash) and possibly execute arbitrary code via a crafted packet.
CVSS:   7.5
URL:CVE-2015-5621
CWE:CWE-19 Data Handling

Those reports are FALSE positives and are completed unfounded!
A bug report for the OWASP Dependency Check tool has been created regarding 
this issue.

See also my statement in the SNMP4J FAQ at:
https://oosnmp.net/confluence/pages/viewpage.action?pageId=29720580 
<https://oosnmp.net/confluence/pages/viewpage.action?pageId=29720580>

Best regards,
Frank Fock





___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Using SNMP4J with logback

2018-04-12 Thread Frank Fock
Hi Debraj,

You can write your own LogAdapter and LogFactory implementation for logback.
That should be quite simple. You can start with the Log4JLogAdatper and 
Log4JLogFactory as example.

Best rergards,
Frank

> On 12. Apr 2018, at 12:37, Debraj Manna  wrote:
> 
> Cross-posting from stackoverflow
> 
> 
> We are using SLF4J and logback in our application code and SNMP4J has log4j
> as dependency.
> 
> Can someone let me know how can I make SNMP4J work with logback?
> 
> Version
> 
>   - SNMP4J - 2.4.3
>   - Logback - 1.2.3
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Timeouts in version 2.5.7+

2018-04-12 Thread Frank Fock
Hi Steffen,

That was probably too fast :-(. I made an error when merging from master branch 
to the 2.x release
which introduced the bug you mentioned below by three way merging some testing 
modifications into it. 
In the master branch the code was/is correct.
I will create a 2.6.2 version that fixes that. 

Best regards,
Frank  

> On 12. Apr 2018, at 19:04, Steffen Brüntjen <steffen.bruent...@macmon.eu> 
> wrote:
> 
> Hi Frank,
> 
> that was fast! I've started running tests with the new version and until now 
> it is working well. I reviewed the code change and I think, it works, but 
> there's a minor bug:
> 
> In my opinion, it should be "if (tm.isIdle())", not "if (!tm.isIdle())" in 
> line 108.
> 
> Also I'm not sure whether the loop in the synchronized block is helpful. You 
> should maybe rather do something like this:
> 
>  synchronized (this) {
>// check again to avoid race conditions with the notify of the task 
> manager
>for (TaskManager tm : taskManagers) {
>  if (!tm.isIdle()) {
>tm.execute(task);
>return;
>  }
>}
>try {
>  wait(taskManagersBusyTimeoutMillis);
>} catch (InterruptedException ex) {
>  handleInterruptedExceptionOnExecute(ex, task);
>}
>  }
> 
> 
> Because now a WorkerTask could run into the synchronized block, finds a 
> taskManager to be idle, then runs through the taskManagers (third time) and 
> may find all taskManagers busy again.
> 
> Thank you for your very quick fix!
> 
> Best regards,
> Steffen Brüntjen
> 
> 
> -Original Message-
> From: Frank Fock [mailto:f...@agentpp.com] 
> Sent: Dienstag, 10. April 2018 17:25
> To: Steffen Brüntjen <steffen.bruent...@macmon.eu>
> Cc: snmp4j@agentpp.org
> Subject: Re: [SNMP4J] Timeouts in version 2.5.7+
> 
> Hi Steffen,
> 
> OK, many thanks for helping sorting this out. I support your analysis and 
> will provide a fix a soon as possible.
> 
> Best regards,
> Frank
> 
>> On 10. Apr 2018, at 12:26, Steffen Brüntjen <steffen.bruent...@macmon.eu> 
>> wrote:
>> 
>> Hi Frank
>> 
>> 
>> I know that remote troubleshooting is annoying; that's why I was trying to 
>> provide as many details as possible. Anyways, with your last hint we're 
>> getting there! The while loop you mentioned is not exited, we can see that 
>> in the stack traces. Actually, the DefaultUDPTransportMapping thread remains 
>> forever in this state:
>> 
>> "DefaultUDPTransportMapping_0.0.0.0/0" #35 daemon prio=5 os_prio=0 
>> tid=0x7f6829984800 nid=0x2a6d in Object.wait() [0x7f67936fd000]
>>  java.lang.Thread.State: WAITING (on object monitor)
>>   at java.lang.Object.wait(Native Method)
>>   at java.lang.Object.wait(Object.java:502)
>>   at org.snmp4j.util.ThreadPool.execute(ThreadPool.java:103)
>>   - locked <0x88818548> (a org.snmp4j.util.ThreadPool)
>>   at 
>> org.snmp4j.util.MultiThreadedMessageDispatcher.processMessage(MultiThreadedMessageDispatcher.java:162)
>>   at 
>> org.snmp4j.transport.AbstractTransportMapping.fireProcessMessage(AbstractTransportMapping.java:76)
>>   at 
>> org.snmp4j.transport.DefaultUdpTransportMapping$ListenThread.run(DefaultUdpTransportMapping.java:430)
>>   at java.lang.Thread.run(Thread.java:745)
>> 
>> 
>> It is waiting for a notify that never comes:
>> 
>> synchronized (this) {
>>   try {
>> wait(); // line 103
>>   } catch (InterruptedException ex) {
>> handleInterruptedExceptionOnExecute(ex, task);
>>   }
>> 
>> 
>> I guess, here's a timing problem. Suppose, in this piece of code,
>> 
>> public void execute(WorkerTask task) {
>>   while (true) {
>> for (int i=0; i<taskManagers.size(); i++) {
>>   TaskManager tm = taskManagers.get(i);
>>   if ((respawnThreads) && (!tm.isAlive())) {
>> tm = new TaskManager(getTaskManagerName(name, i));
>> taskManagers.set(i, tm);
>>   }
>>   if (tm.isIdle()) {
>> try {
>>   tm.execute(task);
>>   return;
>> }
>> catch (IllegalStateException isex) {
>>   // ignore
>> }
>>   }
>> }
>> synchronized (this) {
>>   try {
>> wait();
>>   } catch (InterruptedException ex) {
>> handleInterruptedExceptionOnExecute(ex, task);
>>   }
>> 

Re: [SNMP4J] Timeouts in version 2.5.7+

2018-04-10 Thread Frank Fock
Hi Steffen,

OK, many thanks for helping sorting this out. I support your analysis and will 
provide a fix a soon as possible.

Best regards,
Frank

> On 10. Apr 2018, at 12:26, Steffen Brüntjen <steffen.bruent...@macmon.eu> 
> wrote:
> 
> Hi Frank
> 
> 
> I know that remote troubleshooting is annoying; that's why I was trying to 
> provide as many details as possible. Anyways, with your last hint we're 
> getting there! The while loop you mentioned is not exited, we can see that in 
> the stack traces. Actually, the DefaultUDPTransportMapping thread remains 
> forever in this state:
> 
> "DefaultUDPTransportMapping_0.0.0.0/0" #35 daemon prio=5 os_prio=0 
> tid=0x7f6829984800 nid=0x2a6d in Object.wait() [0x7f67936fd000]
>   java.lang.Thread.State: WAITING (on object monitor)
>at java.lang.Object.wait(Native Method)
>at java.lang.Object.wait(Object.java:502)
>at org.snmp4j.util.ThreadPool.execute(ThreadPool.java:103)
>- locked <0x88818548> (a org.snmp4j.util.ThreadPool)
>at 
> org.snmp4j.util.MultiThreadedMessageDispatcher.processMessage(MultiThreadedMessageDispatcher.java:162)
>at 
> org.snmp4j.transport.AbstractTransportMapping.fireProcessMessage(AbstractTransportMapping.java:76)
>at 
> org.snmp4j.transport.DefaultUdpTransportMapping$ListenThread.run(DefaultUdpTransportMapping.java:430)
>at java.lang.Thread.run(Thread.java:745)
> 
> 
> It is waiting for a notify that never comes:
> 
>  synchronized (this) {
>try {
>  wait(); // line 103
>} catch (InterruptedException ex) {
>  handleInterruptedExceptionOnExecute(ex, task);
>}
> 
> 
> I guess, here's a timing problem. Suppose, in this piece of code,
> 
>  public void execute(WorkerTask task) {
>while (true) {
>  for (int i=0; i<taskManagers.size(); i++) {
>TaskManager tm = taskManagers.get(i);
>if ((respawnThreads) && (!tm.isAlive())) {
>  tm = new TaskManager(getTaskManagerName(name, i));
>  taskManagers.set(i, tm);
>}
>if (tm.isIdle()) {
>  try {
>tm.execute(task);
>return;
>  }
>  catch (IllegalStateException isex) {
>// ignore
>  }
>}
>  }
>  synchronized (this) {
>try {
>  wait();
>} catch (InterruptedException ex) {
>  handleInterruptedExceptionOnExecute(ex, task);
>}
>  }
>}
>  }
> 
> 
> tm.isIdle() returns false for all task managers, because they are all 
> working. In that case, the thread would start waiting for a notify by any of 
> the task managers. Suppose moreover, the notify actually came from all 
> running task managers right before this thread entered waiting status. 
> execute() wouldn't return, in fact it would stay in line 103 (SNMP4J-2.5.7), 
> and that's exactly what we can see in the stacktrace. In version 2.5.6, 
> notify could not happen between tm.isIdle() and wait() because execute() was 
> synchronized.
> 
> 
> Best regards,
> Steffen Brüntjen
> 
> 
> 
> -Original Message-
> From: Frank Fock [mailto:f...@agentpp.com] 
> Sent: Montag, 9. April 2018 20:59
> To: Steffen Brüntjen <steffen.bruent...@macmon.eu>
> Cc: snmp4j@agentpp.org
> Subject: Re: [SNMP4J] Timeouts in version 2.5.7+
> 
> Hi Steffen,
> 
> I understood the problem very well, but I am trying to find a possible cause.
> In past, users have chosen a very low timeout because it worked - the 
> system(s) answered very fast and SNMP4J timeout mechanism was not fast enough 
> to timeout the request although the timeout value was lower than the 
> effective response time. 
> 
> This behaviour then changed by some other timing side effect and all answers 
> were timed out then. 
> I just wanted to sort this out, but you did not provide your timeout value 
> though. 
> 
> As supporter it is very difficult to operate with too few facts. 
> 
> As you can see from the following code of the DefaultUdpTransportMapping 
> class, the “Received…” log message must be printed out if something was 
> received from the UDP port:
> 
> public void run() {
>  DatagramSocket socketCopy = socket;
>  if (socketCopy != null) {
>try {
>  socketCopy.setSoTimeout(getSocketTimeout());
>  if (receiveBufferSize > 0) {
>socketCopy.setReceiveBufferSize(Math.max(receiveBufferSize,
>maxInboundMessageSize));
>  }
>  if (logger.isDebugEnabled()) {
>logger.debug("UDP receive

Re: [SNMP4J] Timeouts in version 2.5.7+

2018-04-09 Thread Frank Fock
. Apr 2018, at 15:19, Steffen Brüntjen <steffen.bruent...@macmon.eu> 
> wrote:
> 
> Hi!
> 
>> Is your timeout value big enough?
> 
> It seems I couldn't make the problem clear, so once again from the beginning. 
> I've been sending millions of millions SNMP queries over a long time, like 
> months, with no problems. Then I replaced SNMP4J version 2.5.6 with version 
> 2.5.7 (it can be any other newer release) and restarted the program. The 
> program starts running fine again, but only for some comparatively short 
> amount of time (sometimes 10 minutes, sometimes 2 days). From the moment on, 
> when the problem arises, NO more SNMP packets are received at all. There's 
> not a single SNMP request that results in something else but a timeout. I 
> made no configuration changes like timeouts/retries, no changes in the 
> network, none of the 200 devices change and no one has access to the machine. 
> Consequently, when I restart the program, it runs fine again. So I bet a too 
> low timeout can't be the problem. As an example here's my last test. I 
> extracted all data from SNMP4J log messages:
> 
> 2018-04-05 10:43 Program starts
> 2018-04-05 10:43 First outgoing SNMP request
> 2018-04-05 22:23 Last incoming message
> 2018-04-09 . Program is still running (until today)
> 
> 4,994,621 sent messages from 2018-04-05 10:43 to 22:23
> 4,992,120 received msgs from 2018-04-05 10:43 to 22:23
>   53,323 sent messages from 2018-04-05 22:23 to now
>0 received msgs from 2018-04-05 22:23 to now
> 
> (The different number of outgoing requests per amount of time comes from the 
> fact I wrote in my first mail: The program queries the sysObjectId and then - 
> if successful - more OIDs. If the sysObjectId can't be queried, the rest of 
> communication doesn't take place.)
> 
> 
>> I do not see any differences in the stacktraces, do I miss something?
> 
> In your last mail you wrote, that "From the stack trace it seems that there 
> is no idle TaskManager in your ThreadPool for the 
> MultiThreadMessageDispatcher left.". So with the two identical stack traces I 
> was trying to point out that there's no indication of a missing TaskManager 
> thread.
> 
> 
> Best regards and thanks,
> Steffen Brüntjen
> 
> 
> 
> 
> -Original Message-
> From: Frank Fock [mailto:f...@agentpp.com] 
> Sent: Freitag, 6. April 2018 15:40
> To: Steffen Brüntjen <steffen.bruent...@macmon.eu>
> Cc: snmp4j@agentpp.org
> Subject: Re: [SNMP4J] Timeouts in version 2.5.7+
> 
> Is your timeout value big enough?
> I do not see any differences in the stacktraces, do I miss something?
> 
> 
>> Am 06.04.2018 um 14:15 schrieb Steffen Brüntjen 
>> <steffen.bruent...@macmon.eu>:
>> 
>> Hi Frank
>> 
>> Mmh, I don't think it's because of uncaught exceptions (at least not outside 
>> of SNMP4J). SNMP packets are continued to be sent out normally, the 
>> responses are received by kernel but not "recognized" by SNMP4J (see tcpdump 
>> output). I get normal timeouts as if the devices wouldn't respond any more 
>> (but they do). I reproduced the problem once again with TRACE logging 
>> enabled. The SNMP4J logs appear to be very normal, except that there are no 
>> more "Received message from ... with length ...: ..." messages any more 
>> (DefaultUdpTransportMapping.java:409). Here are the different types of log 
>> messages after problem occurs (in random order):
>> 
>> Sending message to .../161 with length 43: ... | 
>> (DefaultUdpTransportMapping.java:112)
>> Removed pending request with handle: PduHandle[...] | (Snmp.java:995)
>> Request timed out: ... | (Snmp.java:1900)
>> Running pending sync request with handle PduHandle[...] and retry count left 
>> 1 | (Snmp.java:1808)
>> 
>> 
>> The stacktraces look the same when everything is running fine:
>> 
>> "snmp.3" #39 prio=5 os_prio=0 tid=0x7f682a81a000 nid=0x2a71 in 
>> Object.wait() [0x7f67932f9000]
>>  java.lang.Thread.State: WAITING (on object monitor)
>>   at java.lang.Object.wait(Native Method)
>>   at java.lang.Object.wait(Object.java:502)
>>   at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>>   - locked <0x88861810> (a org.snmp4j.util.ThreadPool$TaskManager)
>> 
>> "snmp.2" #38 prio=5 os_prio=0 tid=0x7f682a818000 nid=0x2a70 in 
>> Object.wait() [0x7f67933fa000]
>>  java.lang.Thread.State: WAITING (on object monitor)
>>   at java.lang.Object.wait(Native Method)
>>   at java.lang.Object.wait(Object.java:502)
>>   at org.snmp4j.util.ThreadPool$TaskMa

Re: [SNMP4J] Timeouts in version 2.5.7+

2018-04-06 Thread Frank Fock
Is your timeout value big enough?
I do not see any differences in the stacktraces, do I miss something?


> Am 06.04.2018 um 14:15 schrieb Steffen Brüntjen <steffen.bruent...@macmon.eu>:
> 
> Hi Frank
> 
> Mmh, I don't think it's because of uncaught exceptions (at least not outside 
> of SNMP4J). SNMP packets are continued to be sent out normally, the responses 
> are received by kernel but not "recognized" by SNMP4J (see tcpdump output). I 
> get normal timeouts as if the devices wouldn't respond any more (but they 
> do). I reproduced the problem once again with TRACE logging enabled. The 
> SNMP4J logs appear to be very normal, except that there are no more "Received 
> message from ... with length ...: ..." messages any more 
> (DefaultUdpTransportMapping.java:409). Here are the different types of log 
> messages after problem occurs (in random order):
> 
> Sending message to .../161 with length 43: ... | 
> (DefaultUdpTransportMapping.java:112)
> Removed pending request with handle: PduHandle[...] | (Snmp.java:995)
> Request timed out: ... | (Snmp.java:1900)
> Running pending sync request with handle PduHandle[...] and retry count left 
> 1 | (Snmp.java:1808)
> 
> 
> The stacktraces look the same when everything is running fine:
> 
> "snmp.3" #39 prio=5 os_prio=0 tid=0x7f682a81a000 nid=0x2a71 in 
> Object.wait() [0x7f67932f9000]
>   java.lang.Thread.State: WAITING (on object monitor)
>at java.lang.Object.wait(Native Method)
>at java.lang.Object.wait(Object.java:502)
>at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>- locked <0x88861810> (a org.snmp4j.util.ThreadPool$TaskManager)
> 
> "snmp.2" #38 prio=5 os_prio=0 tid=0x7f682a818000 nid=0x2a70 in 
> Object.wait() [0x7f67933fa000]
>   java.lang.Thread.State: WAITING (on object monitor)
>at java.lang.Object.wait(Native Method)
>at java.lang.Object.wait(Object.java:502)
>at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>- locked <0x88861a20> (a org.snmp4j.util.ThreadPool$TaskManager)
> 
> "snmp.1" #37 prio=5 os_prio=0 tid=0x7f6829986800 nid=0x2a6f in 
> Object.wait() [0x7f67934fb000]
>   java.lang.Thread.State: WAITING (on object monitor)
>at java.lang.Object.wait(Native Method)
>at java.lang.Object.wait(Object.java:502)
>at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>- locked <0x88861c30> (a org.snmp4j.util.ThreadPool$TaskManager)
> 
> "snmp.0" #36 prio=5 os_prio=0 tid=0x7f6829988800 nid=0x2a6e in 
> Object.wait() [0x7f67935fc000]
>   java.lang.Thread.State: WAITING (on object monitor)
>at java.lang.Object.wait(Native Method)
>at java.lang.Object.wait(Object.java:502)
>at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>- locked <0x88861e40> (a org.snmp4j.util.ThreadPool$TaskManager)
> 
> 
> Here are the stacktraces after problem starts:
> 
> "snmp.3" #39 prio=5 os_prio=0 tid=0x7f682a81a000 nid=0x2a71 in 
> Object.wait() [0x7f67932f9000]
>   java.lang.Thread.State: WAITING (on object monitor)
>at java.lang.Object.wait(Native Method)
>at java.lang.Object.wait(Object.java:502)
>at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>- locked <0x888185a0> (a org.snmp4j.util.ThreadPool$TaskManager)
> 
> "snmp.2" #38 prio=5 os_prio=0 tid=0x7f682a818000 nid=0x2a70 in 
> Object.wait() [0x7f67933fa000]
>   java.lang.Thread.State: WAITING (on object monitor)
>at java.lang.Object.wait(Native Method)
>at java.lang.Object.wait(Object.java:502)
>at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>- locked <0x888187b0> (a org.snmp4j.util.ThreadPool$TaskManager)
> 
> "snmp.1" #37 prio=5 os_prio=0 tid=0x7f6829986800 nid=0x2a6f in 
> Object.wait() [0x7f67934fb000]
>   java.lang.Thread.State: WAITING (on object monitor)
>at java.lang.Object.wait(Native Method)
>at java.lang.Object.wait(Object.java:502)
>at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>- locked <0x888189c0> (a org.snmp4j.util.ThreadPool$TaskManager)
> 
> "snmp.0" #36 prio=5 os_prio=0 tid=0x7f6829988800 nid=0x2a6e in 
> Object.wait() [0x7f67935fc000]
>   java.lang.Thread.State: WAITING (on object monitor)
>at java.lang.Object.wait(Native Method)
>at java.lang.Object.wait(Object.java:502)
>at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>- locked <0x88818bd0> (a org.snmp4j.uti

Re: [SNMP4J] Timeouts in version 2.5.7+

2018-04-03 Thread Frank Fock
Hi Steffen,

From the stack trace it seems that there is no idle TaskManager in your 
ThreadPool for the MultiThreadMessageDispatcher left.
Maybe all TaskManagers died because of exceptions?

You can simply use the DefaultMessageDispatcher in your case. I do not expect 
advantages from the multi-threaded variant. Maybe you can find the root cause 
easier with the simple message dispatcher.

Best regards,
Frank 


> On 3. Apr 2018, at 13:26, Steffen Brüntjen <steffen.bruent...@macmon.eu> 
> wrote:
> 
> Hi Frank
> 
> 
> Thanks for your reply. I don't reuse PDUs. In case of SNMPv2c, the effective 
> statements would be:
> 
>  PDU pdu = new PDU();
>  pdu.setType(PDU.GET);
>  pdu.add(new VariableBinding(...));
>  ResponseEvent responseEvent = snmp.send(pdu, target); // timeout
> 
> I believe the PDU request IDs will be coming from this code in 
> MessageDispatcherImpl:
> 
>  protected PduHandle createPduHandle() {
>return new PduHandle(getNextRequestID());
>  }
> 
> 
> There's only one static snmp instance for all targets, I read somewhere that 
> this is the preferred implementation.
> 
> 
> I'am also able to remote debug the program, but I wouldn't know where to look 
> at. Also, it's a bit of extra work and it will take a while, but it's 
> possible.
> 
> 
> Best regards,
> Steffen
> 
> 
> -Original Message-
> From: Frank Fock [mailto:f...@agentpp.com] 
> Sent: Sonntag, 1. April 2018 08:23
> To: Steffen Brüntjen <steffen.bruent...@macmon.eu>
> Cc: snmp4j@agentpp.org
> Subject: Re: [SNMP4J] Timeouts in version 2.5.7+
> 
> Hi Steffen,
> 
> There was no change on the DefaultUdpTransportMapping between 2.5.6 and 
> 2.5.7, thus I assume that behaviour change is a side effect of some other 
> changes. SNMP4J is no a bit faster.
> Have you checked your code for race conditions?
> When you use Snmp.send, how do you create the request IDs of the PDUs? 
> 
> Also reusing the PDU objects before the request is finished might cause this 
> issue. 
> 
> Best regards,
> Frank  
> 
>> On 16. Mar 2018, at 12:14, Steffen Brüntjen <steffen.bruent...@macmon.eu> 
>> wrote:
>> 
>> Hi!
>> 
>> I'm using SNMP4J for monitoring around 200 devices. It has been running 
>> stably for months. Now I found a problem in the latest releases: When my 
>> process runs for a couple of hours (sometimes days), after some time SNMP4J 
>> returns nothing but timeouts. My program initially uses Snmp.send() and 
>> TableUtils (I think, this doesn't matter). After the problem shows up once, 
>> all my program effectively does is querying the SysObjectIds (because this 
>> already results in timeouts):
>> 
>>   org.snmp4j.Snmp.send(get(SnmpV2Mib.sysObjectID), target)
>> 
>> 
>> Some of the targets are community targets, some are user targets, but I get 
>> timeouts for all devices. I repeated testing with only community targets 
>> resulting in the same behavior. I tracked down the problem to release 2.5.7. 
>> The previous version 2.5.6 works without problems, all releases starting 
>> with 2.5.7 show the problem. I also analyzed the SNMP packages using 
>> tcpdump. The devices send their answers quickly, the packets don't look any 
>> special. It seems that SNMP4J doesn't receive, recognize or process the UDP 
>> packets.
>> 
>> Can you reproduce the problem? Does anyone see problems in source code 
>> changes from 2.5.6 to 2.5.7?
>> 
>> Best regards
>> Steffen Brüntjen
>> 
>> 
>> 
>> Here are some stacktraces at the time the problem exists:
>> 
>> "DefaultUDPTransportMapping_0.0.0.0/162" #72 daemon prio=5 os_prio=0 
>> tid=0x7fa0ac00a000 nid=0x4433 runnable [0x7fa08b4f3000]
>>  java.lang.Thread.State: RUNNABLE
>>  at java.net.PlainDatagramSocketImpl.receive0(Native Method)
>>  - locked <0x89977c28> (a java.net.PlainDatagramSocketImpl)
>>  at 
>> java.net.AbstractPlainDatagramSocketImpl.receive(AbstractPlainDatagramSocketImpl.java:143)
>>  - locked <0x89977c28> (a java.net.PlainDatagramSocketImpl)
>>  at java.net.DatagramSocket.receive(DatagramSocket.java:812)
>>  - locked <0x89b2b3a8> (a java.net.DatagramPacket)
>>  - locked <0x89977c78> (a java.net.DatagramSocket)
>>  at 
>> org.snmp4j.transport.DefaultUdpTransportMapping$ListenThread.run(DefaultUdpTransportMapping.java:397)
>>  at java.lang.Thread.run(Thread.java:745)
>> 
>> "DefaultUDPTransportMapping_0.0.0.0/0" #33 daemon prio=5 os_prio=0 
>> tid=0x7fa126c

Re: [SNMP4J] Timeouts in version 2.5.7+

2018-04-01 Thread Frank Fock
Hi Steffen,

There was no change on the DefaultUdpTransportMapping between 2.5.6 and 2.5.7, 
thus I assume that behaviour change is a side effect of some other changes. 
SNMP4J is no a bit faster.
Have you checked your code for race conditions?
When you use Snmp.send, how do you create the request IDs of the PDUs? 

Also reusing the PDU objects before the request is finished might cause this 
issue. 

Best regards,
Frank  

> On 16. Mar 2018, at 12:14, Steffen Brüntjen  
> wrote:
> 
> Hi!
> 
> I'm using SNMP4J for monitoring around 200 devices. It has been running 
> stably for months. Now I found a problem in the latest releases: When my 
> process runs for a couple of hours (sometimes days), after some time SNMP4J 
> returns nothing but timeouts. My program initially uses Snmp.send() and 
> TableUtils (I think, this doesn't matter). After the problem shows up once, 
> all my program effectively does is querying the SysObjectIds (because this 
> already results in timeouts):
> 
>org.snmp4j.Snmp.send(get(SnmpV2Mib.sysObjectID), target)
> 
> 
> Some of the targets are community targets, some are user targets, but I get 
> timeouts for all devices. I repeated testing with only community targets 
> resulting in the same behavior. I tracked down the problem to release 2.5.7. 
> The previous version 2.5.6 works without problems, all releases starting with 
> 2.5.7 show the problem. I also analyzed the SNMP packages using tcpdump. The 
> devices send their answers quickly, the packets don't look any special. It 
> seems that SNMP4J doesn't receive, recognize or process the UDP packets.
> 
> Can you reproduce the problem? Does anyone see problems in source code 
> changes from 2.5.6 to 2.5.7?
> 
> Best regards
> Steffen Brüntjen
> 
> 
> 
> Here are some stacktraces at the time the problem exists:
> 
> "DefaultUDPTransportMapping_0.0.0.0/162" #72 daemon prio=5 os_prio=0 
> tid=0x7fa0ac00a000 nid=0x4433 runnable [0x7fa08b4f3000]
>   java.lang.Thread.State: RUNNABLE
>   at java.net.PlainDatagramSocketImpl.receive0(Native Method)
>   - locked <0x89977c28> (a java.net.PlainDatagramSocketImpl)
>   at 
> java.net.AbstractPlainDatagramSocketImpl.receive(AbstractPlainDatagramSocketImpl.java:143)
>   - locked <0x89977c28> (a java.net.PlainDatagramSocketImpl)
>   at java.net.DatagramSocket.receive(DatagramSocket.java:812)
>   - locked <0x89b2b3a8> (a java.net.DatagramPacket)
>   - locked <0x89977c78> (a java.net.DatagramSocket)
>   at 
> org.snmp4j.transport.DefaultUdpTransportMapping$ListenThread.run(DefaultUdpTransportMapping.java:397)
>   at java.lang.Thread.run(Thread.java:745)
> 
> "DefaultUDPTransportMapping_0.0.0.0/0" #33 daemon prio=5 os_prio=0 
> tid=0x7fa126c9d800 nid=0x440c in Object.wait() [0x7fa0b60f1000]
>   java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.snmp4j.util.ThreadPool.execute(ThreadPool.java:103)
>   - locked <0x883cde50> (a org.snmp4j.util.ThreadPool)
>   at 
> org.snmp4j.util.MultiThreadedMessageDispatcher.processMessage(MultiThreadedMessageDispatcher.java:162)
>   at 
> org.snmp4j.transport.AbstractTransportMapping.fireProcessMessage(AbstractTransportMapping.java:76)
>   at 
> org.snmp4j.transport.DefaultUdpTransportMapping$ListenThread.run(DefaultUdpTransportMapping.java:430)
>   at java.lang.Thread.run(Thread.java:745)
> 
> "snmp.3" #37 prio=5 os_prio=0 tid=0x7fa125a38000 nid=0x4410 in 
> Object.wait() [0x7fa0b5ced000]
>   java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>   - locked <0x883ddeb8> (a org.snmp4j.util.ThreadPool$TaskManager)
> 
> "snmp.2" #36 prio=5 os_prio=0 tid=0x7fa126ca1800 nid=0x440f in 
> Object.wait() [0x7fa0b5dee000]
>   java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>   - locked <0x883de0c8> (a org.snmp4j.util.ThreadPool$TaskManager)
> 
> "snmp.1" #35 prio=5 os_prio=0 tid=0x7fa126ca0800 nid=0x440e in 
> Object.wait() [0x7fa0b5eef000]
>   java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>   - locked <0x883de2d8> (a org.snmp4j.util.ThreadPool$TaskManager)
> 
> "snmp.0" #34 prio=5 os_prio=0 tid=0x7fa126ca nid=0x440d in 
> Object.wait() [0x7fa0b5ff]
>   java.lang.Thread.State: WAITING (on object monitor)
>   at 

Re: [SNMP4J] Possible concurrency bug in snmp4j ?

2018-02-14 Thread Frank Fock
2.6.0 will be released next week. 

> Am 13.02.2018 um 18:15 schrieb Maayan, Elhanan <elhanan.maa...@sbdinc.com>:
> 
> Thanks, do you have any timeline regarding 2.6?
>  
> From: Frank Fock [mailto:f...@agentpp.com] 
> Sent: Tuesday, February 13, 2018 7:15 PM
> To: Maayan, Elhanan <elhanan.maa...@sbdinc.com>
> Cc: snmp4j@agentpp.org
> Subject: Re: [SNMP4J] Possible concurrency bug in snmp4j ?
>  
> *External Message, please be cautious.*
> 2.5.11 might already solve the problem, that depends on your usage profile.
> The work around would be to apply the 2.6.0 DefaultTcpMapping sources to your 
> version, if you do not like to use/wait for that version.
>  
> 
> 
> On 13. Feb 2018, at 10:53, Maayan, Elhanan <elhanan.maa...@sbdinc.com> wrote:
>  
> so 2.5.11 won't help? Any workaround?
> 
> Get Outlook for Android
>  
> From: Frank Fock <f...@agentpp.com>
> Sent: Tuesday, February 13, 2018 11:51:23 AM
> To: Maayan, Elhanan
> Cc: snmp4j@agentpp.org
> Subject: Re: [SNMP4J] Possible concurrency bug in snmp4j ?
>  
> *External Message, please be cautious.*
> 
> The immediate reconnection issue (TCP) to the same address and port (SFJ-164) 
> has been fixed in SNMP4J 2.6.0 which is available as SNAPSHOT. 
> 
> See also the mailing list archive around January 27th. 
> 
> The ticket system is available for users with support contract.
> 
> Best regards,
> Frank 
> 
> > On 12. Feb 2018, at 19:53, Maayan, Elhanan <elhanan.maa...@sbdinc.com> 
> > wrote:
> > 
> > Thanks, I'll try that , I'm trying to access the bug system, but I can't 
> > find it
> > 
> > The real issue I'm encountering which I don't know the cause is that the 
> > snmp4j tries to send messages, trying to connect , but simply doesn't, I 
> > did a thread dump and it seems to be stuck on the select method no matter 
> > what
> > 
> > "DefaultTCPTransportMapping_192.168.60.80/0" #75906 daemon prio=5 os_prio=0 
> > tid=0x7f4748e75000 nid=0x79e5 runnable [0x7f4733768000]
> >   java.lang.Thread.State: RUNNABLE
> >at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> >at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> >at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> >at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> >- locked <0x0007042019f8> (a sun.nio.ch.Util$3)
> >- locked <0x0007042019e8> (a 
> > java.util.Collections$UnmodifiableSet)
> >- locked <0x000704201a08> (a sun.nio.ch.EPollSelectorImpl)
> >at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> >at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> >at 
> > org.snmp4j.transport.DefaultTcpTransportMapping$ServerThread.run(DefaultTcpTransportMapping.java:786)
> >at java.lang.Thread.run(Thread.java:745)
> > 
> > there's nothing on tcpdump, using a separate snmp4j on shell on the same 
> > machine is able to connect to the same remote machine, 
> > 
> > but still:
> > 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Looking up 
> > connection for destination '192.168.56.1/162' returned: 
> > SocketEntry[peerAddress=192.168.56.1/162,socket=Socket[unconnected],lastUse=Mon
> >  Mar 09 07:06:25 IST 1970,readBufferPosition=-1]
> > 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - 
> > {192.168.56.1/162=SocketEntry[peerAddress=192.168.56.1/162,socket=Socket[unconnected],lastUse=Mon
> >  Mar 09 07:06:25 IST 1970,readBufferPosition=-1]}
> > 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Socket for 
> > address '192.168.56.1/162' is closed, opening it...
> > 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Trying to 
> > connect to 192.168.56.1/162
> > 
> > 
> > I see that "trying to connect to" is invoked the wakeup, so that must means 
> > the .select is released, but returns no keys, can there be any reason for 
> > that? 
> > 
> > 
> > 
> > 
> > -Original Message-
> > From: Frank Fock [mailto:f...@agentpp.com] 
> > Sent: Monday, February 12, 2018 8:45 PM
> > To: Maayan, Elhanan <elhanan.maa...@sbdinc.com>
> > Cc: snmp4j@agentpp.org
> > Subject: Re: [SNMP4J] Possible concurrency bug in snmp4j ?
> > 
> > *External Message, please be cautious.*
> > 
> > Hi Elhanan,
> > 
> > Please upgrade to SNMP4J 2.5.11 to fix this issue.
> > 
> > Best regards 
> > Frank
> > 
> >> Am 12.02.2018 

Re: [SNMP4J] Possible concurrency bug in snmp4j ?

2018-02-13 Thread Frank Fock
2.5.11 might already solve the problem, that depends on your usage profile.
The work around would be to apply the 2.6.0 DefaultTcpMapping sources to your 
version, if you do not like to use/wait for that version.


> On 13. Feb 2018, at 10:53, Maayan, Elhanan <elhanan.maa...@sbdinc.com> wrote:
> 
> so 2.5.11 won't help? Any workaround?
> 
> Get Outlook for Android <https://aka.ms/ghei36>
> From: Frank Fock <f...@agentpp.com <mailto:f...@agentpp.com>>
> Sent: Tuesday, February 13, 2018 11:51:23 AM
> To: Maayan, Elhanan
> Cc: snmp4j@agentpp.org <mailto:snmp4j@agentpp.org>
> Subject: Re: [SNMP4J] Possible concurrency bug in snmp4j ?
>  
> *External Message, please be cautious.*
> 
> The immediate reconnection issue (TCP) to the same address and port (SFJ-164) 
> has been fixed in SNMP4J 2.6.0 which is available as SNAPSHOT. 
> 
> See also the mailing list archive around January 27th. 
> 
> The ticket system is available for users with support contract.
> 
> Best regards,
> Frank 
> 
> > On 12. Feb 2018, at 19:53, Maayan, Elhanan <elhanan.maa...@sbdinc.com> 
> > wrote:
> > 
> > Thanks, I'll try that , I'm trying to access the bug system, but I can't 
> > find it
> > 
> > The real issue I'm encountering which I don't know the cause is that the 
> > snmp4j tries to send messages, trying to connect , but simply doesn't, I 
> > did a thread dump and it seems to be stuck on the select method no matter 
> > what
> > 
> > "DefaultTCPTransportMapping_192.168.60.80/0" #75906 daemon prio=5 os_prio=0 
> > tid=0x7f4748e75000 nid=0x79e5 runnable [0x7f4733768000]
> >   java.lang.Thread.State: RUNNABLE
> >at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> >at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> >at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> >at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> >- locked <0x0007042019f8> (a sun.nio.ch.Util$3)
> >- locked <0x0007042019e8> (a 
> > java.util.Collections$UnmodifiableSet)
> >- locked <0x000704201a08> (a sun.nio.ch.EPollSelectorImpl)
> >at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> >at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> >at 
> > org.snmp4j.transport.DefaultTcpTransportMapping$ServerThread.run(DefaultTcpTransportMapping.java:786)
> >at java.lang.Thread.run(Thread.java:745)
> > 
> > there's nothing on tcpdump, using a separate snmp4j on shell on the same 
> > machine is able to connect to the same remote machine, 
> > 
> > but still:
> > 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Looking up 
> > connection for destination '192.168.56.1/162' returned: 
> > SocketEntry[peerAddress=192.168.56.1/162,socket=Socket[unconnected],lastUse=Mon
> >  Mar 09 07:06:25 IST 1970,readBufferPosition=-1]
> > 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - 
> > {192.168.56.1/162=SocketEntry[peerAddress=192.168.56.1/162,socket=Socket[unconnected],lastUse=Mon
> >  Mar 09 07:06:25 IST 1970,readBufferPosition=-1]}
> > 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Socket for 
> > address '192.168.56.1/162' is closed, opening it...
> > 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Trying to 
> > connect to 192.168.56.1/162
> > 
> > 
> > I see that "trying to connect to" is invoked the wakeup, so that must means 
> > the .select is released, but returns no keys, can there be any reason for 
> > that? 
> > 
> > 
> > 
> > 
> > -Original Message-
> > From: Frank Fock [mailto:f...@agentpp.com <mailto:f...@agentpp.com>] 
> > Sent: Monday, February 12, 2018 8:45 PM
> > To: Maayan, Elhanan <elhanan.maa...@sbdinc.com>
> > Cc: snmp4j@agentpp.org
> > Subject: Re: [SNMP4J] Possible concurrency bug in snmp4j ?
> > 
> > *External Message, please be cautious.*
> > 
> > Hi Elhanan,
> > 
> > Please upgrade to SNMP4J 2.5.11 to fix this issue.
> > 
> > Best regards 
> > Frank
> > 
> >> Am 12.02.2018 um 18:05 schrieb Maayan, Elhanan <elhanan.maa...@sbdinc.com>:
> >> 
> >> Hi..i'm using snm4j 2.4.3.
> >> 
> >> Is it possible that just when snmp4j closes a connection (due to timeout, 
> >> or remote closing) and it's trying to addRegistration causing to throw an 
> >> exception, is it possible that snmp4j can no longer establish connec

Re: [SNMP4J] Possible concurrency bug in snmp4j ?

2018-02-13 Thread Frank Fock
The immediate reconnection issue (TCP) to the same address and port (SFJ-164) 
has been fixed in SNMP4J 2.6.0 which is available as SNAPSHOT. 

See also the mailing list archive around January 27th. 

The ticket system is available for users with support contract.

Best regards,
Frank 

> On 12. Feb 2018, at 19:53, Maayan, Elhanan <elhanan.maa...@sbdinc.com> wrote:
> 
> Thanks, I'll try that , I'm trying to access the bug system, but I can't find 
> it
> 
> The real issue I'm encountering which I don't know the cause is that the 
> snmp4j tries to send messages, trying to connect , but simply doesn't, I did 
> a thread dump and it seems to be stuck on the select method no matter what
> 
> "DefaultTCPTransportMapping_192.168.60.80/0" #75906 daemon prio=5 os_prio=0 
> tid=0x7f4748e75000 nid=0x79e5 runnable [0x7f4733768000]
>   java.lang.Thread.State: RUNNABLE
>   at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
>   at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>   at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>   at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>   - locked <0x0007042019f8> (a sun.nio.ch.Util$3)
>   - locked <0x0007042019e8> (a java.util.Collections$UnmodifiableSet)
>   - locked <0x000704201a08> (a sun.nio.ch.EPollSelectorImpl)
>   at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>   at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>   at 
> org.snmp4j.transport.DefaultTcpTransportMapping$ServerThread.run(DefaultTcpTransportMapping.java:786)
>   at java.lang.Thread.run(Thread.java:745)
> 
> there's nothing on tcpdump, using a separate snmp4j on shell on the same 
> machine is able to connect to the same remote machine, 
> 
> but still:
> 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Looking up 
> connection for destination '192.168.56.1/162' returned: 
> SocketEntry[peerAddress=192.168.56.1/162,socket=Socket[unconnected],lastUse=Mon
>  Mar 09 07:06:25 IST 1970,readBufferPosition=-1]
> 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - 
> {192.168.56.1/162=SocketEntry[peerAddress=192.168.56.1/162,socket=Socket[unconnected],lastUse=Mon
>  Mar 09 07:06:25 IST 1970,readBufferPosition=-1]}
> 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Socket for address 
> '192.168.56.1/162' is closed, opening it...
> 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Trying to connect 
> to 192.168.56.1/162
> 
> 
> I see that "trying to connect to" is invoked the wakeup, so that must means 
> the .select is released, but returns no keys, can there be any reason for 
> that? 
> 
> 
> 
> 
> -Original Message-
> From: Frank Fock [mailto:f...@agentpp.com] 
> Sent: Monday, February 12, 2018 8:45 PM
> To: Maayan, Elhanan <elhanan.maa...@sbdinc.com>
> Cc: snmp4j@agentpp.org
> Subject: Re: [SNMP4J] Possible concurrency bug in snmp4j ?
> 
> *External Message, please be cautious.*
> 
> Hi Elhanan,
> 
> Please upgrade to SNMP4J 2.5.11 to fix this issue.
> 
> Best regards 
> Frank
> 
>> Am 12.02.2018 um 18:05 schrieb Maayan, Elhanan <elhanan.maa...@sbdinc.com>:
>> 
>> Hi..i'm using snm4j 2.4.3.
>> 
>> Is it possible that just when snmp4j closes a connection (due to timeout, or 
>> remote closing) and it's trying to addRegistration causing to throw an 
>> exception, is it possible that snmp4j can no longer establish connection?
>> 
>> 
>> 
>> Below is a small log of a sample client I'm doing , which does interval 
>> every 5 seconds, furthermore it's target.setTimeout is also set to 5 
>> seconds, to emulate the bug (which actually happens upon remote close)
>> 
>> You can see that subsequent attempts simply try to connect but don't' send 
>> anything..
>> 
>> 
>> 
>> Mon Feb 12 18:10:37 IST 2018 Sending message
>> 
>> Looking up connection for destination '192.168.97.21/162' returned: 
>> SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[addr=qa-mv-0640.corp.aeroscout.com/192.168.97.21,port=162,localport=51072],lastUse=Mon
>>  Mar 09 04:30:03 IST 1970,readBufferPosition=-1]
>> 
>> {192.168.97.21/162=SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[addr=qa-mv-0640.corp.aeroscout.com/192.168.97.21,port=162,localport=51072],lastUse=Mon
>>  Mar 09 04:30:03 IST 1970,readBufferPosition=-1]}
>> 
>> Waking up selector for new message
>> 
>> Socket has not been used for 10002 milliseconds, closing it
>> 
>> Socket to 192.168.97.21/162 closed d

Re: [SNMP4J] Possible concurrency bug in snmp4j ?

2018-02-12 Thread Frank Fock
Hi Elhanan,

Please upgrade to SNMP4J 2.5.11 to fix this issue.

Best regards 
Frank

> Am 12.02.2018 um 18:05 schrieb Maayan, Elhanan :
> 
> Hi..i'm using snm4j 2.4.3.
> 
> Is it possible that just when snmp4j closes a connection (due to timeout, or 
> remote closing) and it's trying to addRegistration causing to throw an 
> exception, is it possible that snmp4j can no longer establish connection?
> 
> 
> 
> Below is a small log of a sample client I'm doing , which does interval every 
> 5 seconds, furthermore it's target.setTimeout is also set to 5 seconds, to 
> emulate the bug (which actually happens upon remote close)
> 
> You can see that subsequent attempts simply try to connect but don't' send 
> anything..
> 
> 
> 
> Mon Feb 12 18:10:37 IST 2018 Sending message
> 
> Looking up connection for destination '192.168.97.21/162' returned: 
> SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[addr=qa-mv-0640.corp.aeroscout.com/192.168.97.21,port=162,localport=51072],lastUse=Mon
>  Mar 09 04:30:03 IST 1970,readBufferPosition=-1]
> 
> {192.168.97.21/162=SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[addr=qa-mv-0640.corp.aeroscout.com/192.168.97.21,port=162,localport=51072],lastUse=Mon
>  Mar 09 04:30:03 IST 1970,readBufferPosition=-1]}
> 
> Waking up selector for new message
> 
> Socket has not been used for 10002 milliseconds, closing it
> 
> Socket to 192.168.97.21/162 closed due to timeout
> 
> Adding operation 8 for: 
> SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[unconnected],lastUse=Mon
>  Mar 09 04:30:13 IST 1970,readBufferPosition=-1]
> 
> java.nio.channels.ClosedChannelException
> 
> Firing transport state event: 
> org.snmp4j.transport.TransportStateEvent[source=org.snmp4j.transport.DefaultTcpTransportMapping@1d6c6de8,peerAddress=192.168.97.21/162,newState=4,cancelled=false,causingException=java.nio.channels.ClosedChannelException]
> 
> State changed to Closed Peer address 192.168.97.21/162
> 
> Exception in thread "DefaultTCPTransportMapping_192.168.60.80/0" 
> java.lang.RuntimeException: java.nio.channels.ClosedChannelException
> 
>at 
> org.snmp4j.transport.DefaultTcpTransportMapping$ServerThread.processPending(DefaultTcpTransportMapping.java:697)
> 
>at 
> org.snmp4j.transport.DefaultTcpTransportMapping$ServerThread.run(DefaultTcpTransportMapping.java:893)
> 
>at java.lang.Thread.run(Thread.java:745)
> 
> Caused by: java.nio.channels.ClosedChannelException
> 
>at 
> java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:197)
> 
>at 
> org.snmp4j.transport.DefaultTcpTransportMapping$SocketEntry.addRegistration(DefaultTcpTransportMapping.java:433)
> 
>at 
> org.snmp4j.transport.DefaultTcpTransportMapping$ServerThread.processPending(DefaultTcpTransportMapping.java:658)
> 
>... 2 more
> 
> Mon Feb 12 18:10:47 IST 2018 Sending message
> 
> Looking up connection for destination '192.168.97.21/162' returned: null
> 
> {}
> 
> Socket for address '192.168.97.21/162' is closed, opening it...
> 
> Trying to connect to 192.168.97.21/162
> 
> Mon Feb 12 18:10:57 IST 2018 Sending message
> 
> Looking up connection for destination '192.168.97.21/162' returned: 
> SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[unconnected],lastUse=Mon
>  Mar 09 04:30:23 IST 1970,readBufferPosition=-1]
> 
> {192.168.97.21/162=SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[unconnected],lastUse=Mon
>  Mar 09 04:30:23 IST 1970,readBufferPosition=-1]}
> 
> Socket for address '192.168.97.21/162' is closed, opening it...
> 
> Trying to connect to 192.168.97.21/162
> 
> Mon Feb 12 18:11:07 IST 2018 Sending message
> 
> Looking up connection for destination '192.168.97.21/162' returned: 
> SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[unconnected],lastUse=Mon
>  Mar 09 04:30:33 IST 1970,readBufferPosition=-1]
> 
> {192.168.97.21/162=SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[unconnected],lastUse=Mon
>  Mar 09 04:30:33 IST 1970,readBufferPosition=-1]}
> 
> Socket for address '192.168.97.21/162' is closed, opening it...
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Extend DefaultTcpTransportMapping to support NTCIP PMPP

2018-01-28 Thread Frank Fock
Hello Bruno,

I have changed the DefaultTcpTransportMapping to support your below stated 
requirements in SNMP4J 2.6.0.

Best regards,
Frank

> On 26. Jan 2018, at 19:10, Bruno Abreu  wrote:
> 
> Hello again,
> 
> first of all, thank you for you quick reply to our previous post regarding
> SocketTimeout: http://oosnmp.net/pipermail/snmp4j/2018-January/005886.html
> 
> Now we have another request. As already stated, we are using SNMP4J to handle
> the NTCIP-PMPP protocol. But we have specific needs when reading messages from
> a particular device. Namely, because some characters might be escaped, we need
> to keep reading until the end mark is reached. The strategy of using the
> length from the message header just doesn't work because the message size
> might have changed.
> 
> For that we need to extend the DefaultTcpTransportMapping and
> DefaultTcpTransportMapping.ServerThread classes and override the following
> methods:
> 
> From DefaultTcpTransportMapping:
> - private void addBufferToReadBuffer(SocketEntry entry, ByteBuffer 
> byteBuffer);
> 
> From DefaultTcpTransportMapping.ServerThread:
> - private boolean readMessage(SelectionKey sk, SocketChannel readChannel,
> TcpAddress incomingAddress) throws IOException;
> - private void readSnmpMessagePayload(SocketChannel readChannel, TcpAddress
> incomingAddress, SocketEntry entry, ByteBuffer byteBuffer) throws IOException;
> 
> In order to this we had to change the visibility of some of the members of
> these classes, either because we want to override them or because they are
> accessed from the overriden methods. The following patch contains the changes
> we had to apply to DefaultTcpTransportMapping:
> 
> «««
> --- DefaultTcpTransportMapping.java.2.5.112018-01-26 11:36:14.019589314 
> +
> +++ DefaultTcpTransportMapping.java   2018-01-26 13:47:50.0 +
> @@ -62,17 +62,17 @@ public class DefaultTcpTransportMapping
>   private static final LogAdapter logger =
>   LogFactory.getLogger(DefaultTcpTransportMapping.class);
> 
> -  private Map sockets = new Hashtable SocketEntry>();
> -  private WorkerTask server;
> -  private ServerThread serverThread;
> +  protected Map sockets = new Hashtable SocketEntry>();
> +  protected WorkerTask server;
> +  protected ServerThread serverThread;
> 
> -  private CommonTimer socketCleaner;
> +  protected CommonTimer socketCleaner;
>   // 1 minute default timeout
> -  private long connectionTimeout = 6;
> +  protected long connectionTimeout = 6;
>   private boolean serverEnabled = false;
> 
>   private static final int MIN_SNMP_HEADER_LENGTH = 6;
> -  private MessageLengthDecoder messageLengthDecoder =
> +  protected MessageLengthDecoder messageLengthDecoder =
>   new SnmpMesssageLengthDecoder();
>   private int maxBusyLoops = DEFAULT_MAX_BUSY_LOOPS;
> 
> @@ -603,12 +603,12 @@ public class DefaultTcpTransportMapping
> }
>   }
> 
> -  class ServerThread implements WorkerTask {
> -private byte[] buf;
> +  protected class ServerThread implements WorkerTask {
> +protected byte[] buf;
> private volatile boolean stop = false;
> private Throwable lastError = null;
> private ServerSocketChannel ssc;
> -private Selector selector;
> +protected Selector selector;
> 
> private LinkedList pending = new LinkedList();
> 
> @@ -993,7 +993,7 @@ public class DefaultTcpTransportMapping
>   }
> }
> 
> -private boolean readMessage(SelectionKey sk, SocketChannel readChannel,
> +protected boolean readMessage(SelectionKey sk, SocketChannel readChannel,
> TcpAddress incomingAddress) throws 
> IOException {
>   SocketEntry entry = (SocketEntry) sk.attachment();
>   if (entry == null) {
> @@ -1075,7 +1075,7 @@ public class DefaultTcpTransportMapping
>   return false;
> }
> 
> -private void readSnmpMessagePayload(SocketChannel readChannel, TcpAddress
> incomingAddress,
> +protected void readSnmpMessagePayload(SocketChannel readChannel,
> TcpAddress incomingAddress,
> SocketEntry entry, ByteBuffer
> byteBuffer) throws IOException {
>   MessageLength messageLength =
>   
> messageLengthDecoder.getMessageLength(ByteBuffer.wrap(byteBuffer.array()));
> @@ -1142,7 +1142,7 @@ public class DefaultTcpTransportMapping
>   }
> }
> 
> -private void dispatchMessage(TcpAddress incomingAddress,
> +protected void dispatchMessage(TcpAddress incomingAddress,
>  ByteBuffer byteBuffer, long bytesRead,
>  Object sessionID) {
>   byteBuffer.flip();
> @@ -1225,7 +1225,7 @@ public class DefaultTcpTransportMapping
> }
>   }
> 
> -  private void addBufferToReadBuffer(SocketEntry entry, ByteBuffer 
> byteBuffer) {
> +  protected void addBufferToReadBuffer(SocketEntry entry, ByteBuffer
> byteBuffer) {
> 

Re: [SNMP4J] PDP "class has wrong version"

2018-01-27 Thread Frank Fock
This means your compiler is using a language level less than 1.6. Java 6 SE is 
the minimum required for SNMP4J 2.x. For 3.x it will be Java 9 SE.

> On 27. Jan 2018, at 16:44, Mark Harpt  wrote:
> 
> I upgraded my SNMP jars and when I try to build I get "class has wrong 
> version" error on my PDU include.  The version is 50 instead of 49.
> 
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] SocketTimeout task leaks open socket

2018-01-26 Thread Frank Fock
Hi Bruno,

Your use case is indeed special although absolutely valid, of course. The fix 
seems to be pretty clean and straightforward. I will write a unit test for it 
and if everything is fine, it will be included in the next release.

Best regards,
Frank


> On 26. Jan 2018, at 17:02, Bruno Abreu  wrote:
> 
> Hello,
> 
> we are using snmp4j to handle NTCIP-PMPP protocol which is based in SNMP over
> TCP.
> 
> More details about NTCIP-PMPP specification, see:
> http://www.ntcip.org/library/documents/pdf/pmpp01.pdf
> 
> In our case, we need to connect to a device that can only accept one
> connection at a time. This lead us to find what we think might be a bug in the
> DefaultTcpTransportMapping class.
> 
> Because of that "one connection at a time" requirement, we need to close the
> socket explicitly, immediately after communication with the device is
> finished, so that other clients can connect. The SocketTimeout timer task,
> however, is still scheduled to run after the socket is closed. It will
> eventually execute and, since it holds a reference to a socket that is already
> closed, invoking close() on that socket will cause no harm. The problem is
> that it also removes from the 'sockets' Hashtable any entry that might have
> been created with the same target address of the socket it was supposed to be
> closing.
> 
> Since it's possible that a new conversation to the same device is already
> taking place, when a new message is about to be sent out, the
> DefaultTcpTransportMapping doesn't find the entry in the 'sockets' table and
> tries to establish a new connection. From that point on we receive Connection
> refused exceptions.
> 
> The following patch succeeded in solving our problem. We submit it here in
> case you want to consider applying to the DefaultTcpTransportMapping class in
> a future release.
> 
> »»»
> --- DefaultTcpTransportMapping.java.2.5.112018-01-26 11:36:14.019589314 
> +
> +++ DefaultTcpTransportMapping.java   2018-01-26 11:11:42.0 +
> @@ -258,6 +258,9 @@ public class DefaultTcpTransportMapping
> }
> SocketEntry entry = sockets.remove(remoteAddress);
> if (entry != null) {
> +  if (entry.getSocketCleaner() != null) {
> +entry.getSocketCleaner().cancel();
> +  }
>   Socket s = entry.getSocket();
>   if (s != null) {
> SocketChannel sc = entry.getSocket().getChannel();
> @@ -388,7 +391,9 @@ public class DefaultTcpTransportMapping
> 
>   private synchronized void timeoutSocket(SocketEntry entry) {
> if (connectionTimeout > 0) {
> -  socketCleaner.schedule(new SocketTimeout(entry), connectionTimeout);
> +  SocketTimeout socketTimeoutCleaner = new SocketTimeout(entry);
> +  entry.setSocketCleaner(socketTimeoutCleaner);
> +  socketCleaner.schedule(socketTimeoutCleaner, connectionTimeout);
> }
>   }
> 
> @@ -421,6 +426,7 @@ public class DefaultTcpTransportMapping
> private ByteBuffer readBuffer = null;
> private volatile int registrations = 0;
> private volatile int busyLoops = 0;
> +private SocketTimeout socketCleaner = null;
> 
> public SocketEntry(TcpAddress address, Socket socket) {
>   this.peerAddress = address;
> @@ -506,6 +512,14 @@ public class DefaultTcpTransportMapping
>   busyLoops = 0;
> }
> 
> +public SocketTimeout getSocketCleaner() {
> +return socketCleaner;
> +}
> +
> +public void setSocketCleaner(SocketTimeout socketCleaner) {
> +this.socketCleaner = socketCleaner;
> +}
> +
> public String toString() {
>   return "SocketEntry[peerAddress="+peerAddress+
>   ",socket="+socket+",lastUse="+new
> Date(lastUse/SnmpConstants.MILLISECOND_TO_NANOSECOND)+
> @@ -592,7 +606,9 @@ public class DefaultTcpTransportMapping
>   if (logger.isDebugEnabled()) {
> logger.debug("Scheduling " + nextRun);
>   }
> -  socketCleaner.schedule(new SocketTimeout(entry), nextRun);
> +  SocketTimeout socketTimeoutCleaner = new SocketTimeout(entry);
> +  entry.setSocketCleaner(socketTimeoutCleaner);
> +  socketCleaner.schedule(socketTimeoutCleaner, nextRun);
> }
> 
> public boolean cancel(){
> «««
> 
> 
> That you for you attention,
> Bruno Abreu
> 
> -- 
> Living Data - Sistemas de Informação e Apoio à Decisão, Lda.
> LxFactory - Rua Rodrigues de Faria, 103, edifício I, 4º piso
> 1300-501 LISBOA   Phone:  +351 213622163
> Portugal  URL: www.livingdata.pt
> 
> 
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] SNMP client works remotely but fails locally

2018-01-26 Thread Frank Fock
If you are using the latest SNMP4J then the MPv3.createLocalEngineID already 
uses a randomly generated part, because this was a common error. To create a 
stable unique ID you can use the other method which takes an OctetString 
argument. The correct engine ID format is described in the SNMPv3 RFCs or some 
Wiki page. 

If the random variant is not working for you, then the random system is 
probably not will setup/initialized. This might also be a problem of the 
underlying OS.


> On 26. Jan 2018, at 15:26, Mark Harpt <mhar...@cox.net> wrote:
> 
> Thank you for the reply. Do I just make up an engine ID, since 
> createLocalEngineID seems to return the same one on both the agent and the 
> client?  If I just make one up, how do I do that (beginner alert)?
> 
> 
> 
> Here's the relevant part of my test code:
> 
> TransportMapping transport = new DefaultUdpTransportMapping();
> Snmp snmp = new Snmp(transport);
> 
> OctetString localEngineId = new OctetString(MPv3.createLocalEngineID());  
>   <<<<<<<<<<<<<<<<
> USM usm = new USM(SecurityProtocols.getInstance(), localEngineId, 0);
> SecurityModels.getInstance().addSecurityModel(usm);
> 
> OctetString securityName = new OctetString("myuser");
> OID authProtocol = AuthMD5.ID;
> OID privProtocol = PrivDES.ID;
> OctetString authPassphrase = new OctetString("myauth");
> OctetString privPassphrase = new OctetString("mypriv");
> 
> snmp.getUSM().addUser(securityName, new UsmUser(securityName, 
> authProtocol, authPassphrase, privProtocol, privPassphrase));
> 
> UserTarget target = new UserTarget();
> target.setSecurityLevel(SecurityLevel.AUTH_PRIV);
> target.setSecurityName(securityName);
> 
> target.setAddress(GenericAddress.parse(String.format("udp:%s/%s", 
> "127.0.0.1", "161")));
> target.setVersion(SnmpConstants.version3);
> target.setRetries(2);
> target.setTimeout(6);
> 
> transport.listen();
> 
> PDU pdu = new ScopedPDU();
> pdu.add(new VariableBinding(new OID("1.3.6.1.4.5.2.1.3"), new 
> Integer32(1)));
> pdu.setType(PDU.SET);
> ResponseEvent event = snmp.send(pdu, target);
> if (event != null) {
> pdu = event.getResponse();
> if (pdu.getErrorStatus() == PDU.noError) {
>   System.out.println("SET Successful!");
> } else {
>   System.out.println("SET Unsuccessful.");
> }
> }
>
> 
> 
>> On Jan 26, 2018, at 2:14 AM, Frank Fock <f...@agentpp.com 
>> <mailto:f...@agentpp.com>> wrote:
>> 
>> Hi,
>> 
>> This is most likely an issue about using the same engine ID if both run 
>> locally. You must use a unique ID to get it working.
>> 
>> Best regards,
>> Frank
>> 
>> 
>> 
>>> On 26. Jan 2018, at 02:39, Mark Harpt <mhar...@cox.net 
>>> <mailto:mhar...@cox.net>> wrote:
>>> 
>>> I wrote an SNMP client that talks to an agent (gets and sets) just fine if 
>>> the client is on a separate Windows PC from the agent.  If the client is on 
>>> the same Windows PC as the agent, the agent receives the message from the 
>>> client but does not act upon it.  Any ideas?
>>> 
>>> ___
>>> SNMP4J mailing list
>>> SNMP4J@agentpp.org <mailto:SNMP4J@agentpp.org>
>>> https://oosnmp.net/mailman/listinfo/snmp4j 
>>> <https://oosnmp.net/mailman/listinfo/snmp4j>
>> 

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] SNMP client works remotely but fails locally

2018-01-26 Thread Frank Fock
Hi,

This is most likely an issue about using the same engine ID if both run 
locally. You must use a unique ID to get it working.

Best regards,
Frank



> On 26. Jan 2018, at 02:39, Mark Harpt  wrote:
> 
> I wrote an SNMP client that talks to an agent (gets and sets) just fine if 
> the client is on a separate Windows PC from the agent.  If the client is on 
> the same Windows PC as the agent, the agent receives the message from the 
> client but does not act upon it.  Any ideas?
> 
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


[SNMP4J] New Releases AGENT++ Tool Suite, SNMP4J, SNMP4J-SMI-PRO

2018-01-23 Thread Frank Fock
olution displays and to provide better layout and performance.
* Added: Ctrl-C on statistics table dialog copies the selected content to the 
clipboard.
* Fixed: Pro edition: Scripts tab's Save buttons where disabled although script 
code
 has been changed.
* Improved: Packet Analyze function now also supports analysing multiple 
packets and once.

SNMP4J 2.5.11

* Improved [SFJ-162]: TableUtils now waits until three (3) primary 
lexicographic ordering errors
  occurred and returns all rows until then. Rows that contain cell values based 
on incorrectly
  order data will be returned now with status TableEvent.STATUS_WRONG_ORDER. 
That strate will be also
  set in the finishing TableEvent then.

* Fixed [SFJ-161]: TableUtils does not check for lexicographic ordering in 
SNMP4J 2.5.9 which could
  cause endless looping with incorrectly implemented agents. The ordering 
checking can be now disabled
  but is enabled by default.

* Fixed [SFJ-160]: TableUtils returns a wrong order false positive error for 
single row tables when
  using GETBULK with more than one repetition.

SNMP4J-SMI-PRO -1.9.5 (Requires SNMP4J 2.5.11 or later)

* Fixed [SFJ-163]: SmiManager.findSmiObject(String moduleName, 
SmiObjectFilter filter)
  does not use specified moduleName.
* Added: SmiManager.SmiModule.getObjectIdentifiers(OIDOrder) returns all object 
identifiers
  of a loaded MIB module.
* Added: OIDComparator class to compare OIDs in depth-first-or 
breadth-first-order.
* Improved: SmiModule extends SmiObject interface.

* Added: SmiModule.getSmiModuleDefinition() returns the complete SMIv1/v2 
specification
  text as a string.


Best regards,
Frank Fock

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] SNMP4J Agent on Xilinx Zynq ZCU102 Development Board Running Peta Linux

2017-12-06 Thread Frank Fock
Hi Don,

It is just a guess: may be it is caused because the system is very slow in 
providing random data.
Have you checked that? (On most such platforms there is a workaround to provide 
faster good random values)

But I have to admit, that it could be something completely different.

Best regards,
Frank

 


> On 6. Dec 2017, at 19:30, Broderick, Don  wrote:
> 
> I am trying to run an agent I made using AgenPro on this hardware and it get 
> to calling AgentConfigmanager.initialize() method but it never returns.  This 
> same agent works on Windows and Linux without problem.  I have included a 
> portion of the Java verbose output below and the Agent just hangs after the 
> last line below with no other activity happening.  When I run it on Linux or 
> Windows I get much more output after the corresponding last line below.  I 
> would expect the Agent.bc file to be created/updated in the initialize method 
> but it is not being created.  I tried manually creating the file but still 
> have the same behavior.  I am using the Oracle Java distribution.  Any 
> suggestions would be appreciated.
> 
> Thanks,
> Don
> 
> [Loaded org.snmp4j.security.USM from jar:rsrc:snmp4j-2.5.7.jar!/]
> [Loaded org.snmp4j.security.SecurityParameters from 
> jar:rsrc:snmp4j-2.5.7.jar!/]
> [Loaded org.snmp4j.security.SecurityStateReference from 
> jar:rsrc:snmp4j-2.5.7.jar!/]
> [Loaded org.snmp4j.security.SecurityProtocols from 
> jar:rsrc:snmp4j-2.5.7.jar!/]
> [Loaded org.snmp4j.security.SecurityProtocol from jar:rsrc:snmp4j-2.5.7.jar!/]
> [Loaded org.snmp4j.security.AuthenticationProtocol from 
> jar:rsrc:snmp4j-2.5.7.jar!/]
> [Loaded org.snmp4j.security.PrivacyProtocol from jar:rsrc:snmp4j-2.5.7.jar!/]
> [Loaded org.snmp4j.security.AuthGeneric from jar:rsrc:snmp4j-2.5.7.jar!/]
> [Loaded org.snmp4j.security.AuthMD5 from jar:rsrc:snmp4j-2.5.7.jar!/]
> [Loaded java.security.GeneralSecurityException from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded java.security.NoSuchAlgorithmException from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded org.snmp4j.mp.SnmpConstants from jar:rsrc:snmp4j-2.5.7.jar!/]
> [Loaded org.snmp4j.security.AuthSHA from jar:rsrc:snmp4j-2.5.7.jar!/]
> [Loaded org.snmp4j.security.AuthSHA2 from jar:rsrc:snmp4j-2.5.7.jar!/]
> [Loaded org.snmp4j.security.AuthHMAC128SHA224 from 
> jar:rsrc:snmp4j-2.5.7.jar!/]
> [Loaded org.snmp4j.security.AuthHMAC192SHA256 from 
> jar:rsrc:snmp4j-2.5.7.jar!/]
> [Loaded org.snmp4j.security.AuthHMAC256SHA384 from 
> jar:rsrc:snmp4j-2.5.7.jar!/]
> [Loaded org.snmp4j.security.AuthHMAC384SHA512 from 
> jar:rsrc:snmp4j-2.5.7.jar!/]
> [Loaded org.snmp4j.security.PrivacyGeneric from jar:rsrc:snmp4j-2.5.7.jar!/]
> [Loaded org.snmp4j.security.PrivDES from jar:rsrc:snmp4j-2.5.7.jar!/]
> [Loaded java.security.spec.AlgorithmParameterSpec from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded java.security.Key from /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Opened /home/root/jdk1.8.0_152/jre/lib/jce.jar]
> [Loaded javax.crypto.NoSuchPaddingException from 
> /home/root/jdk1.8.0_152/jre/lib/jce.jar]
> [Loaded java.security.InvalidAlgorithmParameterException from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded java.security.KeyException from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded java.security.InvalidKeyException from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded org.snmp4j.security.Salt from jar:rsrc:snmp4j-2.5.7.jar!/]
> [Loaded sun.security.provider.SecureRandom$SeederHolder from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded sun.security.provider.SeedGenerator from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded sun.security.provider.SeedGenerator$URLSeedGenerator from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded sun.security.provider.NativeSeedGenerator from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded sun.security.provider.SeedGenerator$URLSeedGenerator$1 from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded sun.security.provider.SeedGenerator$1 from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded java.net.NetworkInterface$2 from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded java.nio.file.DirectoryStream$Filter from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded java.nio.file.Files$AcceptAllFilter from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded java.nio.file.DirectoryStream from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded sun.nio.fs.UnixDirectoryStream from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded java.util.concurrent.locks.ReadWriteLock from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded java.util.concurrent.locks.ReentrantReadWriteLock from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded java.util.concurrent.locks.ReentrantReadWriteLock$Sync from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded java.util.concurrent.locks.ReentrantReadWriteLock$FairSync from 
> /home/root/jdk1.8.0_152/jre/lib/rt.jar]
> [Loaded 
> 

Re: [SNMP4J] Using TLS for SNMPv3

2017-11-14 Thread Frank Fock
Hi Nick,

The most important question is: Does the server implement RFC5590, 5591, 6353 
and did you configure the manager side (SNMP4J) accordingly. 

If both sides are consistently setup and configured according to those RFCs, 
then it will work.
(I know this statement does not help much, but I have too few information to 
identify where the setup or the configuration is incomplete or inconsistent.

Best regards,
Frank


> On 14. Nov 2017, at 22:54, Nick Chang <nick.ch...@serimaconsulting.com> wrote:
> 
> Hi Frank,
> 
> Thanks very much for the quick response. Currently I am just in the 
> researching phase to verify the functionality of snmp4j over TLS. I can 
> envision that there will be definitely some sort of certificate management 
> scheme for the devices on the server side.
> 
> At the moment, the two issues that I raised in my previous email are 
> preventing me from proceeding further with the prototyping effort. Do you 
> have any pointer or hint on how to work through these two issues?
> 
> Thanks again in advance!
> 
> Nick
> 
> On 11/14/17, 3:20 PM, "Frank Fock" <f...@agentpp.com> wrote:
> 
>Hi Nick,
> 
>When using TLSTM, you are not doing TLS alone. TLSTM is integrated to the 
> SNMPv3 transport model and uses the security name too. Thus, the security 
> name you use in SNMP, is mapped to the certificates (roughly). For this 
> mapping, more than one approach exists. Is that supported (TLSTM including 
> security-name-to- certificate mapping) on the server side?
> 
>If yes, you can use the SnmpConfigurator in SNMP4J’s util package to 
> configure your Snap session.
> 
>Best regards,
>Frank  
> 
> 
>> On 14. Nov 2017, at 20:45, Nick Chang <nick.ch...@serimaconsulting.com> 
>> wrote:
>> 
>> Hi Frank,
>> 
>> I made some further progress by importing DeviceCert into the keystore and 
>> then also corrected the subject name is  the call 
>> securityCallback.addAcceptedSubjectDN().
>> Now I can see the SSL handshaking successful. However, I still experience 
>> following two issues:
>> 
>> 1. Occasionally, the handshaking failed and got such an error during 
>> “ServerHello, TLSv1.2” phase.
>> javax.net.ssl.SSLException: Unsupported record version Unknown-26.31
>>  at sun.security.ssl.InputRecord.checkRecordVersion(InputRecord.java:552)
>>  at 
>> sun.security.ssl.EngineInputRecord.bytesInCompletePacket(EngineInputRecord.java:113)
>>  at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:868)
>>  at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
>>  at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
>>  at org.snmp4j.transport.TLSTM$ServerThread.readMessage(TLSTM.java:1483)
>> 
>> 2. All the requests are timed out and the response.getResponse() is always 
>> null. I set the timeout very high, 1 minute, and retries to 3. The same 
>> device can respond to snmpget command without any delay. Below is the code 
>> snippet of sending a request
>>   PDU pdu = new ScopedPDU();
>>   pdu.add(new VariableBinding(new OID(someOid),new 
>> OctetString("Hello")));
>>   pdu.setType(PDU.GET);
>>   ResponseEvent response = snmp.send(pdu, ct);
>>   logger.debug("Response: {} ", response.getResponse());
>> 
>> Any suggestion on further trouble shooting this is greatly appreciated!
>> 
>> Thanks a lot in advance,
>> 
>> Nick
>> 
>> On 11/13/17, 10:07 PM, "Nick Chang" <nick.ch...@serimaconsulting.com> wrote:
>> 
>>   Hi Frank,
>> 
>>   Thanks for your reply. I did use “System.setProperty("javax.net.debug", 
>> "all");” to view the handshaking traffic between the device and the client. 
>> I found out that I need to add the following lines to get it working with 
>> Java 1.8 since it supports TLSv1.2 by default
>> 
>>   String[] tlsProtocols = new String[]{"TLSv1.2"};
>>   ((TLSTM) transport).setTlsProtocols(tlsProtocols);
>> 
>>   I currently got stuck at *** ServerHello, TLSv1.2 step, the error is
>>   “sun.security.validator.ValidatorException: PKIX path building failed: 
>> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
>> valid certification path to requested target”
>> 
>>   I think that it might have something to do with the incorrect setup of 
>> keystore and truststore that I have, but I have not been able to figure out 
>> what exactly I should construct them to make it pass this error.
>&

Re: [SNMP4J] Using TLS for SNMPv3

2017-11-14 Thread Frank Fock
Hi Nick,

When using TLSTM, you are not doing TLS alone. TLSTM is integrated to the 
SNMPv3 transport model and uses the security name too. Thus, the security name 
you use in SNMP, is mapped to the certificates (roughly). For this mapping, 
more than one approach exists. Is that supported (TLSTM including 
security-name-to- certificate mapping) on the server side?

If yes, you can use the SnmpConfigurator in SNMP4J’s util package to configure 
your Snap session.

Best regards,
Frank  


> On 14. Nov 2017, at 20:45, Nick Chang <nick.ch...@serimaconsulting.com> wrote:
> 
> Hi Frank,
> 
> I made some further progress by importing DeviceCert into the keystore and 
> then also corrected the subject name is  the call 
> securityCallback.addAcceptedSubjectDN().
> Now I can see the SSL handshaking successful. However, I still experience 
> following two issues:
> 
> 1. Occasionally, the handshaking failed and got such an error during 
> “ServerHello, TLSv1.2” phase.
> javax.net.ssl.SSLException: Unsupported record version Unknown-26.31
>   at sun.security.ssl.InputRecord.checkRecordVersion(InputRecord.java:552)
>   at 
> sun.security.ssl.EngineInputRecord.bytesInCompletePacket(EngineInputRecord.java:113)
>   at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:868)
>   at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
>   at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
>   at org.snmp4j.transport.TLSTM$ServerThread.readMessage(TLSTM.java:1483)
> 
> 2. All the requests are timed out and the response.getResponse() is always 
> null. I set the timeout very high, 1 minute, and retries to 3. The same 
> device can respond to snmpget command without any delay. Below is the code 
> snippet of sending a request
>PDU pdu = new ScopedPDU();
>pdu.add(new VariableBinding(new OID(someOid),new 
> OctetString("Hello")));
>pdu.setType(PDU.GET);
>ResponseEvent response = snmp.send(pdu, ct);
>logger.debug("Response: {} ", response.getResponse());
> 
> Any suggestion on further trouble shooting this is greatly appreciated!
> 
> Thanks a lot in advance,
> 
> Nick
> 
> On 11/13/17, 10:07 PM, "Nick Chang" <nick.ch...@serimaconsulting.com> wrote:
> 
>Hi Frank,
> 
>Thanks for your reply. I did use “System.setProperty("javax.net.debug", 
> "all");” to view the handshaking traffic between the device and the client. I 
> found out that I need to add the following lines to get it working with Java 
> 1.8 since it supports TLSv1.2 by default
> 
>String[] tlsProtocols = new String[]{"TLSv1.2"};
>((TLSTM) transport).setTlsProtocols(tlsProtocols);
> 
>I currently got stuck at *** ServerHello, TLSv1.2 step, the error is
>“sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target”
> 
>I think that it might have something to do with the incorrect setup of 
> keystore and truststore that I have, but I have not been able to figure out 
> what exactly I should construct them to make it pass this error.
> 
>Here are certificates and keys that I have, 
>• CACert
>• DeviceCert: whose alias is “device”
>• ClientCert: whose alias is “client”
>• DeviceKey: private key of device
>• ClientKey : private key of client
>which I could connect to the device by using such a command: 
>openssl s_client -connect <Device’s IPv6 Addr>: -tls1_2 -cert 
> ClientCert -CAfile CACert -key ClientKey
> 
>The keystore is created by adding ClientCert,  CACert and ClientKey 
> together.
> 
>Then I imported the CACert and DeviceCert into Java’s default truststore 
> in JAVA_HOME/lib/security/cacerts
> 
>And in the client code, I have
> 
>CertifiedTarget ct = new CertifiedTarget(new OctetString(“device”));
> 
>and 
> 
>    securityCallback.addLocalCertMapping(ct.getAddress(), “client”);
> 
>Any pointer on what keystore and truststore should be and the correct way 
> to construct CertifiedTarget and use securityCallback.addLocalCertMapping() 
> is greatly appreciated.
> 
>Thanks very much,
> 
>Nick
> 
>On 11/13/17, 6:34 PM, "Frank Fock" <f...@agentpp.com> wrote:
> 
>Hi Nick,
> 
>Do you have enabled debug logging? This should give more detailed 
> information about the TLS handshake.
> 
>Best regards,
>Frank
> 
> 
>> On 11. Nov 2017, at 17:14, Nick Chang <nick.ch...

Re: [SNMP4J] Using TLS for SNMPv3

2017-11-13 Thread Frank Fock
Hi Nick,

Do you have enabled debug logging? This should give more detailed information 
about the TLS handshake.

Best regards,
Frank


> On 11. Nov 2017, at 17:14, Nick Chang  wrote:
> 
> Hi Frank,
> 
> I am using snmp4j to build a client with functionality similar to that of 
> net-snmp’s snmpget. The device is using IPv6 and configured with TLS.
> I followed the instruction carefully given on this page, 
> https://oosnmp.net/confluence/pages/viewpage.action?pageId=3834144, but the 
> response always comes back with null from the device.
> Do you have any suggestion how I should trouble this further. I am using JDK 
> 1.8 and snmp4j v2.5.6
> 
> Thanks,
> 
> Nick
> 
> 
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] SNMP4J - SSH Transport

2017-11-07 Thread Frank Fock
Hi Prema,

TLS transport is only standardised for SNMPv3 messaging protocol. It  will not 
work for SNMPv2c.
If you simply want to encrypt the traffic between manager and agent (what seems 
to be the case, otherwise SNMPv3 would be your base requirement), then using a 
VPN (IPsec) between manager and agent could be an option. 

Best regards,
Frank


> On 7. Nov 2017, at 17:36, Prema Upot <prema.u...@optelian.com> wrote:
> 
> Hi Frank,
> 
> We initially had the idea of using SSH since we already had SSH server 
> running on the server side. But on further investigation, it appears that we 
> need to do more work in that area to make it usable for SNMP, so we are going 
> to try TLS transport instead as you suggested. 
> 
> I have a couple of questions in this area.
> The FAQ in this page 
> https://oosnmp.net/confluence/pages/viewpage.action?pageId=3834144 
> <https://oosnmp.net/confluence/pages/viewpage.action?pageId=3834144> states 
> we need to use MPv3 model. Our server is going to be processing SNMP v2 
> messages going over TLS. 
> How do I set up the messageProcessingModel and CertifiedTarget version in 
> this case in the SNMP4J based client ?
> 
> Thanks,
> Prema
> 
> -Original Message-
> From: Frank Fock [mailto:f...@agentpp.com <mailto:f...@agentpp.com>] 
> Sent: Friday, October 20, 2017 3:54 PM
> To: Prema Upot <prema.u...@optelian.com <mailto:prema.u...@optelian.com>>
> Cc: snmp4j@agentpp.org <mailto:snmp4j@agentpp.org>
> Subject: Re: [SNMP4J] SNMP4J - SSH Transport
> 
> Hi Prema,
> 
> The both interface classes are only a first approach, but nothing usable at 
> the moment.
> SNMP over SSH is rather complex to implement. I prefer using TLS directly.
> Why are you looking for SSH?
> 
> Best regards,
> Frank
> 
> 
>> On 20. Oct 2017, at 19:53, Prema Upot <prema.u...@optelian.com> wrote:
>> 
>> Hi,
>> 
>> I see that the latest snmp4j 2.5.8 has support code for integrating a third 
>> party SSH stack as transport.  Has anyone tried it especially with JSch?
>> 
>> Thanks,
>> Prema
>> ___
>> SNMP4J mailing list
>> SNMP4J@agentpp.org
>> https://linkprotect.cudasvc.com/url?a=https://oosnmp.net/mailman/listinfo/snmp4j=E,1,NlPzmXwc6S2koC0fribV2K_et0Nrl5Vwr1cIZGP15pHFtI6FeGtq8nnHKNnEBzyEOFIP81YxyN7q-YuKc--1o5ocemHBKgQ3jODvc2lCCfWXFMsCXQB2=1
>>  
>> <https://linkprotect.cudasvc.com/url?a=https://oosnmp.net/mailman/listinfo/snmp4j=E,1,NlPzmXwc6S2koC0fribV2K_et0Nrl5Vwr1cIZGP15pHFtI6FeGtq8nnHKNnEBzyEOFIP81YxyN7q-YuKc--1o5ocemHBKgQ3jODvc2lCCfWXFMsCXQB2=1>
___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] SNMP4J - SSH Transport

2017-10-20 Thread Frank Fock
Hi Prema,

The both interface classes are only a first approach, but nothing usable at the 
moment.
SNMP over SSH is rather complex to implement. I prefer using TLS directly.
Why are you looking for SSH?

Best regards,
Frank


> On 20. Oct 2017, at 19:53, Prema Upot  wrote:
> 
> Hi,
> 
> I see that the latest snmp4j 2.5.8 has support code for integrating a third 
> party SSH stack as transport.  Has anyone tried it especially with JSch?
> 
> Thanks,
> Prema
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] SNMP4J-SMI-PRO Missing artifact in Maven repository?

2017-09-28 Thread Frank Fock
Hi Don,

I do not know why it is not working with your repository proxy. Nevertheless,
I will simplify the dependencies for the next release, so that it will work 
even in your case out-of-the-box.
Doing that requires some restructuring of the AGENT++ internal packages but 
that should be worth it.

Best regards,
Frank


> On 27. Sep 2017, at 17:17, Broderick, Don <d...@mitre.org> wrote:
> 
> Frank,
>  
> With 1.8.0 I have the following which works:
>  
> org.snmp4j.smi
> snmp4j-smi-pro
> 1.8.0
>  
>  
> For 1.9.2 I have the following which causes the Maven error:
>  
> org.snmp4j.smi
> snmp4j-smi-pro
> 1.9.2
> jar-with-dependencies
>  
>  
> That is the only difference in the pom file from when it works and doesn’t.
>  
> I have taken the jar with dependencies and included it directly in the java 
> build path in Eclipse as an external library and removed the dependency from 
> my pom file.  This works correctly and I am able to build and run my 
> application.
>  
> Thanks,
> DonB
> 
> 
>  
> From: Frank Fock [mailto:f...@agentpp.com] 
> Sent: Wednesday, September 20, 2017 4:26 PM
> To: Broderick, Don <d...@mitre.org>
> Cc: snmp4j@agentpp.org
> Subject: Re: [SNMP4J] SNMP4J-SMI-PRO Missing artifact in Maven repository?
>  
>  
> Don,
>  
> The JASMI classes are in the packages com.agentpp.smi and 
> com.agentpp.smiparser for example.
> They are all included in the jar-with-dependencies. 
> Something must be still wrong with your pom.xml
> A dependency to JASMI should not exists in that pom.xml nor induced due to 
> transitive dependencies.
>  
> Best regards,
> Frank
>  
> On 20. Sep 2017, at 17:16, Broderick, Don <d...@mitre.org 
> <mailto:d...@mitre.org>> wrote:
>  
> Frank,
> 
> No problem, I am grateful you are being so helpful!
> 
> Unfortunately I am getting "Missing artifact com.oosnmp:jasmi:jar:4.2.2" now. 
>  I examined our Artifactory and see  
> snmp4j-smi-pro-1.9.2-jar-with-dependencies.jar that is 893.84 KB.  When I 
> examine what is in the jar using the Artifactory web interface I see under 
> com it has agentpp, objectspace, and snmp4j.  Should it show oosnmp that has 
> jasmi also?
> 
> Thanks for all your help,
> DonB
> 
> -Original Message-
> From: Frank Fock [mailto:f...@agentpp.com <mailto:f...@agentpp.com>] 
> Sent: Thursday, September 14, 2017 8:37 PM
> To: Broderick, Don <d...@mitre.org <mailto:d...@mitre.org>>
> Cc: snmp4j@agentpp.org <mailto:snmp4j@agentpp.org>
> Subject: Re: [SNMP4J] SNMP4J-SMI-PRO Missing artifact in Maven repository?
> 
> Don,
> 
> You are right. It was my fault. The classifier for the JAR with dependencies 
> was 'jar-with-dep’ in 1.9.1 instead the “standard” classifier 
> 'jar-with-dependencies’.
> I have fixed that with version 1.9.2 which is now available.
> 
> I took a long time to sort this out. Please excuse that. I had to understand 
> how you access the repository with the JAR first, in order to understand what 
> was going wrong. 
> 
> Best regards,
> Frank
> 
> 
> On 14. Sep 2017, at 15:23, Broderick, Don <d...@mitre.org 
> <mailto:d...@mitre.org>> wrote:
> 
> Frank,
> 
> We have a corporate repository using Artifactory that mirrors your 
> repository.  I can see the jar and pom files on our repository and the pom 
> file there is the same as the one on your repository.  I have been consulting 
> with some other people internally that are more experienced with Maven than I 
> am and have not been able to resolve the issue.  I am unable to directly go 
> to your repository due to the corporate firewall and security configuration 
> of our network.
> 
> Artifactory says to use "jar-with-dep" classifier to access this 
> artifact.  I have tried this and get missing artifact for 
> jasmi:jar:4.2.2
> 
> This is the only artifact I am having issues with and this is only since 
> 1.9.1.  If necessary I will have to see if I can manually load the jar on our 
> repository using a simple pom file that won't need the classifier.
> 
> Thanks,
> DonB
> 
> -Original Message-
> From: Frank Fock [mailto:f...@agentpp.com <mailto:f...@agentpp.com>]
> Sent: Monday, September 11, 2017 6:18 PM
> To: Broderick, Don <d...@mitre.org <mailto:d...@mitre.org>>
> Cc: snmp4j@agentpp.org <mailto:snmp4j@agentpp.org>
> Subject: Re: [SNMP4J] SNMP4J-SMI-PRO Missing artifact in Maven repository?
> 
> Hi Don,
> 
> I am confused. What Maven repository are you using? (And if it is not 
> oosnmp.net <http://

Re: [SNMP4J] SNMP4J-SMI-PRO Missing artifact in Maven repository?

2017-09-20 Thread Frank Fock

Don,

The JASMI classes are in the packages com.agentpp.smi and com.agentpp.smiparser 
for example.
They are all included in the jar-with-dependencies. 
Something must be still wrong with your pom.xml
A dependency to JASMI should not exists in that pom.xml nor induced due to 
transitive dependencies.

Best regards,
Frank

> On 20. Sep 2017, at 17:16, Broderick, Don <d...@mitre.org> wrote:
> 
> Frank,
> 
> No problem, I am grateful you are being so helpful!
> 
> Unfortunately I am getting "Missing artifact com.oosnmp:jasmi:jar:4.2.2" now. 
>  I examined our Artifactory and see  
> snmp4j-smi-pro-1.9.2-jar-with-dependencies.jar that is 893.84 KB.  When I 
> examine what is in the jar using the Artifactory web interface I see under 
> com it has agentpp, objectspace, and snmp4j.  Should it show oosnmp that has 
> jasmi also?
> 
> Thanks for all your help,
> DonB
> 
> -Original Message-
> From: Frank Fock [mailto:f...@agentpp.com] 
> Sent: Thursday, September 14, 2017 8:37 PM
> To: Broderick, Don <d...@mitre.org>
> Cc: snmp4j@agentpp.org
> Subject: Re: [SNMP4J] SNMP4J-SMI-PRO Missing artifact in Maven repository?
> 
> Don,
> 
> You are right. It was my fault. The classifier for the JAR with dependencies 
> was 'jar-with-dep’ in 1.9.1 instead the “standard” classifier 
> 'jar-with-dependencies’.
> I have fixed that with version 1.9.2 which is now available.
> 
> I took a long time to sort this out. Please excuse that. I had to understand 
> how you access the repository with the JAR first, in order to understand what 
> was going wrong. 
> 
> Best regards,
> Frank
> 
>> On 14. Sep 2017, at 15:23, Broderick, Don <d...@mitre.org> wrote:
>> 
>> Frank,
>> 
>> We have a corporate repository using Artifactory that mirrors your 
>> repository.  I can see the jar and pom files on our repository and the pom 
>> file there is the same as the one on your repository.  I have been 
>> consulting with some other people internally that are more experienced with 
>> Maven than I am and have not been able to resolve the issue.  I am unable to 
>> directly go to your repository due to the corporate firewall and security 
>> configuration of our network.
>> 
>> Artifactory says to use "jar-with-dep" classifier to access this 
>> artifact.  I have tried this and get missing artifact for 
>> jasmi:jar:4.2.2
>> 
>> This is the only artifact I am having issues with and this is only since 
>> 1.9.1.  If necessary I will have to see if I can manually load the jar on 
>> our repository using a simple pom file that won't need the classifier.
>> 
>> Thanks,
>> DonB
>> 
>> -Original Message-
>> From: Frank Fock [mailto:f...@agentpp.com]
>> Sent: Monday, September 11, 2017 6:18 PM
>> To: Broderick, Don <d...@mitre.org>
>> Cc: snmp4j@agentpp.org
>> Subject: Re: [SNMP4J] SNMP4J-SMI-PRO Missing artifact in Maven repository?
>> 
>> Hi Don,
>> 
>> I am confused. What Maven repository are you using? (And if it is not 
>> oosnmp.net, then how did you deploy SNMP4J-SMI-PRO there?)
>> 
>> Best regards,
>> Frank
>> 
>> 
>>> On 11. Sep 2017, at 18:29, Broderick, Don <d...@mitre.org> wrote:
>>> 
>>> Hi Frank,
>>> 
>>> When I added the classifier I know get the following error:
>>> Missing artifact 
>>> org.snmp4j.smi:snmp4j-smi-pro:jar:jar-with-dependencies:1.9.1
>>> 
>>>  
>>> org.snmp4j.smi
>>> snmp4j-smi-pro
>>> 1.9.1
>>> jar-with-dependencies
>>>  
>>> 
>>> Any other suggetions?
>>> 
>>> Thanks,
>>> DonB
>>> 
>>> -Original Message-
>>> From: Frank Fock [mailto:f...@agentpp.com]
>>> Sent: Thursday, September 07, 2017 1:29 AM
>>> To: Broderick, Don <d...@mitre.org>
>>> Cc: snmp4j@agentpp.org
>>> Subject: Re: [SNMP4J] SNMP4J-SMI-PRO Missing artifact in Maven repository?
>>> 
>>> Hi Don,
>>> 
>>> Please just add the following line to your dependency definition:
>>> 
>>> jar-with-dependencies
>>> 
>>> I have also added the complete example to the FAQ at:
>>> https://oosnmp.net/confluence/pages/viewpage.action?pageId=5799973
>>> 
>>> Best regards,
>>> Frank
>>> 
>>>> On 6. Sep 2017, at 13:31, Broderick, Don <d...@mitre.org> wrote:
>>>> 
>>>> Sorry if this is a duplicate, I am not sure if the first one went out.
>>

Re: [SNMP4J] SNMP4J-SMI-PRO Missing artifact in Maven repository?

2017-09-14 Thread Frank Fock
Don,

You are right. It was my fault. The classifier for the JAR with dependencies 
was  
'jar-with-dep’ in 1.9.1 instead the “standard” classifier 
'jar-with-dependencies’.
I have fixed that with version 1.9.2 which is now available.

I took a long time to sort this out. Please excuse that. I had to understand 
how you access the repository with the JAR first, in order to understand what 
was going wrong. 

Best regards,
Frank

> On 14. Sep 2017, at 15:23, Broderick, Don <d...@mitre.org> wrote:
> 
> Frank,
> 
> We have a corporate repository using Artifactory that mirrors your 
> repository.  I can see the jar and pom files on our repository and the pom 
> file there is the same as the one on your repository.  I have been consulting 
> with some other people internally that are more experienced with Maven than I 
> am and have not been able to resolve the issue.  I am unable to directly go 
> to your repository due to the corporate firewall and security configuration 
> of our network.
> 
> Artifactory says to use "jar-with-dep" classifier to access this artifact.  I 
> have tried this and get missing artifact for jasmi:jar:4.2.2
> 
> This is the only artifact I am having issues with and this is only since 
> 1.9.1.  If necessary I will have to see if I can manually load the jar on our 
> repository using a simple pom file that won't need the classifier.
> 
> Thanks,
> DonB
> 
> -Original Message-
> From: Frank Fock [mailto:f...@agentpp.com] 
> Sent: Monday, September 11, 2017 6:18 PM
> To: Broderick, Don <d...@mitre.org>
> Cc: snmp4j@agentpp.org
> Subject: Re: [SNMP4J] SNMP4J-SMI-PRO Missing artifact in Maven repository?
> 
> Hi Don,
> 
> I am confused. What Maven repository are you using? (And if it is not 
> oosnmp.net, then how did you deploy SNMP4J-SMI-PRO there?)
> 
> Best regards,
> Frank
> 
> 
>> On 11. Sep 2017, at 18:29, Broderick, Don <d...@mitre.org> wrote:
>> 
>> Hi Frank,
>> 
>> When I added the classifier I know get the following error:
>> Missing artifact 
>> org.snmp4j.smi:snmp4j-smi-pro:jar:jar-with-dependencies:1.9.1
>> 
>>   
>>  org.snmp4j.smi
>>  snmp4j-smi-pro
>>  1.9.1
>>  jar-with-dependencies
>>   
>> 
>> Any other suggetions?
>> 
>> Thanks,
>> DonB
>> 
>> -Original Message-
>> From: Frank Fock [mailto:f...@agentpp.com] 
>> Sent: Thursday, September 07, 2017 1:29 AM
>> To: Broderick, Don <d...@mitre.org>
>> Cc: snmp4j@agentpp.org
>> Subject: Re: [SNMP4J] SNMP4J-SMI-PRO Missing artifact in Maven repository?
>> 
>> Hi Don,
>> 
>> Please just add the following line to your dependency definition:
>> 
>> jar-with-dependencies
>> 
>> I have also added the complete example to the FAQ at:
>> https://oosnmp.net/confluence/pages/viewpage.action?pageId=5799973
>> 
>> Best regards,
>> Frank
>> 
>>> On 6. Sep 2017, at 13:31, Broderick, Don <d...@mitre.org> wrote:
>>> 
>>> Sorry if this is a duplicate, I am not sure if the first one went out.
>>> 
>>> Frank,
>>> 
>>> I only have this in my POM, if I don't have this I will need to manually 
>>> download and install the jar on each system.
>>>  
>>> org.snmp4j.smi
>>> snmp4j-smi-pro
>>> 1.9.1
>>>  
>>> 
>>> When I build with 1.8.0 it works fine and the POM for 1.8.0 in your Maven 
>>> repository is:
>>> 
>>> http://maven.apache.org/POM/4.0.0 
>>> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
>>> 4.0.0
>>> org.snmp4j.smi
>>> snmp4j-smi-pro
>>> 1.8.0
>>> SNMP4J-SMI-PRO MIB Parser API
>>> 
>>> The POM in your repository for 1.9.1 is very different and lists the 
>>> dependencies that are causing the problem.  Shouldn't the POM in the 
>>> repository for 1.9.1 be the same as the 1.8.0 one except for the version 
>>> number?
>>> 
>>> Thanks,
>>> DonB
>>> 
>>> -Original Message-
>>> From: Frank Fock [mailto:f...@agentpp.com] 
>>> Sent: Tuesday, August 29, 2017 5:13 PM
>>> To: Broderick, Don <d...@mitre.org>
>>> Cc: snmp4j@agentpp.org
>>> Subject: Re: [SNMP4J] SNMP4J-SMI-PRO Missing artifact in Maven repository?
>>> 
>>> Hi Don,
>>> The pom.xml your are using is wrong, i.e. remove all missing dependencies 
>>> and use the SNMP4J SMI PRO jar that comes with the distribution file.
>>> Best regards 

Re: [SNMP4J] SNMP4J-SMI-PRO Missing artifact in Maven repository?

2017-09-11 Thread Frank Fock
Hi Don,

I am confused. What Maven repository are you using? (And if it is not 
oosnmp.net, then how did you deploy SNMP4J-SMI-PRO there?)

Best regards,
Frank


> On 11. Sep 2017, at 18:29, Broderick, Don <d...@mitre.org> wrote:
> 
> Hi Frank,
> 
> When I added the classifier I know get the following error:
> Missing artifact org.snmp4j.smi:snmp4j-smi-pro:jar:jar-with-dependencies:1.9.1
> 
>
>   org.snmp4j.smi
>   snmp4j-smi-pro
>   1.9.1
>   jar-with-dependencies
>
> 
> Any other suggetions?
> 
> Thanks,
> DonB
> 
> -Original Message-
> From: Frank Fock [mailto:f...@agentpp.com] 
> Sent: Thursday, September 07, 2017 1:29 AM
> To: Broderick, Don <d...@mitre.org>
> Cc: snmp4j@agentpp.org
> Subject: Re: [SNMP4J] SNMP4J-SMI-PRO Missing artifact in Maven repository?
> 
> Hi Don,
> 
> Please just add the following line to your dependency definition:
> 
>  jar-with-dependencies
> 
> I have also added the complete example to the FAQ at:
> https://oosnmp.net/confluence/pages/viewpage.action?pageId=5799973
> 
> Best regards,
> Frank
> 
>> On 6. Sep 2017, at 13:31, Broderick, Don <d...@mitre.org> wrote:
>> 
>> Sorry if this is a duplicate, I am not sure if the first one went out.
>> 
>> Frank,
>> 
>> I only have this in my POM, if I don't have this I will need to manually 
>> download and install the jar on each system.
>>   
>>  org.snmp4j.smi
>>  snmp4j-smi-pro
>>  1.9.1
>>   
>> 
>> When I build with 1.8.0 it works fine and the POM for 1.8.0 in your Maven 
>> repository is:
>> 
>> http://maven.apache.org/POM/4.0.0 
>> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
>> 4.0.0
>> org.snmp4j.smi
>> snmp4j-smi-pro
>> 1.8.0
>> SNMP4J-SMI-PRO MIB Parser API
>> 
>> The POM in your repository for 1.9.1 is very different and lists the 
>> dependencies that are causing the problem.  Shouldn't the POM in the 
>> repository for 1.9.1 be the same as the 1.8.0 one except for the version 
>> number?
>> 
>> Thanks,
>> DonB
>> 
>> -Original Message-
>> From: Frank Fock [mailto:f...@agentpp.com] 
>> Sent: Tuesday, August 29, 2017 5:13 PM
>> To: Broderick, Don <d...@mitre.org>
>> Cc: snmp4j@agentpp.org
>> Subject: Re: [SNMP4J] SNMP4J-SMI-PRO Missing artifact in Maven repository?
>> 
>> Hi Don,
>> The pom.xml your are using is wrong, i.e. remove all missing dependencies 
>> and use the SNMP4J SMI PRO jar that comes with the distribution file.
>> Best regards 
>> Frank
>> 
>>> Am 24.08.2017 um 23:20 schrieb Frank Fock <f...@agentpp.com>:
>>> 
>>> Hi Don,
>>> 
>>> The artefacts you are missing are internal ones and are already included in 
>>> the SNMP4J-SMI-PRO 1.9.1 JAR file.Why do you think that those classes are 
>>> missing? Do you get any class not found exception?
>>> 
>>> Best regards,
>>> Frank
>>> 
>>> 
>>>> On 24. Aug 2017, at 17:19, Broderick, Don <d...@mitre.org> wrote:
>>>> 
>>>> I am trying to upgrade so v1.9.1 and get the following error:
>>>> com.oosnmp:jasmi:jar:4.2.2, com.oosnmp:valueconverter:jar:3.0.4: Could not 
>>>> find artifact
>>>> 
>>>> I have looked in https://oosnmp.net/dist/release/com/oosnmp/ and do not 
>>>> see jasmi, is this missing from the repository?
>>>> 
>>>> Thanks,
>>>> DonB
>>>> ___
>>>> SNMP4J mailing list
>>>> SNMP4J@agentpp.org
>>>> https://oosnmp.net/mailman/listinfo/snmp4j
>>> 
>>> ___
>>> SNMP4J mailing list
>>> SNMP4J@agentpp.org
>>> https://oosnmp.net/mailman/listinfo/snmp4j
>> 
> 

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] SNMP4J-SMI-PRO Missing artifact in Maven repository?

2017-08-29 Thread Frank Fock
Hi Don,
The pom.xml your are using is wrong, i.e. remove all missing dependencies and 
use the SNMP4J SMI PRO jar that comes with the distribution file.
Best regards 
Frank

> Am 24.08.2017 um 23:20 schrieb Frank Fock <f...@agentpp.com>:
> 
> Hi Don,
> 
> The artefacts you are missing are internal ones and are already included in 
> the SNMP4J-SMI-PRO 1.9.1 JAR file.Why do you think that those classes are 
> missing? Do you get any class not found exception?
> 
> Best regards,
> Frank
> 
> 
>> On 24. Aug 2017, at 17:19, Broderick, Don <d...@mitre.org> wrote:
>> 
>> I am trying to upgrade so v1.9.1 and get the following error:
>> com.oosnmp:jasmi:jar:4.2.2, com.oosnmp:valueconverter:jar:3.0.4: Could not 
>> find artifact
>> 
>> I have looked in https://oosnmp.net/dist/release/com/oosnmp/ and do not see 
>> jasmi, is this missing from the repository?
>> 
>> Thanks,
>> DonB
>> ___
>> SNMP4J mailing list
>> SNMP4J@agentpp.org
>> https://oosnmp.net/mailman/listinfo/snmp4j
> 
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] SNMP4J-SMI-PRO Missing artifact in Maven repository?

2017-08-24 Thread Frank Fock
Hi Don,

The artefacts you are missing are internal ones and are already included in the 
SNMP4J-SMI-PRO 1.9.1 JAR file.Why do you think that those classes are missing? 
Do you get any class not found exception?

Best regards,
Frank


> On 24. Aug 2017, at 17:19, Broderick, Don  wrote:
> 
> I am trying to upgrade so v1.9.1 and get the following error:
> com.oosnmp:jasmi:jar:4.2.2, com.oosnmp:valueconverter:jar:3.0.4: Could not 
> find artifact
> 
> I have looked in https://oosnmp.net/dist/release/com/oosnmp/ and do not see 
> jasmi, is this missing from the repository?
> 
> Thanks,
> DonB
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] report bug for snmp4j

2017-08-22 Thread Frank Fock
Hi Vincent 
I will fix it, but I think the error must be in the input stream, because the 
API clearly states, that if the length is 0, then 0 bytes are returned (and not 
-1 what you observed). Of course, the agent might also be the problem by 
encoding a wrong length.
Best regards 
Frank

> Am 22.08.2017 um 10:47 schrieb Vincent Zhang :
> 
> Hi Dear,
> I am not sure this is the correct mail address to report bug, please 
> I found a bug for snmp4j.  This is introduced in the latest snmp4j 2.5.7 
> release.
> 
> Behaviour: 
> When server returns an empty string for an oid, the 2.5.7 snmp4j will fail 
> with fail with exception while the older jars can work. 
> 
> Cause
> In the latest release, you have improved the performance for BRE. See the 
> line  799, the length will be 0 if the stream is already empty. In this case, 
> consume stream line 803 will always get -1, as a result it will fail to pass 
> the validation in line 804 and an exception will be thrown. 
> 
> 
> 
> Suggested Fix
> When the stream is already empty, we need not consume the stream anymore, 
> instead we can return the empty byte array as the previous snmp4j release did.
> 
> Why I am concerning this
> I am not sure if the snmp protocol allows server return an empty string for 
> an oid, but we do have related case in our product. My customers may have 
> snmp server returning empty string, so currently I am using the 2.5.6 snmp4j 
> as workaround. But it will be fantacy if the latest snmp4j release can 
> support empty string as response.
> 
> 
> Cheers.
> 
> Vincent
___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


[SNMP4J] New Releases: SNMP4J 2.5.7, SNMP4J-SMI-PRO 1.9.1, MIB Designer 4.1.6, MIB Explorer 4.2.0

2017-08-17 Thread Frank Fock
Hi,

New releases of SNMP4J, SNMP4JSMI-PRO, MIB Designer, and MIB Explorer are 
available for download.
Besides small fixes for the MIB parser, the MIB Designer and MIB Explorer 
releases are based on a new installation packing method and can now better 
detect if individual files need to be updated during startup.

For SNMP4J TableUtils and MIB Explorer the retrieval of wide tables (many 
columns) should be faster now.
In SNMP4J, you need to activate the new behaviour in TableUtils. For MIB 
Explorer it is the new default.
 
Here are the release notes:

SNMP4J Version 2.5.7:

* Fixed [SFJ-143]: TableUtils may return two or more TableEvents for the same 
row index if
  TableUtils is configured to request less columns in a PDU than provided for 
table retrieval and
  the agent returns the later sent columns earlier than the first sent.
* Added: Snmp.setMessageDispatcher(..).
* Added: BER BigInteger encoding and decoding necessary to decode/encode 
Diffie-Hellman parameters.
* Added: TLSTMExtendedTrustManager and corresponding Factory class.
* Fixed: Source object for ResponseEvents propagated from the ReportHandler of 
Snmp
  (was ReportHandler is now the Snmp class).
* Improved: Defined constant for AuthMD5 key length.
* Added: Supporting functions and constants for Diffie Hellman USM key 
exchange. DH key exchange
  will be available in SNMP4J-Agent 3.0.
* Improved: Performance of BER octet string decoding.

SNMP4J-SMI-PRO 1.9.1: Version 1.9.1 (Requires SNMP4J 2.5.6 or later)

* Fixed [SFJ-144]: MIB compiler does not check if an object is accessible in
  NOTIFICATION-TYPE's OBJECTS clause.
* Fixed [SFJ-146]: SNMP4J-SMI allows empty BITS construct in SYNTAX clauses 
although
  this is not allowed by RFC 2578.

MIB Designer 4.1.6:

* Fixed [MDS-44]: When switching between MIB module tabs old errors could be
  displayed that are already fixed.
* Fixed [MDS-47]: Mac OS X: UI hangs when trying to import/compile MIB modules 
using
  Aqua look file dialog for a second time.
* Fixed [MDS-36]: Installer did not check if already installed file is the same.
* Improved [MDS-46]: Multi-threaded RFC extraction
* Improved [MDS-48]: Enhanced copy of MIB nodes with paste on leaf nodes 
like
  OBJECT-TYPE, TRAP-TYPE, NOTIFICATION-TYPE with "insert before" behavior.

MIB Explorer 4.2.0:

[2017-08-17] MIB Explorer 4.2.0

* Fixed [MXP-65]: Mac OS X with system look (Nimbus): Dialog to choose
  installation directory is not shown and application hangs.
* Added [MXP-66]: Multi-threaded column retrieval for wide tables (enabled
  by default, can be disabled in Preferences->General).
* Improved: Installer now checks if already installed file is the same and
  skips it during installation/upgrade automatically. 
* Improved: Online help updated.
* Known issue: Context help is not working under Mac OS X with Nimbus look

Frank Fock



 


___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Issue when a PDU contains two SETs for a table row status with a value of 6 to destroy when one row exists and the other row does not exist

2017-08-10 Thread Frank Fock
Hi Don,

This is obviously a bug and will be fixed with the next SNMP4J-Agent release.

Best regards,
Frank


> On 9. Aug 2017, at 16:54, Broderick, Don  wrote:
> 
> SNMP4J version 2.5.6
> SNMP4J-Agent version 2.6.0
> 
> I have discovered the following behavior inconsistency where I would expect 
> no error to be returned in both cases.
> 
> When a PDU is sent containing one SET of a row status to 6 for destroy for a 
> row that exists the row is destroyed and no error is returned.  Performing 
> the same operation in a separate PDU for a row that does not exist again 
> returns no error.  When a PDU containing 2 SETs, one for a row that exists 
> and one for a row that does not exist (both in the same table) a commit 
> failed error is returned and the row that existed is destroyed.
> 
> In the line highlighted below of DefaultMOTable the variable "row" has a null 
> value when this event occurs and causes a null pointer exception.
> 
>  public void commit(SubRequest request) {
>OID cellOID = request.getVariableBinding().getOid();
>MOTableCellInfo cell = getCellInfo(cellOID);
>MOMutableColumn col = (MOMutableColumn) getColumn(cell.getColumn());
>if (logger.isDebugEnabled()) {
>  logger.debug("Committing sub-request ("+
>   request.getVariableBinding()+") for column: "+col);
>}
>// Make sure changes are atomic -> sync whole table model
>synchronized (model) {
>  R row;
>  if (hasNewRows(request.getRequest())) {
>row = getNewRows(request.getRequest()).get(cell.getIndex());
>// check if row has been added already
>if (!model.containsRow(row.getIndex())) {
>  if (!addRow(row)) {
>request.setErrorStatus(PDU.resourceUnavailable);
>return;
>  }
>}
>  }
>  else {
>row = model.getRow(cell.getIndex());
>  }
> 
> -DonB
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] How to cancel a async request when the Response Event is from a PDU.Report?

2017-08-02 Thread Frank Fock
Hello Nelson,

You are right, not using Snmp.this at the below quoted code location was an 
error.
I have corrected this for the next major release.

However, this should not induce a real memory leak, because the ending message 
context is removed after the timeout anyway. Nevertheless, for some time, more 
objects exists in memory then required.

As workaround, you can use the user object in the asynchronous request to 
provide the Snmp instance reference to the async request listener.

Best regards,
Frank


> On 2. Aug 2017, at 12:29, Nelson Silva  wrote:
> 
> Hello,
> 
> I noticed a memory leak when i'm using async requests and i have a lot of
> PDU.Reports.
> 
> 
> From the java doc i found that i need to cancel the request however the
> source from the ResponseEvent is a ReportHandler and i don't have access to
> the Snmp instance.
> 
> // Always cancel async request when response has been received
> *   // otherwise a memory leak is created! Not canceling a request
> *   // immediately can be useful when sending a request to a broadcast
> *   // address.
> *   ((Snmp)event.getSource()).cancel(event.getRequest(), this);
> 
> 
> I was expecting the source to be the Snmp instance.
> 
> On ReportProcessor we have this:
> 
> // return report
> reqListener.onResponse(new ResponseEvent(this,
>e.getPeerAddress(),
>reqPDU,
>pdu,
>reqUserObject));
> 
> 
> I believe it should be
> 
> reqListener.onResponse(new ResponseEvent(*Snmp.**this*,
> 
>e.getPeerAddress(),
>reqPDU,
>pdu,
>reqUserObject));
> 
> regards,
> 
> This happens in every versions i have tested, 1.11.2 to 2.5.6
> 
> Nelson Silva
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] TCP Socket in SYN_RECV when sending V3 traps

2017-06-20 Thread Frank Fock
Hi Neeraj,

As I wrote before, you first have to understand the engine ID concept.
Otherwise, you will not get it running (unless by accident).

For INFORM you have to specify the engine ID of the NET-SNMP target engine as 
authoritative engine ID.
You first have to discover it or let SNMP4J discover it.

Best regards,
Frank


> On 19. Jun 2017, at 04:37, Neeraj Vaidya <neeraj.vai...@yahoo.co.in> wrote:
> 
> Thanks Frank. So how do I get the authoritativeEngineId at runtime ?
> 
> The remote snmptrap collector has provided me with a user id of myuser and 
> engine id of 0102030405. This is via an email correspondence which I had with 
> the administrators of the remote system.
> 
> When I use the SnmpRequest tool bundled as part of snmp4j, which engineId 
> parameters do I need to set  when sending an INFORM ?
> -l , -e , -E ?
> 
> I tried setting just the -e flag with 0102030405 on the command line of this 
> tool and still at the receiving end i.e. in the logs of the net-snmp trap 
> collector I see a message of "no match on engineID (80 00 88 .)"
> Basically, the snmptrapd collector is not using 0102030405 for USM engine ID 
> matching purposes. 
> 
> If I were to send just a coldStart trap with the SnmpRequest tool bundled in 
> snmp4j distribution, what command line do I need to use ?
> My engine ID which I can successfully specify as the authoritativeEngineId 
> via -e flag is 0102030405, when using the snmptrap utility.
> I was of the opinion that the same -e flag can be used in SnmpRequest utility 
> as well.
> 
> Regards,
> Neeraj
> 
> 
> On Mon, 19/6/17, Frank Fock <f...@agentpp.com> wrote:
> 
> Subject: Re: [SNMP4J] TCP Socket in SYN_RECV when sending V3 traps
> To: "Neeraj Vaidya" <neeraj.vai...@yahoo.co.in>
> Cc: snmp4j@agentpp.org
> Date: Monday, 19 June, 2017, 8:31 AM
> 
> Hi Neeraj,
> 
> Please make sure, that you have understand the
> engine ID and context 
> engine ID terms and
> usages.
> It seems that you mix up things.
> Your example below cannot work for 
> INFORM
> PDUs, because
> you need to specify the
> authoritative engine ID as context engine ID 
> then. This is the
> INFORM
> *receivers* engine ID.
> Instead, you use the
> senders engine ID. The receiver should drop/ignore 
> such an INFORM message with
> unknownPduHandles counter increased.
> 
> Best regards,
> Frank
> 
> Am
> 16.06.2017 um 22:41 schrieb Neeraj Vaidya:
>> Hi Frank,
>> Coming back
> to this conversation as I have been away from this task due
> to other project commitments.
>> In the
> example below, I have also noticed that if I change the PDU
> type to INFORM, the receiving snmptrap collector (which is
> net-snmp snmptrapd) fails to match the engine id. It picks
> up something totally different from what I am setting
> below.
>> Is there some other place where
> I need to set the engineId ?
>> 
>> Regards,
>> Neeraj
>> 
>> Sent from my
> iPhone
>> 
>> On 24 May
> 2017, at 16:44, Frank Fock <f...@agentpp.com>
> wrote:
>> 
>>>> 
>  Code Start
> 
>>>> 
>>>>
> Address address =
> GenericAddress.parse("tcp:rhelhost1/1163");
>>>> 
>>>>
>  try {
>>>> 
> TransportMapping transportMapping = new
> DefaultTcpTransportMapping();
>>>>  
>transportMapping.listen();
>>>>  
>>>>  Snmp snmp = new
> Snmp(transportMapping);
>>>> 
>>>>  USM usm = new
> USM(SecurityProtocols.getInstance(),
>>>>
>new
> OctetString(MPv3.createLocalEngineID()), 0);
>>>>  
>>>> 
> SecurityModels.getInstance().addSecurityModel(usm);
>>>> 
>>>>
>  //snmp.listen(); > Do I need to use this
> invocation ??
>>>> 
>>>>  byte[] b = (new
> BigInteger("0102030405",16)).toByteArray();
>>>> 
>>>>
>  snmp.getUSM().addUser(new
> OctetString("snmp4j"),
>>>>  new
> UsmUser(new OctetString("snmp4j"), AuthMD5.ID, new
> OctetString("snmp4j"), PrivDES.ID, new
> OctetString("snmp4j")));
>>>>  
>>>>  UserTarget
> target = new UserTarget();
>>

Re: [SNMP4J] TCP Socket in SYN_RECV when sending V3 traps

2017-06-18 Thread Frank Fock

Hi Neeraj,

Please make sure, that you have understand the engine ID and context 
engine ID terms and usages.
It seems that you mix up things. Your example below cannot work for 
INFORM PDUs, because
you need to specify the authoritative engine ID as context engine ID 
then. This is the

INFORM *receivers* engine ID.
Instead, you use the senders engine ID. The receiver should drop/ignore 
such an INFORM message with

unknownPduHandles counter increased.

Best regards,
Frank

Am 16.06.2017 um 22:41 schrieb Neeraj Vaidya:

Hi Frank,
Coming back to this conversation as I have been away from this task due to 
other project commitments.
In the example below, I have also noticed that if I change the PDU type to 
INFORM, the receiving snmptrap collector (which is net-snmp snmptrapd) fails to 
match the engine id. It picks up something totally different from what I am 
setting below.
Is there some other place where I need to set the engineId ?

Regards,
Neeraj

Sent from my iPhone

On 24 May 2017, at 16:44, Frank Fock <f...@agentpp.com> wrote:


 Code Start 


   Address address = GenericAddress.parse("tcp:rhelhost1/1163");

try {
TransportMapping transportMapping = new 
DefaultTcpTransportMapping();
transportMapping.listen();

Snmp snmp = new Snmp(transportMapping);


USM usm = new USM(SecurityProtocols.getInstance(),
  new 
OctetString(MPv3.createLocalEngineID()), 0);

SecurityModels.getInstance().addSecurityModel(usm);


//snmp.listen(); > Do I need to use this invocation ??

byte[] b = (new BigInteger("0102030405",16)).toByteArray();

snmp.getUSM().addUser(new OctetString("snmp4j"),
new UsmUser(new OctetString("snmp4j"), AuthMD5.ID, new 
OctetString("snmp4j"), PrivDES.ID, new OctetString("snmp4j")));

UserTarget target = new UserTarget();

target.setAddress(address);

target.setRetries(1);
target.setTimeout(5000);
target.setVersion(SnmpConstants.version3);
target.setSecurityLevel(SecurityLevel.AUTH_NOPRIV);
target.setSecurityName(new OctetString("snmp4j"));

// create the PDU

ScopedPDU pdu = new ScopedPDU();
long sysUpTime = Instant.now().getEpochSecond();
//pdu.add(new VariableBinding(SnmpConstants.sysUpTime),new 
OctetString(new Date().toString()));
pdu.setType(ScopedPDU.TRAP);
pdu.add(new VariableBinding(SnmpConstants.sysUpTime, new 
TimeTicks(sysUpTime)));
pdu.add(new VariableBinding(SnmpConstants.snmpTrapOID, 
SnmpConstants.linkUp));
pdu.setContextEngineID(new OctetString().fromByteArray(b));
snmp.setLocalEngine(b, 0, 0);
// send the PDU

ResponseEvent response = null;


response = snmp.send(pdu, target);

Thread.sleep(10); // This Sleep somehow allows the entire TCP 3-way 
handshake to occur without terminating the program

snmp.close();

} catch (IOException e) {
e.printStackTrace();
} catch (InterruptedException e) {
e.printStackTrace();
}
 Code End  
---


--
---
AGENT++
Maximilian-Kolbe-Str. 10
73257 Koengen, Germany
https://agentpp.com
Phone: +49 7024 8688230
Fax:   +49 7024 8688231

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] TCP Socket in SYN_RECV when sending V3 traps

2017-05-25 Thread Frank Fock
Hi Neeraj,

If you do not like the behaviour of the DefaultTcpTransportMapping, then you 
can implement your own without using NIO/multi-threading. Closing a connection 
while a message is being sent even if the message has already been accepted by 
the Java TCP stack, is always risky. The sent message could be lost and has to 
be recent - if you have closed the connection meanwhile, the resending might 
not take place anymore.
This is totally independent from the SNMP4J DefaultTcpTransportMapping 
implementation.

Best regards,
Frank

> On 25. May 2017, at 22:57, Neeraj Vaidya  wrote:
> 
> Thanks Fabrice. Still I am not convinced why the DefaultTcpTransportMapping 
> class should not complete the connection and send before the next line of 
> code I.e. SNMP.close is called.
> 
> I believe the ServerThread is being started using run method and not start 
> method of Runnable. Shouldn't this just run as a normal method without 
> spawning any Thread and thus wait for completing what it is supposed to do 
> before terminating the connection.
> 
> Regards,
> Neeraj
> 
>> On 25 May 2017, at 20:25, Fabrice Bacchella  
>> wrote:
>> 
>> 
>>> Le 24 mai 2017 à 09:50, Neeraj Vaidya  a écrit :
>>> 
>>> Hi Frank,
>>> Thanks for your reply I will try with UDP and let you know.
>>> We have a use case to just use TCP owing to the large size of the payload 
>>> I.e. because of MTU limitation of UDP.
>> 
>> UDP packet can be bigger than MTU. They just will be fragmented.
>> 
> 

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] TCP Socket in SYN_RECV when sending V3 traps

2017-05-24 Thread Frank Fock
Hi Neeraj,

A trap is an unconfirmed PDU. Thus, it is send and the application/SNMP API 
will not wait for any response. 
In you case, the Java TCP layer accepted the message, but without the sleep 
statement, the TCP layer will not be able to actually send the message before 
you close the connection. 

Summarised it is not a bug in SNMP4J but a shortcoming in your code. Why are 
you using TCP for traps? UDP will be much better for this use case and you will 
not observe this issue with UDP.

Best regards,
Frank

> On 23. May 2017, at 20:33, Neeraj Vaidya  wrote:
> 
> Hi,
> I have written the following code to send v3 traps to a trap collector daemon 
> (specifically snmptrapd from net-snmp library), which is running on a TCP 
> port.
> The snmptrapd is running on a RHEL server. And my code is also running on 
> that same host.
> All I am trying at the moment is to include the linkup trapOID and the 
> sysUpTime in the PDU (ScopedPDU to be precise).
> 
> In an Eclipse IDE or even by invoking my application via a command line, when 
> I "Run" the application, traps do not get sent out, however, when I "Debug" 
> the application in Eclipse IDE, the traps DO get sent successfully.
> 
> Upon analyzing further, I noticed that when I "Run" the application, the 
> application completes (but without sending TRAPS) without any error, however, 
> the socket that got created as a result of the Snmp.send() invocation, is in 
> a SYN_RECV state. 
> 
> This lead me to think that it is possible that the ServerThread in the 
> DefaultTcpTransportMapping class is not allowed to complete the 3-way 
> handshake and thus the sending of the message, before the flow moves on to 
> the next statement in the code.
> 
> So, I then added a Thread.Sleep of even 10ms, immediately after the 
> Snmp.send() method invocation, and Now the trap gets sent out (both when I 
> "Run" the application via command-line/Eclipse OR even when I debug it in 
> Eclipse).
> 
> The code shown below is the one which contains the Thread.Sleep statement and 
> is a working version of the code.
> 
> Is this a bug in the SNMP4J library or am I doing something wrong in my code 
> ? Why does the trap not get sent out without adding the Sleep.
> Shouldn't the TCP connection (& send) be allowed to complete before the code 
> moves on to the next statement in the program ?
> 
>  Code Start 
>  
> 
>Address address = GenericAddress.parse("tcp:rhelhost1/1163");
> 
>   try {
>   TransportMapping transportMapping = new 
> DefaultTcpTransportMapping();
>   transportMapping.listen();  
>   
>   Snmp snmp = new Snmp(transportMapping);
> 
>   USM usm = new USM(SecurityProtocols.getInstance(),
>   new 
> OctetString(MPv3.createLocalEngineID()), 0);
>   
>   SecurityModels.getInstance().addSecurityModel(usm);
> 
>   //snmp.listen(); > Do I need to use this invocation 
> ??
> 
>   byte[] b = (new 
> BigInteger("0102030405",16)).toByteArray();
> 
>   snmp.getUSM().addUser(new OctetString("snmp4j"),
>   new UsmUser(new OctetString("snmp4j"), 
> AuthMD5.ID, new OctetString("snmp4j"), PrivDES.ID, new 
> OctetString("snmp4j")));
>   
>   UserTarget target = new UserTarget();
>   
>   target.setAddress(address);
>   target.setRetries(1);
>   target.setTimeout(5000);
>   target.setVersion(SnmpConstants.version3);
>   target.setSecurityLevel(SecurityLevel.AUTH_NOPRIV);
>   target.setSecurityName(new OctetString("snmp4j"));
>   
>   // create the PDU
>   ScopedPDU pdu = new ScopedPDU();
>   long sysUpTime = Instant.now().getEpochSecond();
>   //pdu.add(new 
> VariableBinding(SnmpConstants.sysUpTime),new OctetString(new 
> Date().toString()));
>   pdu.setType(ScopedPDU.TRAP);
>   pdu.add(new VariableBinding(SnmpConstants.sysUpTime, 
> new TimeTicks(sysUpTime)));
>   pdu.add(new VariableBinding(SnmpConstants.snmpTrapOID, 
> SnmpConstants.linkUp));
>   pdu.setContextEngineID(new 
> OctetString().fromByteArray(b));
>   snmp.setLocalEngine(b, 0, 0);
>   // send the PDU 
>   
>   ResponseEvent response = null;
> 
>   

Re: [SNMP4J] TableUtils.getTable() null pointer exception

2017-04-12 Thread Frank Fock
Hi Stuart,

What SNMP4J version are you using?

Best regards,
Frank


> On 12. Apr 2017, at 18:19, Stuart Johnston  wrote:
> 
> Using TableUtils.getTable() can cause a null pointer exception when used with 
> SNMPv3, when the PDU is created. DefaultPDUFactory.createPDU() is called, 
> which calls 
> applyContextInfoToScopedPDU() to set the engine ID. If the engine ID has not 
> previously been set in the DefaultPDUFactory, then an NPE will be thrown. In 
> fact, we really don’t want to have to specify the engine ID in the PDU 
> factory, since snmp4j will automatically discover it and apply it if it isn’t 
> set. The solution is to create a DefaultPDUFactory with an empty (rather than 
> null) engine ID. In this cause, everything works as expected.
> 
> The immediate workaround is to call new DefaultPDUFactory(PDU.GET) rather 
> than new DefaultPDUFactory(). new DefaultPDUFactory(PDU.GET) will create an 
> empty, rather than null engine ID. I think the correct, long term fix is to 
> change the constructor to:
> 
> /**
>  * Creates a PDU factory for the {@link PDU#GET} PDU type.
>  */
> public DefaultPDUFactory() {
> this(PDU.GET);
> }
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] interesting

2017-04-12 Thread Frank Fock
Hi,

I have unsubscribed and blocked this user, please ignore this posting.

Best regards,
Frank Fock
___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Unsupported PDU type

2017-04-06 Thread Frank Fock
You can yourself “sniff” into incoming packets using a TransportListener and 
then change (fix) the PDU type on-the-fly in the message byte stream. 
Afterwards, SNMPJ4 will accept the PDU.


> On 5. Apr 2017, at 22:23, Yuri Krysko <yuri.kry...@mcdean.com> wrote:
> 
> Thank you Frank! I thought of it as well. It looks like one of the SNMP
> clients that I am listening for traps from is badly implemented. Is there
> any way to ignore this message and/or force snmp4j to process the trap as
> SNMPv1 if the client sends such rogue messages?
> 
> I used wireshark to sniff communications between my IDE and remote SNMP
> client, and I can confirm this nonsense: the trap comes as v2c, but it is
> actually V1TRAP type.
> 
> On 4/5/17, 4:03 PM, "Frank Fock" <f...@agentpp.com <mailto:f...@agentpp.com>> 
> wrote:
> 
>> Hi Yuri,
>> 
>> The PDU is a v2c PDU which does not allow SNMPv1 TRAP!
>> 
>> Best regards,
>> Frank
>> 
>>> On 5. Apr 2017, at 17:37, Yuri Krysko <yuri.kry...@mcdean.com> wrote:
>>> 
>>> Hello All,
>>> 
>>> I am getting the following IOException when trying to decode received
>>> SNMP trap
>>> 
>>> 
>>> java.io.IOException: Unsupported PDU type: -92
>>> 
>>> at org.snmp4j.PDU.decodeBER(PDU.java:566)
>>> 
>>> at org.snmp4j.mp.MPv2c.prepareDataElements(MPv2c.java:201)
>>> 
>>> at
>>> org.snmp4j.MessageDispatcherImpl.dispatchMessage(MessageDispatcherImpl.ja
>>> va:278)
>>> 
>>> at
>>> org.snmp4j.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.jav
>>> a:387)
>>> 
>>> at
>>> org.snmp4j.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.jav
>>> a:347)
>>> 
>>> at
>>> org.snmp4j.util.MultiThreadedMessageDispatcher$MessageTask.run(MultiThrea
>>> dedMessageDispatcher.java:182)
>>> 
>>> at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:260)
>>> 
>>> 
>>> To my knowledge, PDU type -92 is supported and denotes V1TRAP. Could
>>> anyone advise?
>>> 
>>> Thanks !
>>> 
>>> 
>>> 
>>> LEGAL DISCLAIMER: M.C. Dean, Inc. and its subsidiaries considers this
>>> e-mail and any files transmitted with it to be protected, proprietary or
>>> privileged information intended solely for the use of the named
>>> recipient(s). Any disclosure of this material or the information
>>> contained herein, in whole or in part, to anyone outside of the intended
>>> recipient or affiliates is strictly prohibited. M. C. Dean, Inc. accepts
>>> no liability for the content of this e-mail or for the consequences of
>>> any actions taken on the basis of the information contained in it,
>>> unless that information is subsequently confirmed in writing. Employees
>>> of M.C. Dean, Inc. are instructed not to infringe on any rights of the
>>> recipient; any such communication violates company policy. If you are
>>> not the intended recipient, any disclosure, copying, distribution, or
>>> action taken or omitted in reliance on this information is strictly
>>> prohibited by M.C. Dean, Inc.; please notify the sender immediately by
>>> return e-mail, delete this communication and destroy all copies.
>>> ___
>>> SNMP4J mailing list
>>> SNMP4J@agentpp.org
>>> https://oosnmp.net/mailman/listinfo/snmp4j
>> 
> 
> 
> 
> 
> LEGAL DISCLAIMER: M.C. Dean, Inc. and its subsidiaries considers this e-mail 
> and any files transmitted with it to be protected, proprietary or privileged 
> information intended solely for the use of the named recipient(s). Any 
> disclosure of this material or the information contained herein, in whole or 
> in part, to anyone outside of the intended recipient or affiliates is 
> strictly prohibited. M. C. Dean, Inc. accepts no liability for the content of 
> this e-mail or for the consequences of any actions taken on the basis of the 
> information contained in it, unless that information is subsequently 
> confirmed in writing. Employees of M.C. Dean, Inc. are instructed not to 
> infringe on any rights of the recipient; any such communication violates 
> company policy. If you are not the intended recipient, any disclosure, 
> copying, distribution, or action taken or omitted in reliance on this 
> information is strictly prohibited by M.C. Dean, Inc.; please notify the 
> sender immediately by return e-mail, delete this communication and destroy 
> all copies.

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Unsupported PDU type

2017-04-05 Thread Frank Fock
Hi Yuri,

The PDU is a v2c PDU which does not allow SNMPv1 TRAP!

Best regards,
Frank

> On 5. Apr 2017, at 17:37, Yuri Krysko  wrote:
> 
> Hello All,
> 
> I am getting the following IOException when trying to decode received SNMP 
> trap
> 
> 
> java.io.IOException: Unsupported PDU type: -92
> 
> at org.snmp4j.PDU.decodeBER(PDU.java:566)
> 
> at org.snmp4j.mp.MPv2c.prepareDataElements(MPv2c.java:201)
> 
> at 
> org.snmp4j.MessageDispatcherImpl.dispatchMessage(MessageDispatcherImpl.java:278)
> 
> at 
> org.snmp4j.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.java:387)
> 
> at 
> org.snmp4j.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.java:347)
> 
> at 
> org.snmp4j.util.MultiThreadedMessageDispatcher$MessageTask.run(MultiThreadedMessageDispatcher.java:182)
> 
> at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:260)
> 
> 
> To my knowledge, PDU type -92 is supported and denotes V1TRAP. Could anyone 
> advise?
> 
> Thanks !
> 
> 
> 
> LEGAL DISCLAIMER: M.C. Dean, Inc. and its subsidiaries considers this e-mail 
> and any files transmitted with it to be protected, proprietary or privileged 
> information intended solely for the use of the named recipient(s). Any 
> disclosure of this material or the information contained herein, in whole or 
> in part, to anyone outside of the intended recipient or affiliates is 
> strictly prohibited. M. C. Dean, Inc. accepts no liability for the content of 
> this e-mail or for the consequences of any actions taken on the basis of the 
> information contained in it, unless that information is subsequently 
> confirmed in writing. Employees of M.C. Dean, Inc. are instructed not to 
> infringe on any rights of the recipient; any such communication violates 
> company policy. If you are not the intended recipient, any disclosure, 
> copying, distribution, or action taken or omitted in reliance on this 
> information is strictly prohibited by M.C. Dean, Inc.; please notify the 
> sender immediately by return e-mail, delete this communication and destroy 
> all copies.
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Bug in OID class

2017-02-06 Thread Frank Fock

Hi Steffen,

Thanks for the bug report. Will be fixed very soon with SNMP4J 2.5.5.

Best regards,
Frank

Am 06.02.2017 um 17:17 schrieb Steffen Brüntjen:

Hi!

I found a problem in the OID class. The nextPeer() method runs into a 
StackOverflowError. The method:

   public final OID nextPeer() {
 OID next = new OID(this);
 if ((next.size() > 0) && (last() != MAX_SUBID_VALUE)) {
   next.set(next.size()-1, last()+1);
 }
 else if (next.size() > 1) {
   next.trim(1);
   next = nextPeer();
 }
 return next;
   }


The fix:

- next = nextPeer()
+ next = next.nextPeer();


Here's a test case:

   @Test
   public void testNextPeer() {
 OID oid = new OID(new int[] { 1, 0x });
 oid.nextPeer();
   }


Best regards,
Steffen Brüntjen
___
SNMP4J mailing list
SNMP4J@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

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] SNMPv3 Notifications

2017-02-02 Thread Frank Fock
Hi Ron,

What you observe is correct and matches the SNMP standard requirements.
In SNMP, the trap receiver is authoritative. That is, the sender must use the 
SNMP(v3) user name and password the receiver knows and accepts.

Hope this helps anyway ;-)

Best regards,
Frank


> On 2 Feb 2017, at 22:06, Ronald Braswell  wrote:
> 
> I have a device that hard codes a UsmUser name nameB and sends it with
> SNMPv3 notifications noAuthNoPriv (can't change the level).  I did
> configure the device for SNMPv3 with a different user name nameA and the
> passphrases for priv and auth.   I can poll the device using nameA.   But I
> cannot send a notification from the device using SNMPv3. which uses nameB.
>  Is this because with SNMPv3 notifications there must be a UsmUser for
> nameB registered in the USM UsmUserTable associated with the snmp instance
> (I have one instance for traps and polls)?   Of course I can send a V1 trap
> using a trap community string of anything and it is delivered.   But the
> SNMP4J library will not deliver the SNMPv3 notification with  nameB to
> processPdu(CommandResponderEvent evt).
> 
> I configured the SNMP manager (my code) with nameB using the same authPriv
> as for nameA and set up the same user on the target device with the same
> security parameters.  Now when the device sends an SNMPv3 notification USM,
> name=nameB, noAuthNoPriv the SNMP4J software forwards the notification to
> me whereas it did not before.
> 
> Do I need to add a nameB UsmUser noAuthNoPriv to the UsmUserTable just to
> receive SNMPv3 traps from the device which hard codes the nameB for the
> UsmUser name?
> 
> Ron
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Set USM security parameters per request

2017-02-01 Thread Frank Fock
Hi Ron,

You can remove the time information for a specific target by calling
UsmTimeTable.remove(engineID).

You can get the engineID by calling MPv3.getEngineID(Address).

Best regards,
Frank

> On 2 Feb 2017, at 00:01, Ronald Braswell  wrote:
> 
> I have code which calls USM.removeEngineTime(engineID) that I use to enable
> the re-discovery process again for a device with which my SNMP manager has
> lost communications.   This works for several devices.   But one device has
> problems.
> 
> If I call USM.removeEngineTime(engineID) for this device before it comes
> back up, when it does come back up the requests go out with a reboots
> parameter of 0 but with a time parameter > 0 indicating the time since the
> call to removeEngineTime.   The device does not respond to this.  If I do
> another removeEngineTime after the device comes back up the time security
> parameter is 0 as well as the reboots parameter and it works.   The problem
> is that I don't know when the device comes back up since it does not send a
> trap or notification indicating this.   When I call my function
> (resetUsmUser(securityName))  it resets all TimeTableEntries with
> securityName even if the entry is not the localized one for the device
> having the problem.   I have a number of like devices using the same USM
> security name and passphrases.   I would prefer the ones still up not have
> to go through the discovery process as well.I would like to be able to
> set the reboots, time for the request to 0 just for a particular request
> going to the particular device.
> 
> Is there a way to do this with SNMP4J?Is there a away in the SNMP4J API
> to tell which localized UserTableEntry belongs to a particular device (USM
> discovery process enabled)?
> 
> Ron

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Snmp4j-Agent SNMP-MPD-MIB missing for reading snmpInvalidMsgs ?

2017-01-29 Thread Frank Fock
Hi Ulrich,

SNMP4J-Agent 2.6.0-SNAPSHOT contains the SNMP-MPD-MIB implementation in the new 
class SnmpMpdMib.
See https://oosnmp.net/dist/snapshot/org/snmp4j/snmp4j-agent/2.6.0-SNAPSHOT/ 
<https://oosnmp.net/dist/snapshot/org/snmp4j/snmp4j-agent/2.6.0-SNAPSHOT/>

Best regards,
Frank

> On 27 Jan 2017, at 09:35, ulrich berl <ulrich.b...@gmx.net> wrote:
> 
> Thanks Frank!
>  
> br, Ulrich
>  
> 
> Gesendet: Freitag, 27. Januar 2017 um 02:28 Uhr
> Von: "Frank Fock" <f...@agentpp.com>
> An: "ulrich berl" <ulrich.b...@gmx.net>
> Cc: snmp4j@agentpp.org
> Betreff: Re: [SNMP4J] Snmp4j-Agent SNMP-MPD-MIB missing for reading 
> snmpInvalidMsgs ?
> Hi Ullrich
> 
> This seems to be an error (that the SNMP-MPD-MIB counters are not implemented 
> by the AgentConfigManager.
> I ill add the missing code for the next release.
> 
> Meanwhile you can, of course, implement your own CounterListener for those 
> three counters in your own MIB.
> 
> Best regards,
> Frank
> 
> 
>> On 25 Jan 2017, at 15:19, ulrich berl <ulrich.b...@gmx.net> wrote:
>> 
>> Hi!
>> 
>> From the snmp4j homepage i see that the SNMP4J-Agent should have an 
>> implementation for SNMP-MPD-MIB.
>> Actually in the code the counter for 'snmpInvalidMsgs' will be incremented 
>> on a message process failure (MessageDispatcherImpl.processMessage).
>> 
>> But as there is no SNMP-MPD-MIB implementation, i cant read out the value 
>> for 'snmpInvalidMsgs'.
>> 
>> Should i implement CounterListener in my own mib for 'snmpInvalidMsgs' ?
>> 
>> Thanks, Ulrich
>> ___
>> SNMP4J mailing list
>> SNMP4J@agentpp.org
>> https://oosnmp.net/mailman/listinfo/snmp4j
>  
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Snmp4j-Agent SNMP-MPD-MIB missing for reading snmpInvalidMsgs ?

2017-01-26 Thread Frank Fock

Hi Philippe,

Cross posting messages is not good style and does not help.
If a question is not answered, it might be helpful to rephrase it and add
more details to enable readers to understand it.
 
BTW, I already answered your posting an Dec 29th, 2016.

Best regards,
Frank

> On 27 Jan 2017, at 07:16, FLORENT Philippe  
> wrote:
> 
> Can you reply to my former message about sudent connection issues ??
> I am waiting for a solution to this since last year
> 
> 
___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Snmp4j-Agent SNMP-MPD-MIB missing for reading snmpInvalidMsgs ?

2017-01-26 Thread Frank Fock
Hi Ullrich 

This seems to be an error (that the SNMP-MPD-MIB counters are not implemented 
by the AgentConfigManager.
I ill add the missing code for the next release.

Meanwhile you can, of course, implement your own CounterListener for those 
three counters in your own MIB.

Best regards,
Frank


> On 25 Jan 2017, at 15:19, ulrich berl  wrote:
> 
> Hi!
> 
> From the snmp4j homepage i see that the SNMP4J-Agent should have an 
> implementation for SNMP-MPD-MIB.
> Actually in the code the counter for 'snmpInvalidMsgs' will be incremented on 
> a message process failure (MessageDispatcherImpl.processMessage).
> 
> But as there is no SNMP-MPD-MIB implementation, i cant read out the value for 
> 'snmpInvalidMsgs'.
> 
> Should i implement CounterListener in my own mib for 'snmpInvalidMsgs' ?
> 
> Thanks, Ulrich
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Force snmp to use a private key

2017-01-25 Thread Frank Fock

Hi,

You can use the following constructor of UsmUserEntry, if you only have 
the keys:

http://www.snmp4j.org/doc/org/snmp4j/security/UsmUserEntry.html#UsmUserEntry(byte[],%20org.snmp4j.smi.OctetString,%20org.snmp4j.smi.OID,%20byte[],%20org.snmp4j.smi.OID,%20byte[])

If you know the passphrase and just want to localize the keys with the 
engineID of the target, then

use:
http://www.snmp4j.org/doc/org/snmp4j/security/UsmUser.html#UsmUser(org.snmp4j.smi.OctetString,%20org.snmp4j.smi.OID,%20org.snmp4j.smi.OctetString,%20org.snmp4j.smi.OID,%20org.snmp4j.smi.OctetString,%20org.snmp4j.smi.OctetString)

Hope this helps.

Best regards,
Frank

Am 24.01.2017 um 10:22 schrieb Maciazek Christophe:

Hello,
Until now, I used some linux commands to send snmp requests.
Using passphrases :
snmpgetnext -u myUser -n myContextName -v 3 -l authPriv -a SHA -A 
myAuthPassPhrase -x AES -X myPrivPassPhrase 192.1.1.1 myOid

Directly using local keys for authentification and encryption (no use of the 
engined id received) :
snmpget -u myUser -n myContextName -v 3 -l authPriv -a SHA -3k 
a3f195ebf9390cca7b5cb193e52134852a287c5d -x AES -3K 
03cee8d6123ed92b2aa3fba32152c8de 192.1.1.1 myOid
I have decided to use snmp4j to implement these commands, using snmp4j 2.5.0

No problem for the commands using passphrase. I have found enough exemples to 
do what I want.

But when I want to implement the second case, I can not understand in which 
element I have to indicate that I use local keys and that snmp4j has not to 
calculate keys with the received engined id.

Some help will be usefull please.
Thank you

___
SNMP4J mailing list
SNMP4J@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

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Single snmpset setting a RowStatus first to createAndWait and then to active not working on snmp4j-2.x

2017-01-05 Thread Frank Fock
Hi Iker,
There was a bug/non-optimal code in SNMP4J-Agent 1.x which has now been 
fixed/improved. SNMP4J-Agent 2.x enforces now standard conformity which means 
you have to use RowStatus createAndGo to set a new row active with a single SET 
PDU.

Hope this helps anyway.

Best regards 
Frank

> Am 05.01.2017 um 04:37 schrieb Iker Almandoz :
> 
> Hi Frank,
> 
> We have recently upgraded our snmp4j libraries from the 1.x branch to the 2.x 
> newest versions in order to take advantage of the newest versions and have 
> run into the following problem.
> As part of our usage of snmp4j, we simulate different vendors snmp interfaces 
> in order to have a fully automated test suite of our product.
> For one such vendor, one of the scenarios we have to simulate the dynamic row 
> creation where in a single snmp packet, we set the rowStatus first to 
> createAndWait and in the same exact packet to active
> Assuming the RowStatus OID is SNMPv2-SMI::enterprises.30442.1.2.2.2.5.1.4 and 
> I want to add a new row with ifIndex = 8, I have to be able to do
> 
> snmpset -v2c -c public localhostot 
> SNMPv2-SMI::enterprises.30442.1.2.2.2.5.1.4.8 i 4 ... ( set a bunch of other 
> oIDs on that table to their initial value)... 
> SNMPv2-SMI::enterprises.30442.1.2.2.2.5.1.4.8 i 1
> 
> When using snmp4j-1.x, this was working fine.  I have been able to narrow it 
> down to here
> In the agent 1.4.3, in DefaultMOTable, we have
> 
>  if (row == null) {
>// look for already prepared row
>row = (MOTableRow)
>getNewRows(request.getRequest()).get(cell.getIndex());
>  }
>  if (row != null) {
>prepare(request, cell, mcol, row, false);
>request.completed();
>return;
>  }
> 
> So when the second RowStatus arrives, the row is found in getNEwRows, and we 
> call prepare with newRow = false.
> This means that when the MoChangeEvent is created, the old value is passed as 
> creation is = false
> 
>  MOChangeEvent changeEvent =
>  new MOChangeEvent(this, new CellProxy(cell),
>cell.getCellOID(),
>(creation) ? null : row.getValue(cell.getColumn()),
>request.getVariableBinding().getVariable(),
>true);
> 
> and when the event is processed in the RowStatus class, in 
> beforePrepareMOChange I get a valid currentValue != notExistant so setting it 
> to active works fine
> 
> Now, if I move to agent-2.5.3, the first change in DefaultMoTable becomeso
>  R row = model.getRow(cell.getIndex());
>  boolean newRow = false;
>  if (row == null) {
>// look for already prepared row
>row = getNewRows(request.getRequest()).get(cell.getIndex());
>newRow = true;
>  }
>  if (row != null) {
>prepare(request, cell, mcol, row, newRow);
>request.completed();
>  }
> 
> So now, as the getNewRows is returning the row, the MOChangeVent is created 
> with a previous value of null which defaults to notExistant in RowStatus.
> Here, changeEvent.getOldValue() is null, so currentValue = notExistant and 
> newValue = active.
>  public void beforePrepareMOChange(MOChangeEvent changeEvent) {
>if (changeEvent.getOID().startsWith(oid)) {
>  int currentValue = notExistant;
>  if (changeEvent.getOldValue() instanceof Integer32) {
>currentValue = ((Integer32) changeEvent.getOldValue()).getValue();
>  }
>  int newValue = ((Integer32) changeEvent.getNewValue()).getValue();
>  boolean ok = false;
>  switch (currentValue) {
> case notExistant:
>  ok = ((newValue == createAndGo) ||
>(newValue == createAndWait) || (newValue == destroy));
>  break;
> 
> So with those values, I get within this method ok = false and the set request 
> fails.
> 
> Any help/guidance you can give on this topic would be greatly appreciated as 
> this is blocking our move to production with snmp4j-2.5 at this point.
> I can get our software run ok if I replace line 623 in DefaultMOTAble from
>prepare(request, cell, mcol, row, newRow);
> to
>prepare(request, cell, mcol, row, false);
> 
> however, I am not sure whether this is correct or why the newRow variable is 
> now passed instead of false as in 1.x
> Please let me know if you would need any additional information.
> 
> Best regards,
> Iker
> 
> 
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] FW: suddent error coming out of nowhere

2016-12-29 Thread Frank Fock

Hi Philippe,

It is a simple NullPointerException and you have the stacktrace and the 
code.
It should be easy to identify. From the stacktrace, it seems that you 
are using
an old version of SNMP4J. It would be always helpful to note that (and 
the exact

version number) in your request for help.

Most likely, you are trying to discover the engine ID for a "null" address.
Which cannot work in any case.

Best regards,
Frank

Am 29.12.2016 um 07:41 schrieb FLORENT Philippe:

Is this mailing list still active ?
Can someone answer ?

From: FLORENT Philippe
Sent: mardi 13 décembre 2016 09:45
To: snmp4j@agentpp.org
Subject: FW: suddent error coming out of nowhere

Now I get the same on my pc, no update was made on my pc nor on the remote 
system
Can someone guide me through this ?
thanks

From: FLORENT Philippe
Sent: lundi 12 décembre 2016 12:02
To: snmp4j@agentpp.org
Subject: suddent error coming out of nowhere

Hi,

Suddently my collegue have issues with the app I ve written (works perfectly 
fine on my pc)
I rebooted his pc, but still the same

java.lang.NullPointerException
 at java.util.Hashtable.remove(Unknown Source)
 at org.snmp4j.mp.MPv3.removeEngineID(MPv3.java:356)
 at 
org.snmp4j.Snmp.discoverAuthoritativeEngineID(Snmp.java:1177)
 at starrwarr.remote.snmp.SnmpProber.Connect(SnmpProber.java:93)
 at starrwarr.Machine.run(Machine.java:97)
 at java.lang.Thread.run(Unknown Source)

this was not occurring before and I cant figure out what's going wrong

here is the code I use :

 TransportMapping transport = new 
DefaultUdpTransportMapping();
 snmp = new Snmp(transport);
 USM usm = new USM(SecurityProtocols.getInstance(),new 
OctetString(MPv3.createLocalEngineID()), 0);
 SecurityModels.getInstance().addSecurityModel(usm);
 transport.listen();
 snmp.listen();

 Address targetAddress = 
GenericAddress.parse("udp:"+ipAddress+"/"+port);
 target = new UserTarget();
 target.setAddress(targetAddress);
 target.setRetries(1);
 target.setTimeout(5000);
 target.setVersion(SnmpConstants.version3);
 target.setSecurityLevel(SecurityLevel.AUTH_PRIV);
 target.setSecurityName(new OctetString(userName));

thanks
___
SNMP4J mailing list
SNMP4J@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

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] thread safety on SNMP

2016-12-09 Thread Frank Fock
Hi Mert,

Yes, Snmp is thread safe as it could be.

I will take care about the Closable interface at least for the 3.0 release 
(based on Java 9 for DTLS support).

Best regards,
Frank


> On 8 Dec 2016, at 11:55, Mert Çalışkan  wrote:
> 
> Hi,
> 
> I’m in  the process of integrating SNMP4J into Payara, which is derived from 
> Glassfish application server, for the notification services mechanism.  
> Is it ok to say that an instance of org.snmp4j.Snmp is thread-safe? I’d say 
> it is according to the source but I’d like to verify with the team.  
> 
> I see that a SNMP session can be closed, via close(), so I think it’d be good 
> to implement java.io.Closeable in order to provide try-with-resources feature 
> on the SNMP instances.
> 
> Thanks,  
> 
> Mert Çalışkan
> Oracle Java Champion
> Developer (http://www.t2.com.tr), Lecturer 
> (http://www.cs.hacettepe.edu.tr/kisiler.html), JUG Leader 
> (http://www.ankarajug.org), Author (http://www.amazon.com/author/mert)  
> https://tr.linkedin.com/in/mertcaliskan
> 
> 
> 
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Symbolic names instead of numerical OID?

2016-11-06 Thread Frank Fock

Hello KIM,

SNMP4J-SMI-PRO provides what you are looking for.

Best regards,
Frank

Am 07.11.2016 um 01:18 schrieb BYEONG-GI KIM:

Hello.

are there APIs to use symbolic names such as sysDescr, instead of numerical
OID like 1.3.6.1.2.1.1.5.0?

I've been trying to find it from the API doc, but I couldn't yet.

Thanks in advance.

Regards,

KIM
___
SNMP4J mailing list
SNMP4J@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

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] snmp4j-smi-pro issue

2016-11-03 Thread Frank Fock

Hi Ronald,

Most likely, you get the IMPORTS from a different MIB module, or the MIB 
module

could not be parsed correctly (this could happen if you use the lenient mode
with a broken MIB module).

Hope this helps.

Best regards,
Frank

Am 03.11.2016 um 17:27 schrieb Ronald Braswell:

I am trying to use the SmiModule::getImports() to get the imports for a
module.

Then I want to use the SmiImport::getImportedObjectNames() and
SmiImport::getSourceModuleName()
methods for each import.

Here is the import clause for XUPS-MIB:

IMPORTS
 TimeTicks, Gauge32, Counter32, Integer32
 FROM SNMPv2-SMI
 DisplayString
 FROM SNMPv2-TC
 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE
 FROM SNMPv2-SMI
 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
 FROM SNMPv2-CONF
 eaton, xupsEnvironment
 FROM EATON-OIDS
 -- Need to import these EMP objects to support PowerMIB-style traps for
EMP
 xupsContactIndex, xupsContactType, xupsContactState, xupsContactDescr,
 xupsEnvRemoteTemp, xupsEnvRemoteTempLowerLimit,
xupsEnvRemoteTempUpperLimit,
 xupsEnvRemoteHumidity, xupsEnvRemoteHumidityLowerLimit,
 xupsEnvRemoteHumidityUpperLimit
 FROM EATON-EMP-MIB;

Issues:

The source module names I get from this module are:

RFC1155-SMI
RFC1213-MIB
RFC-1212
RFC-1215

List  moduleImports = smiModule.getImports();
List  importedModules = moduleImports.stream().map( i ->
i.getSourceModuleName() ).collect(Collectors.toList());
importedModules.stream().forEach(System.out::println);

Am I doing something wrong?

Yet, smiModule.getObjectNames() does include the objects imported from the
EATON-EMP-OID (e.g.  xupsEnvRemoteTemp) but the imported objects do not
have all fields populated (e.g. units) whereas the EATON-EMP-MIB objects do
have all fields populated (according to the MIB.

Why would I not see EATON-EMP-MIB in the list of SmiImport for the XUPS-MIB
module?

Ron
___
SNMP4J mailing list
SNMP4J@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

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] detect timeout ?

2016-10-28 Thread Frank Fock

Hi Philippe,

as I wrote, there is a STATUS identifier that indicates the timeout.
Counting VBs is not enough. You get the status value with 
TableEvent.getStatus()


Best regards,
Frank

Am 27.10.2016 um 08:55 schrieb FLORENT Philippe:

What if I get an empty table ?

How to differentiate a timeout with a table that should actually be empty

-Original Message-
From: SNMP4J [mailto:snmp4j-boun...@agentpp.org] On Behalf Of Frank Fock
Sent: jeudi 27 octobre 2016 00:51
To: snmp4j@agentpp.org
Subject: Re: [SNMP4J] detect timeout ?

Hi Philippe,

The (last) TableEvent object will indicate the timeout in its status field.

Best regards,
Frank

Am 26.10.2016 um 15:05 schrieb FLORENT Philippe:

Hi,

I use this function to read infos on my host,

But if the host (or the snmp service) is down, how do I detect it ?

So far I check the table size must be >0 but what if table is 0 size and the 
host is not down ?

thanks

public ArrayList getTable(Mib mib)
  {
  final PDUFactory pduFactory = new DefaultPDUFactory(PDU.GETBULK);
  pduFactory.createPDU(target);
  final TableUtils utils = new TableUtils(snmp, pduFactory);
  List table = utils.getTable(target, new OID[]{ new 
OID(mib.oid) }, null, null);
  for(TableEvent a:table)
  {
  if(a.getColumns()!=null)
  {

  }
  }
 }
___
SNMP4J mailing list
SNMP4J@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

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] TableUtils.getTable() doesn't return

2016-10-25 Thread Frank Fock

Hi Steffen,

Yes, this will be included in the next (2.5.3) release.

Best regards,
Frank

Am 25.10.2016 um 16:09 schrieb Steffen Brüntjen:

Hi!

I can approve that this edit

boolean sentChunk = sendNextChunk();
if (!sentChunk) {
if (anyMatch) {
sent = 0;
anyMatch = false;
sentChunk = sendNextChunk();
}
if (!sentChunk) {
emptyCache();
finished = true;
listener.finished(new TableEvent(this, 
userObject));
}
}

solves the problem. Are you going to merge this to the next release?

The device with this issue is an HP ProCurve Switch 2910al-48G (J9147A).

Best regards,
Steffen Brüntjen



-Original Message-
From: SNMP4J [mailto:snmp4j-boun...@agentpp.org] On Behalf Of Frank Fock
Sent: Dienstag, 25. Oktober 2016 02:03
To: snmp4j@agentpp.org
Subject: Re: [SNMP4J] TableUtils.getTable() doesn't return

Hi Steffen,

I cannot imagine a standard conforming agent that will cause the
situation you
described, but anyway you are right, that there is a "hole" in the
algorithm of
TableUtils.

To fix it, you can replace the "relevant part in
TableRequest.onResponse" with

boolean sentChunk;
if (!(sentChunk = sendNextChunk())) {
if (anyMatch) {
  sent =0;
  anyMatch =false;
  sentChunk = sendNextChunk();
}
if (!sentChunk) {
  emptyCache();
  finished =true;
  listener.finished(new TableEvent(this,userObject));
}
}

Best regards,
Frank


Am 24.10.2016 um 18:36 schrieb Steffen Brüntjen:

Hi!

I found a problem in the TableUtils class. I set maxNumColumnsPerPDU in my
TableUtils object to 1 (because one of the test devices returns results in
wrong lexicographic order). Then, in some cases the TableUtils method

public List getTable(Target target,
OID[] columnOIDs,
OID lowerBoundIndex,
OID upperBoundIndex) {

doesn't return. It starts waiting for a notify() on InternalTableListener
which never comes.

This is the relevant part in TableRequest.onResponse:

if (!sendNextChunk()) {
if (anyMatch) {
sent = 0;
anyMatch = false;
sendNextChunk();
} else {
emptyCache();
finished = true;
listener.finished(new TableEvent(this, 
userObject));
}
}

The problem arises when the second call of sendNextChunk() returns false.
And this is what's happening. In sendNextChunk(), the first false comes
from here:

if (sent >= lastReceived.size()) {
return false;
}

The second false comes from here:

sent += chunkSize;
if (pdu.size() == 0) {
return false;
}
sendRequest(pdu, target, sentColumns);


Best regards,
Steffen Brüntjen

___
SNMP4J mailing list
SNMP4J@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

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Behaviour of ResponseListener in SNMP V3

2016-10-12 Thread Frank Fock

Hi Peter,

You analysis matches mine. The problem is, that the
cancel returns true on my system and with my unit test in that case.

From reading the code, the cancel must return true in this
case, because the pending request is already scheduled at that time
which is ensured by the pduHandleAssigned callback
from the MessageDispatcherImpl.sendPdu.

Are you using your own MessageDispatcher that does not call the
callback.

(Sorry, I have no plausible other idea...)

Best regards,
Frank

Am 12.10.2016 um 16:29 schrieb Peter Verthez:

Hi Frank,

I found it suspicious that there was no real explanation, so I went 
back to my test, and unfortunately that test had succeeded with SNMP4J 
2.5.2 because the agent was genuinely not reachable... When I tested 
again with an agent that should be reachable, I found the same 
problem, also with SNMP4J 2.5.2.


I debugged a little in the SNMP4J code.The cancel is really 
happening after the report message, with the following stack trace:


Daemon Thread [DefaultUDPTransportMapping_172.31.109.98/0] (Suspended 
(breakpoint at line 1925 in Snmp$PendingRequest))

owns: Snmp$AsyncPendingRequest  (id=36087)
Snmp$AsyncPendingRequest(Snmp$PendingRequest).cancel() line: 1925
Snmp$ReportProcessor.processReport(PduHandle, 
CommandResponderEvent) line: 1409
SecureSnmpFactory$WrappedReportHandler.processReport(PduHandle, 
CommandResponderEvent) line: 157

Snmp.processPdu(CommandResponderEvent) line: 1248
MessageDispatcherImpl.fireProcessPdu(CommandResponderEvent) line: 691
MessageDispatcherImpl.dispatchMessage(TransportMapping, 
MessageProcessingModel, Address, BERInputStream, 
TransportStateReference) line: 310
MessageDispatcherImpl.processMessage(TransportMapping, Address, 
BERInputStream, TransportStateReference) line: 387
MessageDispatcherImpl.processMessage(TransportMapping, Address, 
ByteBuffer, TransportStateReference) line: 347
DefaultUdpTransportMapping(AbstractTransportMapping).fireProcessMessage(Address, 
ByteBuffer, TransportStateReference) line: 76

DefaultUdpTransportMapping$ListenThread.run() line: 425
Thread.run() line: 745

Here is what I find (with SNMP4J 2.5.2):
- the 'usmStatsUnknownUserNames' report that we get here is handled in 
ReportProcessor.processReport
- the resend variable stays false, because it is not one of the 3 
special cases given there in lines 1364-1380
- as a consequence, the else is entered in line 1402, which cancels 
the request
- the cancel request returns false here (apparently state of the 
PendingRequest is VIRGIN at that time), so that 'intime' is false on 
Snmp.java line 1414, which causes the listener not to be called


So the question is: why is the state of the PendingRequest equal to 
VIRGIN?   Is this unexpected?


Best regards,
Peter.

On 11/10/2016 0:14, Frank Fock wrote:

Hi Peter,

Thank you for trying version 2.5.2, although it seems to be 
inexplicable why the behavior changed.

There are no changes in 2.5.2 and 2.5.1 in the class Snmp.

Best regards,
Frank

Am 10.10.2016 um 13:27 schrieb Peter Verthez:

Traces now, for info:

2016-10-10 13:25:54,180 DEBUG 
[JM-45-Ping-Ping-7]-[org.snmp4j.security.UsmUserTable] Adding user 
verthezp_wrong2 = 
UsmUser[secName=verthezp_wrong2,authProtocol=1.3.6.1.6.3.10.1.1.3,authPassphrase=12345678,privProtocol=null,privPassphrase=null,localizationEngineID=null]
2016-10-10 13:25:54,182 DEBUG 
[JM-45-Ping-Ping-7]-[org.snmp4j.security.USM] RFC3414 §3.1.4.b 
Outgoing message is not encrypted
2016-10-10 13:25:54,182 DEBUG 
[JM-45-Ping-Ping-7]-[org.snmp4j.mp.MPv3] Adding cache entry: 
StateReference[msgID=16001,pduHandle=PduHandle[922855848],securityEngineID=,securityModel=org.snmp4j.security.USM@137719b6,securityName=verthezp_wrong2,securityLevel=1,contextEngineID=,contextName=nt,retryMsgIDs=null]
2016-10-10 13:25:54,182 DEBUG [JM-45-Ping-Ping-7]-[org.snmp4j.Snmp] 
Running pending async request with handle PduHandle[922855848] and 
retry count left 1
2016-10-10 13:25:54,182 DEBUG 
[JM-45-Ping-Ping-7]-[org.snmp4j.transport.DefaultUdpTransportMapping] Sending 
message to 135.249.41.7/161 with length 61: 
30:3b:02:01:03:30:0f:02:02:3e:81:02:03:00:ff:ff:04:01:04:02:01:03:04:10:30:0e:04:00:02:01:00:02:01:00:04:00:04:00:04:00:30:13:04:00:04:02:6e:74:a0:0b:02:01:00:02:01:00:02:01:00:30:00
2016-10-10 13:25:58,187 DEBUG [SNMP4J 
Timer]-[org.snmp4j.security.USM] RFC3414 §3.1.4.b Outgoing message 
is not encrypted
2016-10-10 13:25:58,187 DEBUG [SNMP4J Timer]-[org.snmp4j.mp.MPv3] 
Adding cache entry: 
StateReference[msgID=16002,pduHandle=PduHandle[922855848],securityEngineID=,securityModel=org.snmp4j.security.USM@137719b6,securityName=verthezp_wrong2,securityLevel=1,contextEngineID=,contextName=nt,retryMsgIDs=null]
2016-10-10 13:25:58,188 DEBUG [SNMP4J Timer]-[org.snmp4j.mp.MPv3] 
Adding previous message IDs [16001] to new entry 
StateReference[msgID=16002,pduHandle=PduHandle[922855848],securityEngineID=,securityModel=org.snmp4j.security.USM@137719b6,securityName

Re: [SNMP4J] Behaviour of ResponseListener in SNMP V3

2016-10-10 Thread Frank Fock

Hi Peter,

Thank you for trying version 2.5.2, although it seems to be inexplicable 
why the behavior changed.

There are no changes in 2.5.2 and 2.5.1 in the class Snmp.

Best regards,
Frank

Am 10.10.2016 um 13:27 schrieb Peter Verthez:

Traces now, for info:

2016-10-10 13:25:54,180 DEBUG 
[JM-45-Ping-Ping-7]-[org.snmp4j.security.UsmUserTable] Adding user 
verthezp_wrong2 = 
UsmUser[secName=verthezp_wrong2,authProtocol=1.3.6.1.6.3.10.1.1.3,authPassphrase=12345678,privProtocol=null,privPassphrase=null,localizationEngineID=null]
2016-10-10 13:25:54,182 DEBUG 
[JM-45-Ping-Ping-7]-[org.snmp4j.security.USM] RFC3414 §3.1.4.b 
Outgoing message is not encrypted
2016-10-10 13:25:54,182 DEBUG [JM-45-Ping-Ping-7]-[org.snmp4j.mp.MPv3] 
Adding cache entry: 
StateReference[msgID=16001,pduHandle=PduHandle[922855848],securityEngineID=,securityModel=org.snmp4j.security.USM@137719b6,securityName=verthezp_wrong2,securityLevel=1,contextEngineID=,contextName=nt,retryMsgIDs=null]
2016-10-10 13:25:54,182 DEBUG [JM-45-Ping-Ping-7]-[org.snmp4j.Snmp] 
Running pending async request with handle PduHandle[922855848] and 
retry count left 1
2016-10-10 13:25:54,182 DEBUG 
[JM-45-Ping-Ping-7]-[org.snmp4j.transport.DefaultUdpTransportMapping] 
Sending message to 135.249.41.7/161 with length 61: 
30:3b:02:01:03:30:0f:02:02:3e:81:02:03:00:ff:ff:04:01:04:02:01:03:04:10:30:0e:04:00:02:01:00:02:01:00:04:00:04:00:04:00:30:13:04:00:04:02:6e:74:a0:0b:02:01:00:02:01:00:02:01:00:30:00
2016-10-10 13:25:58,187 DEBUG [SNMP4J Timer]-[org.snmp4j.security.USM] 
RFC3414 §3.1.4.b Outgoing message is not encrypted
2016-10-10 13:25:58,187 DEBUG [SNMP4J Timer]-[org.snmp4j.mp.MPv3] 
Adding cache entry: 
StateReference[msgID=16002,pduHandle=PduHandle[922855848],securityEngineID=,securityModel=org.snmp4j.security.USM@137719b6,securityName=verthezp_wrong2,securityLevel=1,contextEngineID=,contextName=nt,retryMsgIDs=null]
2016-10-10 13:25:58,188 DEBUG [SNMP4J Timer]-[org.snmp4j.mp.MPv3] 
Adding previous message IDs [16001] to new entry 
StateReference[msgID=16002,pduHandle=PduHandle[922855848],securityEngineID=,securityModel=org.snmp4j.security.USM@137719b6,securityName=verthezp_wrong2,securityLevel=1,contextEngineID=,contextName=nt,retryMsgIDs=null]
2016-10-10 13:25:58,188 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp] Running 
pending async request with handle PduHandle[922855848] and retry count 
left 0
2016-10-10 13:25:58,188 DEBUG [SNMP4J 
Timer]-[org.snmp4j.transport.DefaultUdpTransportMapping] Sending 
message to 135.249.41.7/161 with length 61: 
30:3b:02:01:03:30:0f:02:02:3e:82:02:03:00:ff:ff:04:01:04:02:01:03:04:10:30:0e:04:00:02:01:00:02:01:00:04:00:04:00:04:00:30:13:04:00:04:02:6e:74:a0:0b:02:01:00:02:01:00:02:01:00:30:00
2016-10-10 13:26:06,188 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp] Request 
timed out: 922855848
2016-10-10 13:26:06,188 INFO  [SNMP4J 
Timer]-[com.alcatel.util.net.snmp.SnmpUserTarget] Received response 
org.snmp4j.event.ResponseEvent[source=org.snmp4j.Snmp@dbb54af]
2016-10-10 13:26:06,189 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp] 
Cancelling pending request with handle PduHandle[922855848]



Best regards,
Peter.


On 10/10/2016 13:25, Peter Verthez wrote:

Hi Frank,

I've tried now with SNMP4J 2.5.2 (downloaded by manually changing the 
download URL), and with that version I also can't reproduce the 
problem anymore: the ResponseListener is now called.


So we'll upgrade to that version.

Thanks,
Peter.



On 10/10/2016 8:19, Peter Verthez wrote:

Hi Frank,

Apparently the download page is not updated yet for SNMP4J 2.5.2?

http://www.snmp4j.org/html/download.html

Best regards,
Peter.


On 10/10/2016 7:58, Peter Verthez wrote:

Hi Frank,

Answers on your possibilities:

1. No, the code that I showed in a previous mail is verbatim 
copy/pasted from our source code, the snmp.send method call comes 
directly after the creation of the ResponseListener.


2. No, we don't have an explicit cancel anywhere in our code, 
except inside the ResponseListener, as I showed in the code in the 
previous mail (which isn't reached).


3. No, we are using the original SNMP4J source code.

I'll try with SNMP4J 2.5.2 to see whether that makes a difference.

Best regards,
Peter.


On 9/10/2016 16:36, Frank Fock wrote:

Hi Peter,

Sorry, my statement in my previous message was wrong. Please 
ignore it, because
setting  the request-id field to 0 in a REPORT PDU is OK: If the 
request was encrypted
the command responder would have no chance to decode the 
request-id field.
That's is why the command generator has to be able to match the 
request anyway
by the message-id field. SNMP4J is capable of that, so far, no 
problem.


With SNMP4J 2.5.2 (current release) I still could not reproduce 
the issue.

My unit test works as expected and calls the ResponseListener.

From the code analysis, I see only three possibilities how the 
behavior you observed

could happen:

1. The ReponseListener parameter is null (please check for a typo 
in the parameter name

or a null

Re: [SNMP4J] Using localized keys

2016-10-09 Thread Frank Fock

Hi Ron,

There are two cases you have to differentiate:

1. You have already localized passphrases for your target:
Then use USM.addLocalizedUser(...)
2. You have plain text passphrases for your target:
Then use USM.addUser with a UsmUser that had been created with a 
localizationEngineID.


In the second case, the passphrases will be localized by SNMP4J when the 
user is added to

the USM.

Hope this helps.

Best regards,
Frank

Am 09.10.2016 um 17:00 schrieb Ronald Braswell:

Hi,

I have read about localized keys and understand the concept.   I don't yet
understand how to implement them and use them with SNMP4J.

If anyone has the time to briefly share how to do this I would greatly
appreciate it.

Ron
___
SNMP4J mailing list
SNMP4J@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

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Behaviour of ResponseListener in SNMP V3

2016-10-09 Thread Frank Fock

Hi Peter,

Sorry, my statement in my previous message was wrong. Please ignore it, 
because
setting  the request-id field to 0 in a REPORT PDU is OK: If the request 
was encrypted

the command responder would have no chance to decode the request-id field.
That's is why the command generator has to be able to match the request 
anyway

by the message-id field. SNMP4J is capable of that, so far, no problem.

With SNMP4J 2.5.2 (current release) I still could not reproduce the issue.
My unit test works as expected and calls the ResponseListener.

From the code analysis, I see only three possibilities how the behavior 
you observed

could happen:

1. The ReponseListener parameter is null (please check for a typo in the 
parameter name

or a null assignment before the send call)
2. The pending request was cancelled by closing the Snmp session or 
cancelling the request

(Normally this would have been reported in the log, but...)
3. You did not use the original SNMP4J source code.

Best regards,
Frank


Am 09.10.2016 um 10:33 schrieb Frank Fock:

Hi Peter,

The command responder is not setting the request-id correctly in the 
REPORT PDU.
This is causing the issue on the SNMP4J side. Nevertheless, SNMP4J 
should behave more

robust and should call the response listener after the request times out.
I will add a corresponding unit test for that and fix it.

Best regards,
Frank

Am 07.10.2016 um 12:55 schrieb Peter Verthez:
OK, my apologies: I was copying the wrong traces. Here are the 
correct ones.I've also added a logging message "Received response 
" + event  in the first line of the ResponseListener.onResponse(), 
and the traces below show that it is not coming.


2016-10-07 12:51:17,934 DEBUG 
[JM-4-Ping-Ping-7]-[org.snmp4j.security.UsmUserTable] Adding user 
verthezp_wrong2 = 
UsmUser[secName=verthezp_wrong2,authProtocol=1.3.6.1.6.3.10.1.1.3,authPassphrase=12345678,privProtocol=null,privPassphrase=null,localizationEngineID=null]
2016-10-07 12:51:17,950 DEBUG [JM-4-Ping-Ping-7]-[org.snmp4j.mp.MPv3] 
Context engine ID of scoped PDU is empty! Setting it to authoritative 
engine ID: 80:00:02:7d:03:00:90:d0:6d:fa:bc
2016-10-07 12:51:17,956 DEBUG 
[JM-4-Ping-Ping-7]-[org.snmp4j.security.USM] 
getUser(engineID=80:00:02:7d:03:00:90:d0:6d:fa:bc, 
securityName=verthezp_wrong2)
2016-10-07 12:51:17,964 DEBUG 
[JM-4-Ping-Ping-7]-[org.snmp4j.security.USM] RFC3414 §3.1.4.b 
Outgoing message is not encrypted
2016-10-07 12:51:17,965 DEBUG [JM-4-Ping-Ping-7]-[org.snmp4j.mp.MPv3] 
Adding cache entry: 
StateReference[msgID=46925,pduHandle=PduHandle[1444975050],securityEngineID=80:00:02:7d:03:00:90:d0:6d:fa:bc,securityModel=org.snmp4j.security.USM@529c7488,securityName=verthezp_wrong2,securityLevel=2,contextEngineID=80:00:02:7d:03:00:90:d0:6d:fa:bc,contextName=nt,retryMsgIDs=null]
2016-10-07 12:51:17,972 DEBUG [JM-4-Ping-Ping-7]-[org.snmp4j.Snmp] 
Running pending async request with handle PduHandle[1444975050] and 
retry count left 1
2016-10-07 12:51:17,973 DEBUG 
[JM-4-Ping-Ping-7]-[org.snmp4j.transport.DefaultUdpTransportMapping] 
Sending message to 135.249.41.7/161 with length 357: 
30:82:01:61:02:01:03:30:10:02:03:00:b7:4d:02:03:00:ff:ff:04:01:05:02:01:03:04:38:30:36:04:0b:80:00:02:7d:03:00:90:d0:6d:fa:bc:02:01:08:02:03:02:86:91:04:0f:76:65:72:74:68:65:7a:70:5f:77:72:6f:6e:67:32:04:0c:c2:71:d3:1c:34:43:4a:bb:b8:ba:b2:93:04:00:30:82:01:0e:04:0b:80:00:02:7d:03:00:90:d0:6d:fa:bc:04:02:6e:74:a0:81:fa:02:04:56:20:91:ca:02:01:00:02:01:00:30:81:eb:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:06:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:09:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:02:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:23:3c:03:02:00:05:00:30:0c:06:08:2b:06:01:02:01:01:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:07:00:05:00:30:0c:06:08:2b:06:01:02:01:01:02:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:03:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:0d:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:17:02:01:04:01:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:01:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:02:00:05:00
2016-10-07 12:51:18,125 DEBUG 
[DefaultUDPTransportMapping_172.31.109.98/0]-[org.snmp4j.transport.DefaultUdpTransportMapping] 
Received message from /135.249.41.7/161 with length 103: 
30:65:02:01:03:30:10:02:03:00:b7:4d:02:03:00:ff:ff:04:01:00:02:01:03:04:1d:30:1b:04:0b:80:00:02:7d:03:00:90:d0:6d:fa:bc:02:01:08:02:03:02:86:92:04:00:04:00:04:00:30:2f:04:0b:80:00:02:7d:03:00:90:d0:6d:fa:bc:04:02:6e:74:a8:1c:02:01:00:02:01:00:02:01:00:30:11:30:0f:06:0a:2b:06:01:06:03:0f:01:01:03:00:41:01:44
2016-10-07 12:51:18,125 DEBUG 
[DefaultUDPTransportMapping_172.31.109.98/0]-[org.snmp4j.mp.MPv3] 
SNMPv3 header decoded: msgId=46925, msgMaxSize=65535, msgFlags=00, 
secModel=3
2016-10-07 12:51:18,126 DEBUG 
[DefaultUDPTransportMapping_172.31.109.98/0]-[org.snmp4j.security.USM] Accepting 
zero lengt

Re: [SNMP4J] Behaviour of ResponseListener in SNMP V3

2016-10-09 Thread Frank Fock
quest ID 0
2016-10-07 12:51:21,973 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp] 
PendingRequest canceled key=null, pdu=null, target=null, 
transport=null, listener=null



Best regards,
Peter.



On 7/10/2016 8:18, Peter Verthez wrote:
Ah, maybe I copied the wrong traces then and that is the source of 
the confusion (we have a mix of SNMPv2 and v3 agents).


Let me check...

Thanks,
Peter.


On 6/10/2016 21:45, Frank Fock wrote:

Hi Peter,

The PDU that is send is a SNMPv2c GET request and not a v3 request.
So this cannot be an issue with the USM or other v3 processing.

To be able to reproduce the issue I might need more details. If it 
is indeed

a v3 request, I would like to have the log for it. In addition,
is the "unknown user" locally unknown the the USM of the command
sender or remotely unknown to the command responder.

If locally unknown, a exception is thrown during the send call.

Best regards,
Frank

Am 06.10.2016 um 09:45 schrieb Peter Verthez:

Hi Frank,

The PDU instance is not used in another thread, only in this one. 
All normal functionality works properly (we started to use async 
requests 1.5 years ago), except for this timeout due to a wrong 
security name being used.I'm not sure whether that is a new 
regression or something that wasn't tested before by our test team.


I'm not sure which further information I have to give, I can't 
provide the full source code as this is a proprietary product. If 
you want me to debug something specific I can do that.


Best regards,
Peter.


On 5/10/2016 22:55, Frank Fock wrote:

Hi Peter,

From the provided send call alone, I cannot verify if the 
parameters are correctly
setup. The SnmpUserTarget.this, for example, might not work if 
called in a constructor

of that class.

The pdu instance might be used concurrently by another thread 
(with same or different

request ID), which would corrupt the pending request management.

Best regards,
Frank

Am 05.10.2016 um 08:14 schrieb Peter Verthez:

Hi Frank,

The call of the send method was in the last line of my code 
snippet: session is an Snmp object.


Best regards,
Peter.


On 4/10/2016 20:12, Frank Fock wrote:


Hi Peter,

How do call the send method? Is the listener set there?
All fields null should not happen normally

Best regards,
Frank

Am 04.10.2016 um 11:18 schrieb Peter Verthez:

Hi Frank,

Our code is simply:

ResponseListener respListener = new 
ResponseListener() {

@Override
public void onResponse(ResponseEvent 
event) {
// canceling is required as per 
SNMP4J documentation

((Snmp)event.getSource()).cancel(event.getRequest(), this);
PDU response = event.getResponse();
updateStats(session, agentId, 
startTime, response);

listener.onResponse(response, event.getUserObject());
}
};

session.send(pdu, SnmpUserTarget.this, 
userContext, respListener);


It doesn't reach even the first line of the onResponse method.

I've been debugging a little, and the PendingRequest.run() 
method in the Snmp class is always being exited because all 
fields are null, and so it never calls the onResponse method on 
the listener. This is also what the debug message says:


2016-09-28 16:43:36,861 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp] 
PendingRequest canceled key=null, pdu=null, target=null, 
transport=null, listener=null


I've then put a breakpoint in the cancel() method, and it gets 
run when the following report is coming in (copied from the 
debugger):


REPORT[{contextEngineID=80:00:02:7d:03:00:90:d0:6d:fa:bc, 
contextName=nt}, requestID=0, errorStatus=0, errorIndex=0, 
VBS[1.3.6.1.6.3.15.1.1.3.0 = 18]]


Best regards,
Peter.


On 3/10/2016 23:06, Frank Fock wrote:

Hi Peter,

Yes, the ResponseEvent should be returned after the timeout 
with a null response.
From the log, it is unclear why you do not get the event. Is 
there an if-statement

that ignores the ResponseEvent with null response in your code?

Best regards,
Frank

Am 30.09.2016 um 10:12 schrieb Peter Verthez:

Hi Frank,

If we are using asynchronous SNMP calls with SNMPv3, what 
should be the behaviour in case of timeout, when you used 
wrong credentials such as a wrong user name. Should the 
ResponseListener always be triggered, with 
event.getResponse() = null, after the timeout?


I would expect that, but it looks like this is not what I'm 
seeing: the ResponseListener does not seem to be triggered in 
that case. So this means that our application never knows 
that a timeout occurred. We are using currently SNMP4J 2.5.0. 
Debug logging from SNMP4J:


2016-09-28 16:43:31,768 DEBUG 
[JM-49-Ping-Ping-4]-[org.snmp4j.Snmp] Running pending async 
request with handle PduHandle[1071987217] and retry count left 1
2016-09-28 16:43:31,768 DEBUG 
[JM-49-Ping-Ping-4]-[org.snmp4j.transport.DefaultUdpTransportMapping] 
Sending mess

Re: [SNMP4J] Which library should I use?

2016-10-06 Thread Frank Fock

Hi,

The code you used is just out-dated and was probably written for the 1.x
releases of SNMP4J-Agent.

But the issue is simple to fix: Just use the SnmpCommunityEntryRow
instead MOTableRow as type for "row".

Best regards,
Frank

Am 06.10.2016 um 07:22 schrieb BYEONG-GI KIM:

Hello.

I'm a new who get started to learn snmp agent & manager implementations via
snmp4j.

I have a question; I've been practicing how the source code is written so
that I copied and pasted several example codes from some blogs and websites
like,

http://www.jitendrazaa.com/blog/java/snmp/creating-snmp-agent-server-in-java-using-snmp4j/

The problem is the source code has an error from the line
"communityMIB.getSnmpCommunityEntry().addRow(row);" with the error message
"The method addRow(SnmpCommunityMIB.SnmpCommunityEntryRow) in the type
MOTable
is not applicable for the arguments (MOTableRow)"

I so thought that I'm using wrong snmp4j version, which was the newest
version at the maven repo (
https://mvnrepository.com/artifact/org.snmp4j/snmp4j/2.5.2) though. I thus
changed the libraries to the things that attached in the zip files at the
snmp4j download menu, aka snmp4j-agent-2.5.0.jar and snmp4j-2.5.0.jar. The
error, however, still exists.

What's the problem with this? is the example code just wrongly implemented?
Or, are the libraries wrongly set?

Thanks in advance!

Regards

BGKIM
___
SNMP4J mailing list
SNMP4J@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

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] TreeUtils & DefaultPDUFactory

2016-10-05 Thread Frank Fock

Hi Ron,

You can upgrade to the latest SNMP4J version 2.5.2 and the issue you
described should disappear.

You can also fix the issue, with version 2.5.0 by setting the context 
engine ID

to an empty OctetString in the Factory constructor. SNMP4J will then
automatically replace the empty string with the discovered authoritative
engine ID.

Best regards,
Frank

Am 05.10.2016 um 16:13 schrieb Ronald Braswell:

I am attempting to use TreeUtils with a DefaultPDUFactory using GETNEXT
(the OID range is small).

I have set engine discovery for USM during the initialization of the
program to true.

The target uses V3 and USM. I have successfully polled the target and
have successfully received traps from the target without specifying the
engineID when adding the UsmUser.

However, when I use TreeUtils as described above, it fails with 'Context
engine ID must not be null' at org.snmp4j.ScopedPDU.setContextEngineID()
line 69.

I am using SNMP4j version 2.5.

I notice using wireshark that a get-request is sent to the device to elicit
the report PDU from which it can discover the authoritative engine ID.
There are two packets sent from the manager to the target and the target
responds to each.   I would assume that the packets are encrypted getnext
packets with the responses appropriate to the requests.

When using the DefaultPDUFactory, do I need to specify the authoritative
engine for the user when adding the user to USM even though when polling
and I specify the PDU this is not necessary?

Ron
___
SNMP4J mailing list
SNMP4J@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

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Behaviour of ResponseListener in SNMP V3

2016-10-04 Thread Frank Fock


Hi Peter,

How do call the send method? Is the listener set there?
All fields null should not happen normally

Best regards,
Frank

Am 04.10.2016 um 11:18 schrieb Peter Verthez:

Hi Frank,

Our code is simply:

ResponseListener respListener = new 
ResponseListener() {

@Override
public void onResponse(ResponseEvent event) {
// canceling is required as per SNMP4J 
documentation

((Snmp)event.getSource()).cancel(event.getRequest(), this);
PDU response = event.getResponse();
updateStats(session, agentId, startTime, 
response);
listener.onResponse(response, 
event.getUserObject());

}
};

session.send(pdu, SnmpUserTarget.this, 
userContext, respListener);


It doesn't reach even the first line of the onResponse method.

I've been debugging a little, and the PendingRequest.run() method in 
the Snmp class is always being exited because all fields are null, and 
so it never calls the onResponse method on the listener.   This is 
also what the debug message says:


2016-09-28 16:43:36,861 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp] 
PendingRequest canceled key=null, pdu=null, target=null, 
transport=null, listener=null


I've then put a breakpoint in the cancel() method, and it gets run 
when the following report is coming in (copied from the debugger):


REPORT[{contextEngineID=80:00:02:7d:03:00:90:d0:6d:fa:bc, 
contextName=nt}, requestID=0, errorStatus=0, errorIndex=0, 
VBS[1.3.6.1.6.3.15.1.1.3.0 = 18]]


Best regards,
Peter.


On 3/10/2016 23:06, Frank Fock wrote:

Hi Peter,

Yes, the ResponseEvent should be returned after the timeout with a 
null response.
From the log, it is unclear why you do not get the event. Is there an 
if-statement

that ignores the ResponseEvent with null response in your code?

Best regards,
Frank

Am 30.09.2016 um 10:12 schrieb Peter Verthez:

Hi Frank,

If we are using asynchronous SNMP calls with SNMPv3, what should be 
the behaviour in case of timeout, when you used wrong credentials 
such as a wrong user name.Should the ResponseListener always be 
triggered, with event.getResponse() = null, after the timeout?


I would expect that, but it looks like this is not what I'm seeing: 
the ResponseListener does not seem to be triggered in that case. So 
this means that our application never knows that a timeout 
occurred.   We are using currently SNMP4J 2.5.0. Debug logging from 
SNMP4J:


2016-09-28 16:43:31,768 DEBUG [JM-49-Ping-Ping-4]-[org.snmp4j.Snmp] 
Running pending async request with handle PduHandle[1071987217] and 
retry count left 1
2016-09-28 16:43:31,768 DEBUG 
[JM-49-Ping-Ping-4]-[org.snmp4j.transport.DefaultUdpTransportMapping] Sending 
message to 135.249.41.44/161 with length 268: 
30:82:01:08:02:01:01:04:06:70:75:62:6c:69:63:a0:81:fa:02:04:3f:e5:3a:11:02:01:00:02:01:00:30:81:eb:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:06:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:09:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:02:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:23:3c:03:02:00:05:00:30:0c:06:08:2b:06:01:02:01:01:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:07:00:05:00:30:0c:06:08:2b:06:01:02:01:01:02:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:03:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:0d:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:17:02:01:04:01:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:01:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:02:00:05:00
2016-09-28 16:43:35,771 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp] 
Running pending async request with handle PduHandle[1071987217] and 
retry count left 0
2016-09-28 16:43:35,771 DEBUG [SNMP4J 
Timer]-[org.snmp4j.transport.DefaultUdpTransportMapping] Sending 
message to 135.249.41.44/161 with length 268: 
30:82:01:08:02:01:01:04:06:70:75:62:6c:69:63:a0:81:fa:02:04:3f:e5:3a:11:02:01:00:02:01:00:30:81:eb:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:06:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:09:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:02:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:23:3c:03:02:00:05:00:30:0c:06:08:2b:06:01:02:01:01:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:07:00:05:00:30:0c:06:08:2b:06:01:02:01:01:02:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:03:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:0d:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:17:02:01:04:01:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:01:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:02:00:05:00
2016-09-28 16:43:36,861 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp] 
PendingRequest canceled key=null, pdu=null, target=null, 
transport=null, listener=null
2016-09-28 16:43

Re: [SNMP4J] snmp4j-smi-pro thread safe?

2016-10-03 Thread Frank Fock

Hi Ron,

It is, as long as no other thread is concurrently loading MIB objects 
into the MIB repository

currently used by the SmiManager.
This statement is true for all find methods.

Best regards,
Frank

Am 03.10.2016 um 00:27 schrieb Ronald Braswell:

Are methods on the SmiManager such as 'SmiObject findSmiObject(OID)' for
snmp4j-smi-pro 1.8 thread safe?

Ron
___
SNMP4J mailing list
SNMP4J@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

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Behaviour of ResponseListener in SNMP V3

2016-10-03 Thread Frank Fock

Hi Peter,

Yes, the ResponseEvent should be returned after the timeout with a null 
response.
From the log, it is unclear why you do not get the event. Is there an 
if-statement

that ignores the ResponseEvent with null response in your code?

Best regards,
Frank

Am 30.09.2016 um 10:12 schrieb Peter Verthez:

Hi Frank,

If we are using asynchronous SNMP calls with SNMPv3, what should be 
the behaviour in case of timeout, when you used wrong credentials such 
as a wrong user name.Should the ResponseListener always be 
triggered, with event.getResponse() = null, after the timeout?


I would expect that, but it looks like this is not what I'm seeing: 
the ResponseListener does not seem to be triggered in that case. So 
this means that our application never knows that a timeout occurred.   
We are using currently SNMP4J 2.5.0.   Debug logging from SNMP4J:


2016-09-28 16:43:31,768 DEBUG [JM-49-Ping-Ping-4]-[org.snmp4j.Snmp] 
Running pending async request with handle PduHandle[1071987217] and 
retry count left 1
2016-09-28 16:43:31,768 DEBUG 
[JM-49-Ping-Ping-4]-[org.snmp4j.transport.DefaultUdpTransportMapping] 
Sending message to 135.249.41.44/161 with length 268: 
30:82:01:08:02:01:01:04:06:70:75:62:6c:69:63:a0:81:fa:02:04:3f:e5:3a:11:02:01:00:02:01:00:30:81:eb:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:06:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:09:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:02:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:23:3c:03:02:00:05:00:30:0c:06:08:2b:06:01:02:01:01:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:07:00:05:00:30:0c:06:08:2b:06:01:02:01:01:02:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:03:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:0d:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:17:02:01:04:01:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:01:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:02:00:05:00
2016-09-28 16:43:35,771 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp] Running 
pending async request with handle PduHandle[1071987217] and retry 
count left 0
2016-09-28 16:43:35,771 DEBUG [SNMP4J 
Timer]-[org.snmp4j.transport.DefaultUdpTransportMapping] Sending 
message to 135.249.41.44/161 with length 268: 
30:82:01:08:02:01:01:04:06:70:75:62:6c:69:63:a0:81:fa:02:04:3f:e5:3a:11:02:01:00:02:01:00:30:81:eb:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:06:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:09:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:02:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:23:3c:03:02:00:05:00:30:0c:06:08:2b:06:01:02:01:01:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:07:00:05:00:30:0c:06:08:2b:06:01:02:01:01:02:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:03:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:0d:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:17:02:01:04:01:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:01:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:02:00:05:00
2016-09-28 16:43:36,861 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp] 
PendingRequest canceled key=null, pdu=null, target=null, 
transport=null, listener=null
2016-09-28 16:43:43,771 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp] Request 
timed out: 1071987217
2016-09-28 16:43:43,772 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp] 
Cancelling pending request with handle PduHandle[1071987217]


Best regards,
Peter.



--
---
AGENT++
Maximilian-Kolbe-Str. 10
73257 Koengen, Germany
https://agentpp.com
Phone: +49 7024 8688230
Fax:   +49 7024 8688231

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Trap Handling Configuration Framework

2016-09-29 Thread Frank Fock

Hi Ron,

There are several existing (mostly commercial) trap receiver implementations.
One that uses SNMP4J as protocol implementation is TrapStation. 
All of them provide generic approaches to classify and correlate traps.

My MIB Explorer can do this too on a basic level. 

A fully generic approach will fail for many MIBs in the market. You will need 
some scripting to achieve best integration result for those non-standard MIBs.

Hope this helps anyway.

Best regards,
Frank 


> On 29 Sep 2016, at 02:57, Ronald Braswell  wrote:
> 
> Is there a configuration based framework for which configurations can be
> specified to properly evaluate all traps from all vendors (or close to it)?
> 
> If not, do most people write custom code to handle traps from various
> vendors?
> 
> Ron
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] Add a proxy before sending SNMP request to the device

2016-09-29 Thread Frank Fock
Hi Zhenyu,

I think the easiest way to realise proxy support is writing your own 
TransportMapping class. Probably you can subclass one of the
abstract implementations.

Best regards,
Frank


> On 28 Sep 2016, at 01:37, Zhenyu Zhou  wrote:
> 
> Hello,
> 
> I'm looking for a java library for SNMP and find SNMP4J is the leading one.
> It satisfied all my requirements (eg. multithread) except for I'd like to
> put the traffic through a proxy before the request reaches device.
> 
> The proxy is a normal HTTP proxy: the client connects to it and sends a
> CONNECT request such as "CONNECT : HTTP/1.1". Then all following
> traffic within this channel will be redirected.
> 
> My question is, does anyone have any insights whether this is doable to add
> this feature to SNMP4J library (my gut feeling is doable)? I feel confused
> because I don't find where the code actively establishes a TCP connection
> with the device - the socket seems to be created at `ServerThread.run()`
> but it is server-side code (I guess it's for TRAP). So where might be the
> correct place to change the address to proxy's and establish the connection
> with proxy meanwhile? It might be somewhere that the code acts as a client
> to connect to the device for POLL.
> 
> Thanks in advance! Sorry for the kind of complex description and feel free
> to ask me to clarify anything here.
> 
> Best Regards!
> 
> Zhou, Zhenyu
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j

___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j


Re: [SNMP4J] SNMP4J Correct Multi-thread Design for use it (under Linux) ?

2016-09-24 Thread Frank Fock
Hi Thierry,

Your singleton factory method is NOT thread safe. This could create issues and
need to be fixed.

Anything else does not seem to be a real issue with SNMP.
The notInTimeWindow report is normal when two SNMPv3 entities 
exchange messages for the first time (the time needs to be synchronised).

Best regards,
Frank



> On 23 Sep 2016, at 15:57, TESSALONIKOS, THIERRY 
>  wrote:
> 
> Hi,
>  
> I need to use SNMP4J API in  multi-threading design, because I must send 2 
> snmp set in parallel toward 2 Network Elements for sending them a parameters…
>  
> So, I have a main thread that initialize the SNMP4J API, with a singleton 
> like this :
>  
> public class SNMP4JInitialize implements SNMPEngineInitInterface{
>  
> // properties SNMP4J
> private static SNMP4JInitialize snmp4JInitializeInstance;
> private static TransportMapping transport;
> private static Snmp snmp;
> private static USM usm;
> private static OctetString localEngineID;
>  
>  
> private SNMP4JInitialize() throws IOException {
>  
> // Intialisation SNMP4J
> transport = new DefaultUdpTransportMapping(); //@TODO utiliser un 
> autre constructeur pour positionner adresse IP d'écoute
> snmp = new Snmp(transport);
> localEngineID = new OctetString(MPv3.createLocalEngineID());
> usm = new USM(SecurityProtocols.getInstance(), localEngineID, 0);
> SecurityModels.getInstance().addSecurityModel(usm);
> SecurityProtocols.getInstance().addPrivacyProtocol(new 
> PrivAES256With3DESKeyExtension());
> transport.listen();
> // Instanaciation de la classe qui gere les UsmUer automatiquement à 
> partir des MAJ JMS envoyées par l'appli JEE
>  
> OctetString securityName1 = new OctetString("toto"); 
> UsmUser usmUser1 = new UsmUser(securityName1, // securityName
> AuthMD5.ID, // authenticationProtocol
> new OctetString("toto123456"), // authenticationPassphrase
> PrivAES128.ID, // privacyProtocol
> new OctetString("toto123456"));   // privacyPassphrase
> snmp.getUSM().addUser(usmUser1);
>  
>  
> OctetString securityName2 = new OctetString("titi"); 
> UsmUser usmUser2 = new UsmUser(securityName2, // securityName
> AuthSHA.ID, // authenticationProtocol
> new OctetString("toto123456"), // authenticationPassphrase
> PrivAES256With3DESKeyExtension.ID, // privacyProtocol
> //PrivAES256.ID, // privacyProtocol
> new OctetString("toto123456"));   // privacyPassphrase
> snmp.getUSM().addUser(usmUser2);
> }
>  
> public static Snmp getSnmp() {
> return snmp;
> }
>  
> public static SNMP4JInitialize getInstance() throws IOException, 
> Exception {
>  
> if (snmp4JInitializeInstance == null) {
> snmp4JInitializeInstance = new SNMP4JInitialize();
> }
> return (snmp4JInitializeInstance);
> }
> }
>  
> And after I launch 2 thread in parallel (from a thread pool, managed by 
> ExecutorService class…)
>  
> Each thread create a new UserTarget and getSNMP instance from the 
> Initialization Singleton, and send the PDU with snmp.send(pdu, target) like 
> this :
>  
> public class SNMP4JRequestSender implements SNMPModuleSenderInterface {
>  
> public RequestTaskStatus sendsnmpv3Request(RequestTaskStatus 
> requestTaskStatus, RequestTaskSNMP requestTaskSNMP) throws IOException {
>  
> final Address targetAddress = 
> GenericAddress.parse(requestTaskSNMP.getSnmpTargetURL());
>  
> // create the target
> UserTarget target = new UserTarget();
> target.setAddress(targetAddress);
> target.setRetries(requestTaskSNMP.getRetry());
> target.setTimeout(requestTaskSNMP.getTimout());
> target.setVersion(SnmpConstants.version3);
> target.setSecurityLevel(SecurityLevel.AUTH_PRIV);
> target.setSecurityName(requestTaskSNMP.getSecurityName());  // The 
> same name used for usmUser
>  
> //create the PDU
> ScopedPDU pdu = new ScopedPDU();
>  
> List variableBindings = requestTaskSNMP.getOids();
>  
> if ((variableBindings == null) || (variableBindings.isEmpty())) {
> requestTaskStatus.setResultStatus(GeneralResultStatusEnum.Failed);
> 
> requestTaskStatus.setReasonStatus(ReasonStatusEnum.NoOIDinSNMPRequest);
> return (requestTaskStatus);
> }
> for (VariableBinding variableBinding : variableBindings) {
> pdu.add(variableBinding);
> }
>  
> pdu.setType(requestTaskSNMP.getPDUType());
>  
> // send the PDU
> final ResponseEvent response = SNMP4JInitialize.getSnmp().send(pdu, 
> target);
>  
> // extract the response PDU (could be null if timed out)
> final PDU responsePDU = 

  1   2   3   4   5   6   7   8   >