02030405, 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:
>
&g
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:
>
> Sub
nk 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
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
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
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
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
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.
My opinion is that atleast the message should be allowed to go out.
Note that this issue does not occur when I
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
